systemd-udevがCPUをペギングするのはなぜですか？

15

4コアのラップトップのコアの1つが固定されており、温度が非常に高いことに気付きました。私はこれを見つけましたtop：

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  359 root      20   0  188684 147228   1552 R  99.4  5.0 111:19.91 systemd-udevd
20011 root      20   0  188320 147604   2076 S  11.0  5.0   0:00.33 systemd-udevd
11053 dotanco+  20   0 3030036 918672  49608 S   9.6 31.2 280:40.65 firefox
 3468 dotanco+  20   0 3612776 136740  43484 S   1.7  4.6  57:02.52 plasma-desktop
20006 root      20   0       0      0      0 Z   1.0  0.0   0:00.37 systemd-udevd

なぜsystemd-udevCPUに打撃を与えているのでしょうか？これはKubuntu 14.10システムです。

$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 \n \l

編集：私はペグされたCPUに加えて、追加の問題があることに気づきました。USB大容量ストレージデバイスやキーボードなど、新しく接続されたUSBデバイスは表示されますlsusbが、使用できません。大容量記憶装置は自動マウントされず、USBキーボードは機能しません。USBドライブを手動でマウントしようとしませんでした。

Bratchleyの提案どおり、ここにstraceのあるのsystemd-udevID 359を持つプロセスが。

systemd cpu-usage

— ドタンコーヘン
ソース

2

あなたは可能性があるstrace、それは使用してstrace -fvvp 359チャンスはそれが何かに継続的にループしていますです。何か意味のあるものを選ぶことができるかもしれません。これはおそらくバグですが、それについてのデータを収集できる場合は、依然として優れたバグレポートになる可能性があります。

— -Bratchley

1

@Bratchley：ありがとう、こちらがstraceです。今、私はそれを読む方法を学ぶためにグーグルで調べていますが、どんなアドバイスでも大歓迎です。

— -dotancohen

1

まあ、ループしているようには見えません。ファイルをmodprobeセットアップして読み込むために、たくさんのファイルを読み込んでいるようです。本当にランダムなものの束。メッセージまたはdmesgコマンドに何かを出力しますか？

— -Bratchley

1

確認する必要がありましたがdmesg、約2〜3時間前にマシンをリセットしました。ループがないことを確認していただき、ありがとうございます。私はそれらを読むことに精通していませんが、トレースを試してみましたが、CPUが急増したときに常に最初に考える無限ループは見つかりませんでした。

— -dotancohen

2

「udevadm monitor」を実行すると表示されるものはありますか？

— V13

15

libmtpがデバイスを検出したように見えますが、デバイスを適切に切断できず、常にチェックしています。特定のデバイスで発生し、/ lib / udev / rules.d / 69-libmtp.rulesを編集することで無効にできます

次のような行を数行探します（ファイルの最後）：

# Autoprobe vendor-specific, communication and PTP devices 
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl     ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li     bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

次のように、ENVの前に＃を付けて2行目をコメント化します。

#ENV{ID_MTP....

コンピューターを再起動するかsudo systemctl restart systemd-udevd、無料のCPUサイクルを実行してお楽しみください:)

— エロバト
ソース

再起動が必要でした。systemd-udevdを数回再起動しようとしましたが、常にすぐにCPUを再度ペグします。

— ネイトグレン

8

udevadm monitorCPUをプールしているドライバーを見つけるために使用します。

— ウェイファクトリー
ソース

OK。デバイスを見つけたと思います。今何？

— -norok2

4

別の原因：

nvidiaドライバー396をインストールしました
空白の画面で再起動する
BIOSの無効なnvidia

システムはIntelで動作しますが、いくつかのスリープ/レジュームの後、私はこれを取得しましたudevadm monitor（ランダムな行ですが、すべて同じことを無期限に繰り返します）：

...
KERNEL[10072.040174] remove   /module/nvidia (module)
UDEV  [10072.062670] add      /module/nvidia (module)
UDEV  [10072.063617] add      /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV  [10072.076901] remove   /module/nvidia (module)
UDEV  [10072.109365] add      /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add      /module/nvidia (module)
KERNEL[10072.139241] add      /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove   /kernel/slab/:0012288 (slab)
...

確信はありませんが、nvidiaドライバーはアクティブですが、nvidiaはBIOSで無効になっているという事実が原因であると考えています。

— dmatej
ソース

1

私は同じ問題に遭遇しました。アンインストールされたNvidiaドライバーは問題を解決しました。

— TC張

2

eLobatoによって提案されたソリューションは、私にとってはうまくいきませんでした。

説明した同じsympthomsで、このスレッドを見つけました：https ://askubuntu.com/questions/1073185/after-upgrade-from-ubuntu-16-to-18-04-systemd-udevd-uses-100-cpu

それで問題は解決しました。完全を期すために以下の解決策を繰り返しますが、すべてのクレジットはbrunom4cielによる元の答えになります。

プロセスを停止および開始して、望ましくない副作用なしに問題を解決できるかどうか試してください。

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sleep 5

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

これが機能する場合、以下のスクリプトに埋め込みます/etc/init.d/systemd-udevd-solv.sh：

sudo vim /etc/init.d/systemd-udevd-solv.sh

そして貼り付け：

#!/bin/sh

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sleep 5

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

次に、ログイン時に実行される許可を変更します

sudo chmod a+x /etc/init.d/systemd-udevd-solv.sh

— SeF
ソース

1

カーネルにはsystemd-udevsのCPU使用率が100％になるバグがあります。

したがって、回避策はシステムを再起動し、Grubのロード中にShiftを押し続けることです。次に、ブートローダーリストにリストされている古いカーネルを選択します。

これは私には問題ありません。

— ヨルト
ソース

0

Linux Mint 17.3 Rosaでも同じ問題が発生しました。

それを解決するには、私のPCがアイドル状態のとき：

ターミナルを開きます。
SUとしてログインします。
topコマンドを使用して、のPIDを参照してくださいsystemd。
それを殺します。

CPUが通常に戻り、RAM使用率が低下しました。もちろん、私のデスクトップはまだ安定しています。その操作の後、デスクトップを通常どおり使用できます。

— リョアディスウィート
ソース

systemdは常にPID 1 0pointer.de/blog/projects/systemd.html

— アベンチュリン

0

これは、Hyper-Vで実行されているCentOSの一部のインストールで問題になることがわかりました。VM設定でIntegration Servicesをオフにすると、解決したように見えます。特に時間同期。

— ヤンジー
ソース