Bug 630914 - Single user mode reported as "unknown"
Summary: Single user mode reported as "unknown"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-07 10:55 UTC by Kamil Páral
Modified: 2014-03-17 03:24 UTC (History)
11 users (show)

Fixed In Version: initscripts-9.20.1-1.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-30 06:09:29 UTC


Attachments (Terms of Use)
dmesg (39.62 KB, text/plain)
2010-09-13 08:17 UTC, Kamil Páral
no flags Details
dmesg output just after booting to runlevel 1 (63.89 KB, text/plain)
2010-09-13 23:30 UTC, Ira Malinich
no flags Details
dmesg again (44.04 KB, text/plain)
2010-09-14 07:16 UTC, Kamil Páral
no flags Details
systemctl --list-jobs (7.02 KB, image/png)
2010-09-14 12:48 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2010-09-07 10:55:15 UTC
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.

Comment 1 He Rui 2010-09-08 09:35:54 UTC
Reproduced

Comment 2 Ira Malinich 2010-09-08 18:20:57 UTC
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.

Comment 3 Lennart Poettering 2010-09-12 20:06:28 UTC
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?

Comment 4 Lennart Poettering 2010-09-12 20:11:54 UTC
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?

Comment 5 Lennart Poettering 2010-09-12 20:13:16 UTC
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?

Comment 6 Kamil Páral 2010-09-13 08:16:31 UTC
(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.

Comment 7 Kamil Páral 2010-09-13 08:17:32 UTC
Created attachment 446856 [details]
dmesg

Booted with "systemd.log_target=kmsg systemd.log_level=debug 1". "runlevel" still reports "unknown".

Comment 8 Lennart Poettering 2010-09-13 20:17:23 UTC
Hmm, seems the utmp-update service is never actually added to the initial transaction. This fix should be simple.

Comment 9 Lennart Poettering 2010-09-13 22:33:32 UTC
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"?

Comment 10 Ira Malinich 2010-09-13 23:30:44 UTC
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.

Comment 11 Kamil Páral 2010-09-14 07:16:27 UTC
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.

Comment 12 Lennart Poettering 2010-09-14 11:49:02 UTC
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?

Comment 13 Kamil Páral 2010-09-14 12:48:10 UTC
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.

Comment 14 Bill Nottingham 2010-09-14 16:00:32 UTC
(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.

Comment 15 Lennart Poettering 2010-09-14 16:05:26 UTC
ExecStopPost= should be the right solution here.

Comment 16 Bill Nottingham 2010-09-14 16:28:09 UTC
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

Comment 17 Fedora Update System 2010-09-27 20:03:02 UTC
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

Comment 18 Fedora Update System 2010-09-28 17:32:51 UTC
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

Comment 19 Fedora Update System 2010-09-30 06:09:07 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.