Re: issue with systemd-udev-settle
Hi,
Am 2015-04-28 07:48, schrieb Matthias Bodenbinder:
I installed debian 8 on one of my PCs and got into trouble with extra
long boot times of > 2 min. I found out that it due to
systemd-udev-settle.service. My PC is using lvm and that somehow
interferes with systemd-udev-settle.service. The web tells that
systemd-udev-settle.service is needed for lvm. Nevertheless I
deactivated it with
systemctl mask systemd-udev-settle
The PC is booting fast now and the logical volumne is mounted just
fine.
Q1) So what is the thing about systemd-udev-settle being needed for
lvm? Do I miss something?
The problem isn't mounting LVMs, systemd will do that once the devices
appear, so that's not a problem. The problem is rather that the backing
devices for LVM (phyiscal volumes) might not be available when the LVM
startup script is run - and then LVM is not activated at all (vgchange
doesn't work, since the device isn't there yet).
Note that if the LVM PV is on the same device as the root filesystem
(e.g. a different partition on the same drive/SSD or so), this will
never occur, because once the root filesystem is mounted, the drive
has to already have been probed. But if it's on another drive, it just
*might* happen that the LVM startup script is called too early.
So yes, udevadm settle (which is what this service calls) is required
if you have a script that needs devices to be there when it's run. It
is not necessarily required in all cases (e.g. if the root filesystem
is on the same drive/SSD), but if it's not there, it might cause
problems. Also, even if you don't have problems right now, it might
cause problems down the line, if you in a year or so decide to alter
something about your system (and then maybe don't remember you masked
this service). And this can also be hard to track down, because not
using udevadm settle just means that you are open to a potential race
condition, so it may work most of the time but every now and then it
might fail, if for some reason at that time the hardware decides to
take longer to probe or so.
Three additional things:
1. Not only the LVM startup script needs udevadm settle, but also
other things might, so masking it is probably a bad idea right now.
2. You can also use LVM in a different way: don't use the startup
script but rather use lvmetad, which will activate volumes when the
backing devices start to appear, which is much more in line with a
proper dynamic startup. To use that, set use_lvmetad = 1 in
/etc/lvm/lvm.conf. Two caveats: please read the comments and
apparently (I haven't tried it myself), it currently doesn't work in
Jessie, because of Bug #774082 [1].
3. Some other scripts might actually call udevadm settle themselves
regardless of this service, so if that hangs, masking the service
doesn't necessarily help you.
In the long term, udevadm settle should probably die and everything
should be able to pick up stuff dynamically (e.g. using lvmetad and
similar), but we're not quite there yet, so you should NOT mask
that service right now. In some future version it might disappear.
Q2) Is there a way to set a shorter timeout value for
systemd-udev-settle.service?
Direct answer to your question:
Create the directory
/etc/systemd/system/systemd-udev-settle.service.d
and create a file
/etc/systemd/system/systemd-udev-settle.service.d/timeout.conf
that contains the following contents:
----------------------------------------------
[Service]
ExecStart=
ExecStart=/bin/udevadm settle --timeout=60
----------------------------------------------
(The first line removes the default command of the service, the
second line sets the new command to be the one with the timeout.)
That said, I think that's a REALLY bad idea to do, because it just
tapers over the real, underlying problem. I've used Jessie with LVM
just fine (even in complicated setups with LVM on iSCSI and such),
so what you are seeing really shouldn't happen. There is some event
in udev's event queue that is not processed in time, which is why
it takes so long for your system to boot. The proper way to fix
this is to figure out what event that is and why that is happening.
Most likely this is a bug in an udev rule that only triggers on
very few systems, also possible is a hardware problem (in which
case you'd want to know about that earlier rather than late).
Therefore, you should try booting with the following kernel
options but with the settle service still enabled:
udev.log-priority=debug udev.children-max=1
Then you should be able to see in the logs (after waiting >2min
for the system to boot ;-)) which event udev couldn't handle. Post
those here and we might be able to find a proper solution to your
problem.
Christian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774082
Reply to: