Bug 752875 - at runlevel 3, only 1 getty is available
at runlevel 3, only 1 getty is available
Status: CLOSED DUPLICATE of bug 708537
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
16
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-10 12:17 EST by Andrew McNabb
Modified: 2011-12-13 21:31 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-13 21:31:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
output from systemctl (9.08 KB, text/plain)
2011-11-10 12:17 EST, Andrew McNabb
no flags Details

  None (edit)
Description Andrew McNabb 2011-11-10 12:17:18 EST
Created attachment 532886 [details]
output from systemctl

At runlevel 3, only a single getty is available by default, and getty instances are not automatically started when I switch to a new virtual terminal. In other words, if I switch between different vts, only one of them has a login prompt. At runlevel 5, I do not have this problem (getty instances automatically start when I switch to a new vt)

systemd-36-3.fc16.x86_64
Comment 1 Michal Schmidt 2011-11-11 03:23:00 EST
systemd-logind.service    loaded failed failed        Login Service

Try to find out why systemd-logind failed. Did it log anything to /var/log/messages?
Comment 2 Andrew McNabb 2011-11-11 11:30:29 EST
It looks like this might be related:

Nov 10 09:51:14 18potato systemd[1]: Failed to read PID file /run/sm-client.pid after start. The service might be broken.
Nov 10 09:51:17 18potato systemd[1]: systemd-logind.service: main process exited, code=exited, status=1
Nov 10 09:51:17 18potato systemd[1]: Unit systemd-logind.service entered failed state.
Comment 3 Bill Nottingham 2011-11-11 11:35:31 EST
systemd-logind failing is unrelated to sm-client.
Comment 4 Andrew McNabb 2011-11-11 11:45:57 EST
(In reply to comment #3)
> systemd-logind failing is unrelated to sm-client.

Then I can't find anything in the logs to indicate why it's in the failed state (likewise for a number of other services in the failed state).
Comment 5 Michal Schmidt 2011-11-11 18:23:16 EST
Have you customized any settings in /etc/systemd/system.conf?
What kernel version are you running?
Comment 6 Michal Schmidt 2011-11-11 18:30:07 EST
And please rule out the possibility of interference from SELinux by testing it in permissive more or disabled.
Comment 7 Andrew McNabb 2011-11-11 18:30:50 EST
(In reply to comment #5)
> Have you customized any settings in /etc/systemd/system.conf?

The only uncommented line in system.conf is "LogLevel=info" (in "[Manager]"), which as far as I can tell is now the default.

> What kernel version are you running?

kernel-3.1.0-7.fc16.x86_64
Comment 8 Andrew McNabb 2011-11-11 18:31:17 EST
(In reply to comment #6)
> And please rule out the possibility of interference from SELinux by testing it
> in permissive more or disabled.

SELinux is already disabled, so that should be ruled out.
Comment 9 Michal Schmidt 2011-11-14 04:26:46 EST
Do you get anything interesting if you run /lib/systemd/systemd-logind directly as root?
Comment 10 Andrew McNabb 2011-11-14 11:28:40 EST
(In reply to comment #9)
> Do you get anything interesting if you run /lib/systemd/systemd-logind directly
> as root?

# /lib/systemd/systemd-logind
Failed to acquire name.
Failed to fully start up daemon: File exists
# /lib/systemd/systemd-logind --help
This program takes no arguments.
# man systemd-logind
No manual entry for systemd-logind
#

Probably not what you were looking for. :)
Comment 11 Michal Schmidt 2011-11-14 11:47:59 EST
That's actually interesting because it indicates that another instance of systemd-logind is already running. What do these commands say?:
 systemctl show systemd-logind.service
 ps aux|grep logind
Comment 12 Andrew McNabb 2011-11-14 12:22:21 EST
(In reply to comment #11)
> That's actually interesting because it indicates that another instance of
> systemd-logind is already running. What do these commands say?:
>  systemctl show systemd-logind.service
>  ps aux|grep logind

Hmm. So it looks like systemd-logind got started again and the problem went away, too. I rebooted, and was again able to reproduce the problem. About reproducing the problem:

- The machine is configured to start in runlevel 3 (or the systemd equivalent).
- At boot, switching to different VTs works.
- If I do init 5 and then init 3, systemd-logind dies and switching to a different VT no longer gives a prompt.

When I run /lib/systemd/systemd-logind manually at this point, I see the following output:

"""New seat seat0.
New user gdm logged in.
New user amcnabb logged in.
New session 3 of user gdm.
Failed to reset controller cpu: No such process
Session 3 has display :1 with nonexisting socket /tmp/.X11-unix/X1.
New session 1 of user amcnabb.
Removed session 3.
"""

The "New session 1 of user amcnabb" seems to refer to an ssh session. I don't quite know why it reports gdm being logged in, but apparently there's a running pulseaudio process owned by gdm (why I don't know).
Comment 13 Andrew McNabb 2011-11-14 12:31:32 EST
By the way, at that point, running init 5 made my manually-run systemd-logind process quit without any error messages.
Comment 14 Andrew McNabb 2011-11-17 14:37:19 EST
I have also noticed that switching runlevels kills all open login sessions on VTs. In other words, if I'm logged in on tty3 and switch to a different runlevel with "init 3" or "init 5", then I get automatically logged out. Is this part of the same problem, or should I open a separate bug report?
Comment 15 Michal Schmidt 2011-11-18 11:12:14 EST
Bad runlevel switching behaviour is bug 708537.
Comment 16 Michal Schmidt 2011-12-13 21:31:11 EST
systemd-logind is a victim of the isolate action here.

*** This bug has been marked as a duplicate of bug 708537 ***

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