Description of problem: systemd-tmpfiles-setup.service fails in runlevel 3 # systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: failed since Tue, 06 Dec 2011 23:06:36 -0600; 1h 58min ago Process: 817 ExecStart=/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. clean install 2. apply all updates 3. add 3 to end of kernel line in menu.lst 4. reboot 5. systemctl status systemd-tmpfiles-setup.service
Blocks: (none) => 2120
Created attachment 1194 [details] Change legacy.conf to use group root instead of non-existent group lock It happens in run level 5 as well. The attached patch corrects the problem.
(In reply to comment #1) > Created attachment 1194 [details] > Change legacy.conf to use group root instead of non-existent group lock > > It happens in run level 5 as well. The attached patch corrects the problem. Hmmm, seems like a lot of change there. Why not create the lock group. See https://bugs.mageia.org/show_bug.cgi?id=3551 comment link. :)
The only reason for the usage of the group lock, is to make the directory group writable. As we don't have the group, we obviously have no login ids in the group, to be given the write permission, so creating the group will not actually do anything. It's a one line change.
CC: (none) => davidwhodgins
(In reply to comment #3) > The only reason for the usage of the group lock, is to make the > directory group writable. Agree. > As we don't have the group, we obviously > have no login ids in the group, to be given the write permission, You can have groups without logins. > so creating the group will not actually do anything. Well, I not telling my system that. I did a "groupadd -r lock" and next boot time was cut in half. > It's a one line change. Yes, and if you look at https://qa.mandriva.com/show_bug.cgi?id=63081#c3 you will see Mandriva's solution is to add the group.
(In reply to comment #4) > (In reply to comment #3) > > so creating the group will not actually do anything. > Well, I not telling my system that. I did a "groupadd -r lock" and next boot > time was cut in half. Can you confirm that by removing the group, and see if the boot time goes back up? On my system, applying the patch made no difference. Booting to run level 3 on my 6+ year old Celeron system has Startup finished in 878ms 916us (kernel) + 9s 379ms 706us (initrd) + 1min 5s 338ms 492us (userspace) = 1min 15s 597ms 114us I'm inclined to think something else caused the change in boot time.
(In reply to comment #5) > Booting to run level 3 on my 6+ year old Celeron system has > Startup finished in 878ms 916us (kernel) + 9s 379ms 706us (initrd) + 1min 5s > 338ms 492us (userspace) = 1min 15s 597ms 114us Must be nice. Your's is faster than my Socket: 939 with AMD Athlon(tm) 64 Processor 3800+ > I'm inclined to think something else caused the change in boot time. Yeah, just pulled in some updates, had disable a bunch of daemons, received your reply and noticed system now pauses at Starting apply kernel variables. :( removed group lock0 reboot Dec 7 19:07:44 localhost systemd[1]: Startup finished in 15s 858ms 108us (kernel) + 1min 11s 160ms 325us (userspace) = 1min 27s 18ms 433us. added group lock reboot Dec 7 19:11:45 localhost systemd[1]: Startup finished in 15s 879ms 796us (kernel) + 1min 22s 693ms 345us (userspace) = 1min 38s 573ms 141us. I am no longer seeing same prompts after Disable IRQ #19 So I know I can login. Still getting my stack trace though. :-/ https://bugs.mageia.org/show_bug.cgi?id=3667
(In reply to comment #5) > I'm inclined to think something else caused the change in boot time. Whew, thought I was going crazy. Yes I am going to agree, but here is the kicker. With group lock, files are created which were needed. After lock removal test shot and putting it back, you saw that my time increased. :( Clean install, installed even more updates, rebooted. Wiped messages. Rebooted, added lock, rebooted. Got a 2 minute 20 second improvement. :) Dec 8 04:24:55 localhost systemd[1]: Startup finished in 15s 834ms 290us (kernel) + 2min 49s 478ms 129us (userspace) = 3min 5s 312ms 419us. Dec 8 04:27:45 localhost systemd[1]: Startup finished in 15s 872ms 212us (kernel) + 1min 9s 906ms 157us (userspace) = 1min 25s 778ms 369us.
can you test with systemd 39 ?
CC: (none) => dmorganec
Resolution was yet another clean install, apply updates, reboot. Jan 27 00:48:23 wb2 systemd[1]: Startup finished in 600ms 279us (kernel) + 4s 764ms 465us (initrd) + 24s 756ms 206us (userspace) = 30s 120ms 950us. # systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: active (exited) since Fri, 27 Jan 2012 00:48:12 -0600; 23min ago Process: 1345 ExecStart=/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
Status: NEW => RESOLVEDResolution: (none) => FIXED