Why is systemd-udev pegging my CPU?












10














I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in 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


Why might systemd-udev be hammering the CPU? This is a Kubuntu 14.10 system:



$ 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


EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.



As per Bratchley's suggestion, here is the strace of the systemd-udev process with ID 359.










share|improve this question




















  • 2




    You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
    – Bratchley
    Oct 1 '15 at 20:22






  • 1




    @Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
    – dotancohen
    Oct 1 '15 at 21:18






  • 1




    Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
    – Bratchley
    Oct 2 '15 at 15:13






  • 1




    I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
    – dotancohen
    Oct 2 '15 at 15:19






  • 2




    Is there anything shown when you run "udevadm monitor" ?
    – V13
    Oct 2 '15 at 16:04
















10














I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in 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


Why might systemd-udev be hammering the CPU? This is a Kubuntu 14.10 system:



$ 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


EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.



As per Bratchley's suggestion, here is the strace of the systemd-udev process with ID 359.










share|improve this question




















  • 2




    You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
    – Bratchley
    Oct 1 '15 at 20:22






  • 1




    @Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
    – dotancohen
    Oct 1 '15 at 21:18






  • 1




    Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
    – Bratchley
    Oct 2 '15 at 15:13






  • 1




    I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
    – dotancohen
    Oct 2 '15 at 15:19






  • 2




    Is there anything shown when you run "udevadm monitor" ?
    – V13
    Oct 2 '15 at 16:04














10












10








10


3





I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in 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


Why might systemd-udev be hammering the CPU? This is a Kubuntu 14.10 system:



$ 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


EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.



As per Bratchley's suggestion, here is the strace of the systemd-udev process with ID 359.










share|improve this question















I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in 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


Why might systemd-udev be hammering the CPU? This is a Kubuntu 14.10 system:



$ 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


EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.



As per Bratchley's suggestion, here is the strace of the systemd-udev process with ID 359.







systemd cpu-usage






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 2 '15 at 15:17

























asked Oct 1 '15 at 11:29









dotancohen

6,216195795




6,216195795








  • 2




    You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
    – Bratchley
    Oct 1 '15 at 20:22






  • 1




    @Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
    – dotancohen
    Oct 1 '15 at 21:18






  • 1




    Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
    – Bratchley
    Oct 2 '15 at 15:13






  • 1




    I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
    – dotancohen
    Oct 2 '15 at 15:19






  • 2




    Is there anything shown when you run "udevadm monitor" ?
    – V13
    Oct 2 '15 at 16:04














  • 2




    You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
    – Bratchley
    Oct 1 '15 at 20:22






  • 1




    @Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
    – dotancohen
    Oct 1 '15 at 21:18






  • 1




    Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
    – Bratchley
    Oct 2 '15 at 15:13






  • 1




    I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
    – dotancohen
    Oct 2 '15 at 15:19






  • 2




    Is there anything shown when you run "udevadm monitor" ?
    – V13
    Oct 2 '15 at 16:04








2




2




You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
– Bratchley
Oct 1 '15 at 20:22




You might strace it using strace -fvvp 359 chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
– Bratchley
Oct 1 '15 at 20:22




1




1




@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18




@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18




1




1




Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
– Bratchley
Oct 2 '15 at 15:13




Well it doesn't look like it's looping.It seems to be reading in a bunch of files and modprobe-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg command?
– Bratchley
Oct 2 '15 at 15:13




1




1




I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
– dotancohen
Oct 2 '15 at 15:19




I should have checked dmesg, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
– dotancohen
Oct 2 '15 at 15:19




2




2




Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04




Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04










6 Answers
6






active

oldest

votes


















11














It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules



Look for a couple of lines that look like this (at the end of the file):



# 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"


Comment the second line by putting a # before ENV, so that it looks like:



#ENV{ID_MTP.... 


Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)






share|improve this answer





















  • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
    – Nate Glenn
    Mar 31 '17 at 7:10



















6














Use udevadm monitor to find out which driver is pooling the cpu.






share|improve this answer































    2














    Another cause:




    1. Installed nvidia driver 396

    2. Restart with blank screen

    3. Disabled nvidia in bios


    4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):



      ...
      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)
      ...



    I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.






    share|improve this answer



















    • 1




      I ran into the same problem. uninstalled Nvidia drivers solved the problem.
      – TC Zhang
      Oct 4 at 5:31



















    1














    There is a bug in the kernel that cause systemd-udevs 100% CPU usage.



    So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.



    This work fine for me.






    share|improve this answer





























      0














      I had the same problem on Linux Mint 17.3 Rosa.



      To solve it, when my PC is idle:




      • I open up terminal.

      • Login as SU.

      • Use top command and see PID of systemd.

      • Kill it.


      CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.






      share|improve this answer























      • I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
        – aventurin
        Sep 27 '16 at 22:21



















      0














      I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.






      share|improve this answer





















        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "106"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f233247%2fwhy-is-systemd-udev-pegging-my-cpu%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        6 Answers
        6






        active

        oldest

        votes








        6 Answers
        6






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        11














        It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules



        Look for a couple of lines that look like this (at the end of the file):



        # 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"


        Comment the second line by putting a # before ENV, so that it looks like:



        #ENV{ID_MTP.... 


        Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)






        share|improve this answer





















        • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
          – Nate Glenn
          Mar 31 '17 at 7:10
















        11














        It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules



        Look for a couple of lines that look like this (at the end of the file):



        # 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"


        Comment the second line by putting a # before ENV, so that it looks like:



        #ENV{ID_MTP.... 


        Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)






        share|improve this answer





















        • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
          – Nate Glenn
          Mar 31 '17 at 7:10














        11












        11








        11






        It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules



        Look for a couple of lines that look like this (at the end of the file):



        # 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"


        Comment the second line by putting a # before ENV, so that it looks like:



        #ENV{ID_MTP.... 


        Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)






        share|improve this answer












        It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules



        Look for a couple of lines that look like this (at the end of the file):



        # 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"


        Comment the second line by putting a # before ENV, so that it looks like:



        #ENV{ID_MTP.... 


        Restart your computer or run sudo systemctl restart systemd-udevd and enjoy your free CPU cycles :)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 19 '16 at 16:13









        eLobato

        21124




        21124












        • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
          – Nate Glenn
          Mar 31 '17 at 7:10


















        • Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
          – Nate Glenn
          Mar 31 '17 at 7:10
















        Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
        – Nate Glenn
        Mar 31 '17 at 7:10




        Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
        – Nate Glenn
        Mar 31 '17 at 7:10













        6














        Use udevadm monitor to find out which driver is pooling the cpu.






        share|improve this answer




























          6














          Use udevadm monitor to find out which driver is pooling the cpu.






          share|improve this answer


























            6












            6








            6






            Use udevadm monitor to find out which driver is pooling the cpu.






            share|improve this answer














            Use udevadm monitor to find out which driver is pooling the cpu.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 7 at 14:48









            Michael Mrozek

            60.6k29187208




            60.6k29187208










            answered May 7 at 13:55









            wayfactory

            6111




            6111























                2














                Another cause:




                1. Installed nvidia driver 396

                2. Restart with blank screen

                3. Disabled nvidia in bios


                4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):



                  ...
                  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)
                  ...



                I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.






                share|improve this answer



















                • 1




                  I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                  – TC Zhang
                  Oct 4 at 5:31
















                2














                Another cause:




                1. Installed nvidia driver 396

                2. Restart with blank screen

                3. Disabled nvidia in bios


                4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):



                  ...
                  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)
                  ...



                I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.






                share|improve this answer



















                • 1




                  I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                  – TC Zhang
                  Oct 4 at 5:31














                2












                2








                2






                Another cause:




                1. Installed nvidia driver 396

                2. Restart with blank screen

                3. Disabled nvidia in bios


                4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):



                  ...
                  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)
                  ...



                I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.






                share|improve this answer














                Another cause:




                1. Installed nvidia driver 396

                2. Restart with blank screen

                3. Disabled nvidia in bios


                4. System works with Intel, but after several sleep/resume I got this from udevadm monitor (random lines but repeating all the same indefinitely):



                  ...
                  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)
                  ...



                I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 16 at 10:06









                Thomas

                3,70061225




                3,70061225










                answered Jun 13 at 7:42









                dmatej

                1313




                1313








                • 1




                  I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                  – TC Zhang
                  Oct 4 at 5:31














                • 1




                  I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                  – TC Zhang
                  Oct 4 at 5:31








                1




                1




                I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                – TC Zhang
                Oct 4 at 5:31




                I ran into the same problem. uninstalled Nvidia drivers solved the problem.
                – TC Zhang
                Oct 4 at 5:31











                1














                There is a bug in the kernel that cause systemd-udevs 100% CPU usage.



                So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.



                This work fine for me.






                share|improve this answer


























                  1














                  There is a bug in the kernel that cause systemd-udevs 100% CPU usage.



                  So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.



                  This work fine for me.






                  share|improve this answer
























                    1












                    1








                    1






                    There is a bug in the kernel that cause systemd-udevs 100% CPU usage.



                    So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.



                    This work fine for me.






                    share|improve this answer












                    There is a bug in the kernel that cause systemd-udevs 100% CPU usage.



                    So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.



                    This work fine for me.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Aug 25 at 19:21









                    Yolt

                    111




                    111























                        0














                        I had the same problem on Linux Mint 17.3 Rosa.



                        To solve it, when my PC is idle:




                        • I open up terminal.

                        • Login as SU.

                        • Use top command and see PID of systemd.

                        • Kill it.


                        CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.






                        share|improve this answer























                        • I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                          – aventurin
                          Sep 27 '16 at 22:21
















                        0














                        I had the same problem on Linux Mint 17.3 Rosa.



                        To solve it, when my PC is idle:




                        • I open up terminal.

                        • Login as SU.

                        • Use top command and see PID of systemd.

                        • Kill it.


                        CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.






                        share|improve this answer























                        • I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                          – aventurin
                          Sep 27 '16 at 22:21














                        0












                        0








                        0






                        I had the same problem on Linux Mint 17.3 Rosa.



                        To solve it, when my PC is idle:




                        • I open up terminal.

                        • Login as SU.

                        • Use top command and see PID of systemd.

                        • Kill it.


                        CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.






                        share|improve this answer














                        I had the same problem on Linux Mint 17.3 Rosa.



                        To solve it, when my PC is idle:




                        • I open up terminal.

                        • Login as SU.

                        • Use top command and see PID of systemd.

                        • Kill it.


                        CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Sep 27 '16 at 22:10









                        Tomasz

                        9,19352965




                        9,19352965










                        answered Sep 27 '16 at 21:50









                        Ryo Adi Suwito

                        1




                        1












                        • I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                          – aventurin
                          Sep 27 '16 at 22:21


















                        • I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                          – aventurin
                          Sep 27 '16 at 22:21
















                        I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                        – aventurin
                        Sep 27 '16 at 22:21




                        I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
                        – aventurin
                        Sep 27 '16 at 22:21











                        0














                        I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.






                        share|improve this answer


























                          0














                          I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.






                          share|improve this answer
























                            0












                            0








                            0






                            I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.






                            share|improve this answer












                            I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Nov 2 '17 at 16:57









                            Yanzzee

                            1012




                            1012






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Unix & Linux Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.





                                Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                Please pay close attention to the following guidance:


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f233247%2fwhy-is-systemd-udev-pegging-my-cpu%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Morgemoulin

                                Scott Moir

                                Souastre