On 07/22/2014 07:55 PM, Matthew Gabeler-Lee wrote: > I do not, but /usr is on an LVM2 volume, and the combination of that and > a bug in the lmt-udev script is the key. > > Some experimentation with the systemd debug-shell service and copying > some key utilities from /usr to / has, I think, found the problem. > > The lmt-udev script is trying to detach itself from the udev daemon, but > it is failing to do so. Udev is running the script with a pipe > connected for stdout and stderr, and is (presumably) waiting for eof on > that pipe instead of waiting for the immediate child process to exit. > > Attached is the output of ps auxww, pstree -alp, and lsof -n from while > the boot is hung. You can see the pipes open and the original lmt-udev > processes in the zombie/defunct state. > > 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. 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. But right now, I really don't have the time to investigate this. Personal life is all that needs the attention right now. By the way, I use systemd on my box along with laptop-mode-tools. The only exception is that I do not have a separate /usr. 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 ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
