On Wed, 23 Jul 2014, Ritesh Raj Sarraf wrote:
On 07/22/2014 07:55 PM, Matthew Gabeler-Lee wrote:
Changing the last line of /lib/udev/lmt-udev from:
) &
to:
) </dev/null >/dev/null 2>&1 &
detaches from those pipes, fixing the problem and producing a normal boot.
One fact that it never broke with the traditional SysV init justifies
that the problem lies in systemd.
Maybe. I could try putting sysvinit back on this system to see what
happens. I think it will still cause problems there, but the severetiy
may be lower.
The sysvinit scripts still wait for udev to settle, which would still
trip on this. The result, I think, would be a 2 minute delay in the
boot process, and then a race to see if udev could "catch up" and create
the device nodes before the init scripts try to mount the filesystems.
If this race is lost, I believe sysvinit would drop into an emergency
recovery shell, whereas systemd tries to limp along, and does mount the
filesystems when they show up (though many other aspects of startup fail
and stay failed).
systemd does have new ideas, which may be good for us, but they expect
changes in all other programs. If that is the case here, and the changes
are not going to break elsewhere, I may look into it.
I think the core of the problem here is not really with systemd, but
with the interaction between udev and LMT. I suppose you could consider
udev part of systemd to some extent now, but ...
Give me your thoughts... How should this be fixed. LMT
(laptop-mode-tools) gets triggered on kernel events. Now those events
could come through udev or anyone else. In your case, it is through udev.
Will increasing the timeout for lmt-udev solve the problem ? Can you run
some tests and conclude that ?
Actually, decreasing the timeout would help the boot process at the
expense of LMT not getting to process the devices at boot. Increasing
the timeout would not help, might make things worse.
The core of the problem, I think, is that lmt-udev is clearly intending
to detach itself from the udev daemon that spawns it, but is failing to
do so. I think the strategy it uses may have worked with prior versions
of udev, but changes in udev mean that the strategy is no longer
sufficient. I don't think those changes in udev were accidental, I
think they were deliberate design choices, so I don't think it can be
called a bug in udev.
I think the change I mentioned earlier (and quoted above) is a correct
and proper solution. It accomplishes the intent of detaching lmt-udev
from the spawning udev instance, allows udev and the rest of the boot
process (systemd or sysvinit) to continue normally, and allows LMT to
process the devices present at boot once /usr is mounted and the LMT
programs are available.
The only risk to it would be if there was error output from the script
that normally would be captured and logged by udev, this would prevent
that. It looks like LMT is designed to log to syslog directly, so if
there are errors they wouldn't be going to stdout/stderr anyways.
Given that udev didn't capture stdout/stderr before, and LMT logs on its
own, I think this risk can be ignored.
--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2AD1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
