Re: issue with systemd-udev-settle
Am 2015-04-29 07:15, schrieb Matthias Bodenbinder:
systemd-analyze blame:
56.397s systemd-udev-settle.service
Yeah, that shouldn't happen.
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?
Ok, so basically you are running into a pathological case of Bug
#762700 [1]. A bit of explanation: journald forwards messages to
syslog by queuing them in the socket for syslog. However, syslog is
only started later in boot (after remote-fs.target, because /var
could be on network filesystems or so) - and thus messages will
only be queued until the kernel reaches a limit, further messages
will be dropped until syslog can actually start and process these
messages. The solution to the aforementioned bug was to increase
the limit from 11 to 513, which covers most cases. However, if at
early boot an uncharacteristic number of messages is generated,
even that limit will be reached.
In this case, because you activated udev debugging, udev will
generate a LOT of messages - and this will exceed the limit, since
udev is early-boot and udevadm-settle.service will have to be done
before syslog is started. (Typically, early-boot shouldn't log
even remotely as much.) Increasing the limit could help here, but
sine this is only for debugging, don't bother, because there's a
much simpler way:
Just use journalctl (without -b) to see all messages (they are
still in RAM in the journal - as per the log you posted, journald
will use up to 80 MiB [2] which is more than enough to keep all
3000 or so messages). Just look through them (there are going to
be a lot of debug messages from udev) and look at the timestamps.
There you'll be able to see where the delay happens - and maybe
you'll have a chance of figuring out, what the problem is. If
it's nothing obvious, just post the last 20 or so udev messages
before the large gap in the timestamps and every udev message
afterwards. If there is no gap and udev is constantly doing
something, take a look at what it's actually doing.
Christian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
[2] The limit depends on the amount of RAM you have, so this is
true on your computer, but not necessarily in general.
Reply to: