20210724のLinuxに関する記事は5件です。

npm install -g が失敗する場合の対処法

環境 Macですがlinuxなら同様の対処で解決するのではないでしょうか 特にバージョンは関係ないかと思います npm install -gをするとPermission deniedで失敗してしまう npmの新しいバージョンが使えるようになったということでnpm install -g npmでバージョンアップしようとしたところ、以下のようなエラーが出てしまいました npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules/npm/node_modules/abbrev' npm ERR! [Error: EACCES: permission denied, access '/usr/local/lib/node_modules/npm/node_modules/abbrev'] { npm ERR! errno: -13, npm ERR! code: 'EACCES', npm ERR! syscall: 'access', npm ERR! path: '/usr/local/lib/node_modules/npm/node_modules/abbrev' npm ERR! } 原因 自明ですが権限エラーです 調べてみるとやはりroot権限になっていました $ ls -la /usr/local/lib/node_modules/npm total 512 // ・・・ drwxr-xr-x 360 root wheel 11520 10 9 2020 node_modules // ・・・ 対処 root権限である必要もないし、Macユーザをオーナーにしようと思ったので以下のコマンドで/usr/local/lib/node_modules以下の権限を全て変更しました $ sudo chown -R $USER /usr/local/lib/node_modules パスワードの入力を要求されるので入力してください 環境変数にユーザ名が登録されたいない場合は $ sudo chown -R $(whoami) /usr/local/lib/node_modules で変更してください ちなみに上記コマンドでは/usr/local/lib/node_modules以下のディレクトリが全てMacのユーザ権限になります ちなみに 別のユーザをオーナーにする場合は$USERの部分にユーザ名を入力してください 参考 stackoverflowに記事がありました https://stackoverflow.com/questions/48910876/error-eacces-permission-denied-access-usr-local-lib-node-modules
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Windows TerminalのLinux設定

WSL2のWindows Terminalにおける、Linuxの設定 デフォルトではLinuxは入っていないので、新規セットアップするたびにあちこちググって設定項目を見つけて設定を記述していたのが面倒くさくなったので、Qiitaに記事化しておきます。 { "cursorShape": "filledBox", "fontFace": "Source Code Pro", "fontSize": 11, "fontWeight": "extra-light", "guid": "{インストールしたLinuxのGUID}", "hidden": false, "name": "インストールしたLinuxの名前", "scrollbarState": "hidden", "source": "Windows.Terminal.Wsl", "startingDirectory": "//wsl$/Ubuntu-20.04/home/[アカウント名]" }, 最低限、これだけ設定しておけば、普段使いのLinuxと同じ設定に出来るのはないかと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

パスワードなしで sudo で apt を実行できるようにする (ubuntu 21.04)

パスワードなしで sudo で apt を実行できるようにする (ubuntu 21.04) 手順 echo $USER ALL=NOPASSWD: /usr/bin/apt | sudo tee /etc/sudoers.d/apt sudo chmod 440 /etc/sudoers.d/apt 説明 こちらの記事 でパスワードなしで sudo を実行する方法を説明しました。 apt のプロキシ対応 の記事で少し触れたとおり、ubuntu 21.04 では /etc/sudoers が readonly に設定されています。そのうえで /etc/sudoers の最後で /etc/sudoers.d 以下のファイルを include するようになっています。 このため /etc/sudoers を直接編集する方法ではなく、/etc/sudoers.d 以下に新しいファイルを作成して行います。 /etc/sudoers.d/README の説明によれば /etc/sudoers.d 以下のファイルのファイルの permission を 440 とすべきとあるので、permission を明示的に指定します。 sudoers 関連のファイルを編集するときの注意 sudoers 関連の設定ファイルを編集する場合、操作を間違うと sudo が機能しなくなる恐れがあります。 このため sudoers 関連の設定ファイルを編集する前に、別に terminal を起動して以下コマンドでroot のシェルを起動したうえで、行うことをお勧めします。 sudo -i 別で root 権限の terminal を起動しておくと、sudoers 関連の設定ファイルの操作を誤った場合でも root 権限で元に戻すことができます。 参考 /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL:ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "@include" directives: @includedir /etc/sudoers.d /etc/sudoers.d/README # # As of Debian version 1.7.2p1-1, the default /etc/sudoers file created on # installation of the package now includes the directive: # # #includedir /etc/sudoers.d # # This will cause sudo to read and parse any files in the /etc/sudoers.d # directory that do not end in '~' or contain a '.' character. # # Note that there must be at least one file in the sudoers.d directory (this # one will do), and all files in this directory should be mode 0440. # # Note also, that because sudoers contents can vary widely, no attempt is # made to add this directive to existing sudoers files on upgrade. Feel free # to add the above directive to the end of your /etc/sudoers file to enable # this functionality for existing installations if you wish! # # Finally, please note that using the visudo command is the recommended way # to update sudoers content, since it protects against many failure modes. # See the man page for visudo for more information. #
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MMC Asynchronous Request

MMC Asynchronous Request Rationale How significant is the cache maintenance overhead? キャッシュメンテナンスのオーバーヘッドは、どれくらい重要ですか? It depends. Fast eMMC and multiple cache levels with speculative cache pre-fetch makes the cache overhead relatively significant. 場合によります。高速なeMMCと、投機的なキャッシュプリフェッチを備えた複数のキャッシュレベルによって、キャッシュのオーバーヘッドを比較的大きくします。 If the DMA preparations for the next request are done in parallel with the current transfer, the DMA preparation overhead would not affect the MMC performance. もし現在の転送と並行して次の要求のためにDMAが準備できるならば、DMAの準備がMMC性能には影響を与えません。 The intention of non-blocking (asynchronous) MMC requests is to minimize the time between when an MMC request ends and another MMC request begins. non-blocking (asynchronous) MMC requestsの目的は、MMC要求が終了してから別のMMC要求が開始するまでの時間を最小限に抑える事にあります。 Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and dma_unmap_sg are processing. Using non-blocking MMC requests makes it possible to prepare the caches for next job in parallel with an active MMC request. mmc_wait_for_req()を使うと、dma_map_sgとdma_unmap_sgを処理している間、MMC controllerはidle状態になります。non-blocking MMC requestsを用いることで、アクティブなMMC要求と並行して次のジョブに対するキャッシュの準備をすることができます。 MMC block driver The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking. mmc block driverのmmc_blk_issue_rw_rq()は、non-blockingになります。 The increase in throughput is proportional to the time it takes to prepare (major part of preparations are dma_map_sg() and dma_unmap_sg()) a request and how fast the memory is. スループットの増加は、要求の準備に要する時間(準備の大部分はdma_map_sg()とdma_unmap_sgです)と、メモリ速度に比例します。 The faster the MMC/SD is the more significant the prepare request time becomes. MMC/SDが高速になれば、要求に対する準備時間はさらに重要になります。 Roughly the expected performance gain is 5% for large writes and 10% on large reads on a L2 cache platform. 大まかに、L2 cache platformにおいて、大容量な書き込みでは5%、大容量な読み込みでは10%の性能向上を示します。 In power save mode, when clocks run on a lower frequency, the DMA preparation may cost even more. 省電力モードでは、クロックがより低い周波数で動作します。DMA準備は更にコストがかかる場合があります。 As long as these slower preparations are run in parallel with the transfer performance won't be affected. これらの準備が遅くなることは、転送処理と並列して実行することで影響を免れます。 Details on measurements from IOZone and mmc_test MMC core API extension There is one new public function mmc_start_req(). 新しいpublic function mmc_start_req()が追加されます。 It starts a new MMC command request for a host. The function isn't truly non-blocking. If there is an ongoing async request it waits for completion of that request and starts the new one and returns. これは、新しいMMC command 要求をホストに開始するものです。この関数は、完全なnon-blockingではありません。もし、非同期要求を実行中である場合には、その要求が開始し、returnし、完遂するまで待ちます。 It doesn't wait for the new request to complete. If there is no ongoing request it starts the new request and returns immediately. 新しいリクエストについては待ちません。新しいリクエストはすぐに開始し、すぐにreturnします。 MMC host extensions There are two optional members in the mmc_host_ops -- pre_req() and post_req() -- that the host driver may implement in order to move work to before and after the actual mmc_host_ops.request() function is called. mmc_host_ops に2つのoptionalなメンバー pre_req()とpost_req()が追加されます。 host driverは、mmc_host_ops.request()関数が呼ばれる前後に実行する処理を実装できます。 In the DMA case pre_req() may do dma_map_sg() and prepare the DMA descriptor, and post_req() runs the dma_unmap_sg(). DMAの場合、pre_req()はdma_map_sg()を実行してDMA descriptorを準備し、post_req()はdma_unmap_sg()を実行します。 Optimize for the first request The first request in a series of requests can't be prepared in parallel with the previous transfer, since there is no previous request. 一連のリクエストにおいて、最初のリクエストには前のリクエストがありません。そのため、前の転送と並行して準備できません。 The argument is_first_req in pre_req() indicates that there is no previous request. The host driver may optimize for this scenario to minimize the performance loss. pre_req()のis_first_req引数は、前のrequestが存在するかどうかを示します。host driverはパフォーマンス損失を最小化するために、このシナリオで最適化することができます。 A way to optimize for this is to split the current request in two chunks, prepare the first chunk and start the request, and finally prepare the second chunk and start the transfer. これを最適化する方法は、現在の要求を2つのchunksに分割する事です。最初のチャンクの準備をして、要求を実行し、最後に2番目のチャンクの準備をして、転送を開始します。 Pseudocode to handle is_first_req scenario with minimal prepare overhead:: is_first_req scenarioを用いた準備のオバーヘッド最小化の疑似コードは以下です。 if (is_first_req && req->size > threshold) /* start MMC transfer for the complete transfer size */ /* 完全な転送サイズをMMC転送を開始 */ mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); /* * Begin to prepare DMA while cmd is being processed by MMC. * The first chunk of the request should take the same time * to prepare as the "MMC process command time". * If prepare time exceeds MMC cmd time * the transfer is delayed, guesstimate max 4k as first chunk size. */ /* * cmdがMMCによって処理されている間に、DMAの準備を開始する * 要求の最初のチャンクは、"MMC process command time"と同じ時間で準備する必要がある。 * 準備時間がMMC cmd時間を超過すると、転送が遅延します。最初のチャンクの大きさは最大4Kと推定します。 */ prepare_1st_chunk_for_dma(req); /* flush pending desc to the DMAC (dmaengine.h) */ /* DMACに対してpendingしていたdescをflushします(dmaengine.h) */ dma_issue_pending(req->dma_desc); prepare_2nd_chunk_for_dma(req); /* * The second issue_pending should be called before MMC runs out * of the first chunk. If the MMC runs out of the first data chunk * before this call, the transfer is delayed. */ /* * 2番目のissue_pendingは、MMCが最初のチャンクを使い果たす前に呼び出す必要があります。 * この呼び出しの前にMMCが最初のデータチャンクを使い果たした場合、転送は遅延します。 */ dma_issue_pending(req->dma_desc); (訳中)つまり、どういうこと? 時間がかかるDMAの準備と、MMCへの送信処理とをパイプライン化することで、効率よく処理しましょう、というアイデア。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

systemd-resolvedを無効化する

覚書です 不具合があるらしく、なくても困らないので無効にします。 rootで実行する systemctl stop systemd-resolved systemctl disable systemd-resolved rm /etc/resolv.conf systemctl restart NetworkManager
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む