Bug 752875
Summary: | at runlevel 3, only 1 getty is available | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew McNabb <amcnabb> | ||||
Component: | systemd | Assignee: | systemd-maint | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 16 | CC: | johannbg, lpoetter, metherid, mschmidt, notting, plautrba, systemd-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-12-14 02:31:11 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
systemd-logind.service loaded failed failed Login Service Try to find out why systemd-logind failed. Did it log anything to /var/log/messages? 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. systemd-logind failing is unrelated to sm-client. (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). Have you customized any settings in /etc/systemd/system.conf? What kernel version are you running? And please rule out the possibility of interference from SELinux by testing it in permissive more or disabled. (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 (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. Do you get anything interesting if you run /lib/systemd/systemd-logind directly as root? (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. :) 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 (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). By the way, at that point, running init 5 made my manually-run systemd-logind process quit without any error messages. 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? Bad runlevel switching behaviour is bug 708537. systemd-logind is a victim of the isolate action here. *** This bug has been marked as a duplicate of bug 708537 *** |
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