Re: issue with systemd-udev-settle

[Matthias Bodenbinder <matthias@bodenbinder.de>]

Hello Christian,

first of all many thanks for your very detailed reply. This was excellent!

I activated systemd-udev-settle again and want to debug the situtation 
according to your instructions (with udev.log-priority etc.).

Here is the time consumption:

systemd-analyze blame:
######################
         56.397s systemd-udev-settle.service
          2.735s postfix.service
           482ms NetworkManager.service
           470ms lvm2-activation-early.service
           456ms ModemManager.service
           363ms systemd-logind.service
           336ms alsa-restore.service
           333ms rc-local.service
           333ms speech-dispatcher.service
           332ms pppd-dns.service
           332ms exim4.service
           330ms minidlna.service
           328ms openvpn.service
           326ms dovecot.service
           251ms avahi-daemon.service
           213ms networking.service
           146ms keyboard-setup.service
           136ms console-setup.service
           126ms kdm.service
           125ms systemd-modules-load.service
           117ms systemd-fsck@dev-vol\x2dgrp1-lv_1.service
           111ms 
systemd-fsck@dev-disk-by\x2duuid-68a8248c\x2d38fd\x2d4d5c\x2d83fa\x2da2aff3ff9ce5.service
           110ms kbd.service
            97ms 
systemd-fsck@dev-disk-by\x2duuid-22c1ca3a\x2dc781\x2d46b2\x2d98d3\x2de2a5733d68d2.service
            90ms lvm2-monitor.service
            84ms packagekit.service
            73ms nfs-common.service
            71ms saned.service
            68ms rpcbind.service
            58ms raid5.mount
            52ms udisks2.service
            44ms polkitd.service
            43ms rsyslog.service
            40ms systemd-user-sessions.service
            38ms user@1000.service
            38ms colord.service
            37ms systemd-udev-trigger.service
            36ms 
systemd-fsck@dev-disk-by\x2duuid-5085c7fb\x2d926d\x2d4f44\x2db8d0\x2d78b571f805d7.service
            35ms lvm2-activation.service
            28ms systemd-tmpfiles-setup-dev.service
            26ms systemd-update-utmp.service
            26ms systemd-journal-flush.service
            25ms rtkit-daemon.service
            24ms upower.service
            22ms lvm2-pvscan@8:17.service
            22ms media-data.mount
            16ms media-data2.mount
            15ms systemd-remount-fs.service
            15ms dev-mqueue.mount
            14ms sys-kernel-debug.mount
            13ms systemd-setup-dgram-qlen.service
            13ms dev-hugepages.mount
            12ms systemd-tmpfiles-setup.service
            11ms systemd-random-seed.service
             8ms kmod-static-nodes.service
             8ms sys-fs-fuse-connections.mount
             8ms var-tmp.mount
             8ms systemd-update-utmp-runlevel.service
             8ms systemd-sysctl.service
             7ms 
dev-disk-by\x2duuid-13030826\x2d8987\x2d46c9\x2dbc1f\x2d8a9e9a4549c9.swap
             7ms tmp.mount
             6ms home.mount
             5ms systemd-udevd.service
             1ms udev-finish.service
################


But I am not really happy with the log since I find the following 
statement when doing a journalctl -b:

#### start of log
Apr 29 06:51:55 xxx systemd-journal[164]: Runtime journal is using 8.0M 
(max allowed 79.2M, trying to leave 118.8M free of 784.2M available → 
current limit 79.2M).

....

Apr 29 06:52:19 xxx systemd-journal[164]: Forwarding to syslog missed 
3819 messages.
Apr 29 06:52:25 xxx systemd-journal[164]: Suppressed 2818 messages from 
/system.slice/systemd-udevd.service

####


Looks like I am missing plenty of udev log messages during the critical 
phase of the boot process. Any idea what to do about it?

Thanks for your help.
Matthias