Description of problem: Tried https://fedoraproject.org/wiki/QA:Testcase_initialization_basic. When booted with 1,single,s,S or -s kernel option, I get into single user mode. Running 'telinit' or 'who -r' reports runlevel "unknown". # runlevel unknown Version-Release number of selected component (if applicable): systemd-9-3.fc14.x86_64 systemd-units-9-3.fc14.x86_64 systemd-sysvinit-9-3.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. Boot kernel with option '1' 2. Run 'runlevel' 3.
Reproduced
For me, any change to runlevel 1 fails to update the current runlevel reported by the "runlevel" command. For example, starting in runlevel 5 and running "telinit 1" causes "runlevel" to report "N 5" as if the runlevel hasn't changed, though X has been stopped.
Hmm, I cannot reproduce this here. if I boot into single user mode by passing "1" on the kernel cmdline and type "runlevel" the output is "N S" for me. Kamil, could you pass "systemd.log_target=kmsg systemd.log_level=debug 1" in the kernel cmdline, then check "runlevel" and attach the output of dmesg" run afterwards here?
Hmm, and if I then do "systemctl default", and from there return to single user mode with "telinit 1", then runlevel correctly returns "5 S" too. So everything seems to work fine here. Kamal (or Ira), an output of dmesg as described in comment 3 would be very useful for me to track down the issue even if i cannot reproduce it myself. One question: do you have /var on a seperate partition?
On more question: (In reply to comment #0) > When booted with 1,single,s,S or -s kernel option, I get into single user mode. > Running 'telinit' or 'who -r' reports runlevel "unknown". "telinit"? That doesn't show the runlevel. Do you mean the "runlevel" command here?
(In reply to comment #5) > > "telinit"? That doesn't show the runlevel. Do you mean the "runlevel" command > here? That's a typo, I meant 'runlevel', yes. I don't have /var on a separate partition.
Created attachment 446856 [details] dmesg Booted with "systemd.log_target=kmsg systemd.log_level=debug 1". "runlevel" still reports "unknown".
Hmm, seems the utmp-update service is never actually added to the initial transaction. This fix should be simple.
Hmpf, I am blind, of course it is added. The output seems to be incomplete. It doesn't show the rescue shell actually be spawned. Have you made sure to attach the full output of "dmesg" when run with "systemd.log_target=kmsg systemd.log_level=debug 1"?
Created attachment 447088 [details] dmesg output just after booting to runlevel 1 I've attached my own dmesg dump. I added the logging parameters and confirmed that "runlevel" reports the current runlevel as "unknown" before directing the output of "dmesg" to a file.
Created attachment 447168 [details] dmesg again Oh, at first I attached /var/log/dmesg, but that's different from the output of dmesg command, right? Attached again, this time after running the command.
OK, this is brokeness in the initscripts package: it sets Type=oneshot instead of Type=simple. The effect of this is that the sinlge user mode will not be reached until the shell is run and finished. Because systemd-update-utmp-runlevel.service is ordered after the single user mode is fully reached it is waiting until the shell has finished before writing the runlevel. That of course means that inside the shell the runlevel will not have been written. Bill, please remove Type=oneshot from single.service (the default is Type=simple, anyway). Bill, what's the rationale for setting Type=oneshot? To suppress concurrent output on the console a bit? If so, then we could perhaps introduce EnableConsoleStatus= which could be set in the individual unit files to disable the console status message for them. That way we could disable this spew for the glue services such as systemd-update-utmp-runlevel.service and the like. Suggestions? Kamil, Ira, if what I wrote above is right, then you should see some queued jobs in "systemctl list-jobs" when you type that into the rescue shell prompt, right?
Created attachment 447207 [details] systemctl --list-jobs (In reply to comment #12) > Kamil, Ira, if what I wrote above is right, then you should see some queued > jobs in "systemctl list-jobs" when you type that into the rescue shell prompt, > right? I suppose so. See screenshot.
(In reply to comment #12) > Bill, what's the rationale for setting Type=oneshot? That's the only way it works. More seriously, to automatically return to the default state, we set 'ExecStartPost=/bin/systemctl default' in single.service. If Type is *not* oneshot, this is executed concurrently, which removes the single-user shell out from under you before it starts.
ExecStopPost= should be the right solution here.
Doh. Of course it is. Not sure where that got lost when I originally set it up. http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=e7d5d1b861f4826d5b564df9a8efff8e7c25fb83
initscripts-9.20.1-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/initscripts-9.20.1-1.fc14
initscripts-9.20.1-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/initscripts-9.20.1-1.fc14
initscripts-9.20.1-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.