[arch-general] at times when booting system-logind fails and system hangs
I haven't identified under which circumstances, when booting the system hangs, and the only thing that can be related to that is the message:
Failed to start Login Service
Of course the recommendation to see the output of:
systemctl status systemd-logind.service
Is useless when that happens. That because the system hangs.
A phisical hard power down is what I've done, and then usually by starting the system again everything works.
Has anyone experienced this? Any suggestion?
Thanks,
On 04/29/2015 05:40 PM, Javier Vasquez wrote:
I haven't identified under which circumstances, when booting the system hangs, and the only thing that can be related to that is the message:
Failed to start Login Service ...
Yes I have seen this but only on one of my computers (laptop, wireless system account (starts at boot)).
My working hypothesis is a systemd race condition of some kind - but for life of me I have not been able to figure it out. Hard rebooting has always booted fine after the hang.
So yes, seen it but not been able to identify the root cause.
Gene
On Wednesday, April 29, 2015 03:40:33 PM Javier Vasquez wrote:
I haven't identified under which circumstances, when booting the system hangs, and the only thing that can be related to that is the message:
Failed to start Login Service
Of course the recommendation to see the output of:
systemctl status systemd-logind.service
Is useless when that happens. That because the system hangs.
Systemd usually logs startup in journalctl. Can you post your journalctl output (from a time when you're sure you had the issue)?
A phisical hard power down is what I've done, and then usually by starting the system again everything works.
Has anyone experienced this? Any suggestion?
Not sure if I remember.
Thanks,
Regards, Mark
On Wed, Apr 29, 2015 at 3:51 PM, Mark Lee mark@markelee.com wrote: ... Systemd usually logs startup in journalctl. Can you post your journalctl output (from a time when you're sure you had the issue)?
Not sure how useful it is. Not sure if attaching the whole output, but here it goes what related to logind:
++++++++++ Apr 29 15:11:22 m1 systemd[1]: Starting Login Service... ... Apr 29 15:11:52 m1 systemd[1]: Unit systemd-logind.service entered failed state. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service failed. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. Apr 29 15:11:23 m1 systemd[1]: Starting Permit User Sessions... Apr 29 15:11:23 m1 systemd[1]: Started D-Bus System Message Bus. Apr 29 15:11:52 m1 systemd-logind[383]: Failed to enable subscription: Connection timed out Apr 29 15:11:52 m1 systemd-logind[383]: Failed to fully start up daemon: Connection timed out Apr 29 15:11:52 m1 systemd[1]: Failed to register name: Connection timed out Apr 29 15:11:52 m1 systemd[1]: Failed to set up API bus: Connection timed out Apr 29 15:11:52 m1 systemd[1]: Starting D-Bus System Message Bus... ... Apr 29 15:11:52 m1 systemd[1]: Looping too fast. Throttling execution a little. ... Apr 29 15:11:55 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:11:56 m1 python[515]: warning: python-dbus not installed. Apr 29 15:11:56 m1 /hp-config_usb_printer[515]: [515]: warning: python-dbus not installed. Apr 29 15:11:56 m1 python[515]: warning: Failed to Import DBUS ... Apr 29 15:11:56 m1 python[515]: error: This is not a valid device Apr 29 15:11:56 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:11:57 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:11:58 m1 systemd[1]: Looping too fast. Throttling execution a little. ... Apr 29 15:12:20 m1 dbus[394]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out Apr 29 15:12:20 m1 dbus[394]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' ... Apr 29 15:12:20 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:12:21 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:12:22 m1 systemd[1]: Looping too fast. Throttling execution a little. ... Apr 29 15:12:44 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:12:45 m1 dbus[394]: [system] Failed to activate service 'org.freedesktop.ColorManager': timed out Apr 29 15:12:45 m1 systemd[1]: Looping too fast. Throttling execution a little. ... Apr 29 15:13:42 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:13:43 m1 systemd[1]: Looping too fast. Throttling execution a little. Apr 29 15:13:44 m1 systemd[1]: Looping too fast. Throttling execution a little. ++++++++++
I don't find this output that insightful, :-)
If you'd like to see the whole output, it's 1267 lines long. Let me know if you might look at an attachement...
-- Javier
On Wednesday, April 29, 2015 07:17:53 PM Javier Vasquez wrote:
On Wed, Apr 29, 2015 at 3:51 PM, Mark Lee mark@markelee.com wrote: ... Systemd usually logs startup in journalctl. Can you post your journalctl output (from a time when you're sure you had the issue)?
Not sure how useful it is. Not sure if attaching the whole output, but here it goes what related to logind:
++++++++++ Apr 29 15:11:22 m1 systemd[1]: Starting Login Service... ... Apr 29 15:11:52 m1 systemd[1]: Unit systemd-logind.service entered failed state. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service failed. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. Apr 29 15:11:23 m1 systemd[1]: Starting Permit User Sessions... Apr 29 15:11:23 m1 systemd[1]: Started D-Bus System Message Bus. Apr 29 15:11:52 m1 systemd-logind[383]: Failed to enable subscription: Connection timed out Apr 29 15:11:52 m1 systemd-logind[383]: Failed to fully start up daemon: Connection timed out
Can you post the output of your /etc/logind.conf?
Regards, Mark
On Wed, Apr 29, 2015 at 7:58 PM, Mark Lee mark@markelee.com wrote: ...
Can you post the output of your /etc/logind.conf?
Regards, Mark
Weird, I don't remember removing that file, but it's not there. I remember I had in it the with the power button I wanted reboot, that the Lid close did nothing, and maybe one more thing... Not sure why I no longer have it.
But any ways, not there...
logind.conf is in /etc/systemd
On 04/29/2015 08:58 PM, Mark Lee wrote:
On Wednesday, April 29, 2015 07:17:53 PM Javier Vasquez wrote:
On Wed, Apr 29, 2015 at 3:51 PM, Mark Lee mark@markelee.com wrote: ... Systemd usually logs startup in journalctl. Can you post your journalctl output (from a time when you're sure you had the issue)?
Not sure how useful it is. Not sure if attaching the whole output, but here it goes what related to logind:
++++++++++ Apr 29 15:11:22 m1 systemd[1]: Starting Login Service... ... Apr 29 15:11:52 m1 systemd[1]: Unit systemd-logind.service entered failed state. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service failed. Apr 29 15:11:52 m1 systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. Apr 29 15:11:23 m1 systemd[1]: Starting Permit User Sessions... Apr 29 15:11:23 m1 systemd[1]: Started D-Bus System Message Bus. Apr 29 15:11:52 m1 systemd-logind[383]: Failed to enable subscription: Connection timed out Apr 29 15:11:52 m1 systemd-logind[383]: Failed to fully start up daemon: Connection timed out
Can you post the output of your /etc/logind.conf?
Regards, Mark
On Wed, Apr 29, 2015 at 8:30 PM, Marshall Neill ramien43@windstream.net wrote:
logind.conf is in /etc/systemd
Yeap:
% grep '^[^#]' /etc/systemd/logind.conf [Login] HandlePowerKey=reboot HandleLidSwitch=ignore
The rest are commentaries...
-- Javier
On Wednesday, April 29, 2015 09:21:10 PM Javier Vasquez wrote:
On Wed, Apr 29, 2015 at 8:30 PM, Marshall Neill ramien43@windstream.net
wrote:
logind.conf is in /etc/systemd
Yeap:
% grep '^[^#]' /etc/systemd/logind.conf [Login] HandlePowerKey=reboot HandleLidSwitch=ignore
The rest are commentaries...
-- Javier
What's your kernel cmdline? What's your initcpio hooks?
Regards, Mark
On Wed, Apr 29, 2015 at 9:25 PM, Mark Lee mark@markelee.com wrote: ...
What's your kernel cmdline? What's your initcpio hooks?
Regards, Mark
My "grub" stuff to call linux (the kernel):
echo 'Loading Linux linux ...' linux /vmlinuz-linux root=UUID=<root_partition_uuid> rw rootwait rootfstype=ext4 resume=UUID=<swap_partition_uuid> echo 'Loading initial ramdisk ...' initrd /intel-ucode.img /initramfs-linux.img
My hooks line in /etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block resume filesystems keyboard fsck"
On Thursday, April 30, 2015 11:29:18 AM Javier Vasquez wrote:
echo 'Loading Linux linux ...' linux /vmlinuz-linux root=UUID=<root_partition_uuid> rw rootwaitrootfstype=ext4 resume=UUID=<swap_partition_uuid>
This is unrelated, but does Arch Linux respect rootwait?
echo 'Loading initial ramdisk ...' initrd /intel-ucode.img /initramfs-linux.imgMy hooks line in /etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block resume filesystems keyboard fsck"
I don't see any issues in there that'd cause your systemd issues. Did you try reinstalling systemd?
Regards, Mark
I ran into the same problem this morning unfortunately :(
The relevant journalctl output (it is quite similar to Javier's)
================= journalctl =================== May 01 12:50:13 archM systemd[1]: Listening on D-Bus System Message Bus Socket. May 01 12:50:13 archM systemd[1]: Starting D-Bus System Message Bus Socket. ... May 01 12:50:13 archM systemd[1]: Starting Login Service... ... May 01 12:50:42 archM dbus[286]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service' May 01 12:50:42 archM systemd[1]: Unit systemd-logind.service entered failed state. May 01 12:50:42 archM systemd[1]: systemd-logind.service failed. May 01 12:50:42 archM systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. ... May 01 12:50:41 archM systemd-logind[279]: Failed to enable subscription: Connection timed out May 01 12:50:41 archM systemd-logind[279]: Failed to fully start up daemon: Connection timed out May 01 12:50:41 archM systemd[1]: Failed to register name: Connection timed out May 01 12:50:41 archM systemd[1]: Failed to set up API bus: Connection timed out May 01 12:50:41 archM systemd[1]: Starting D-Bus System Message Bus... ... May 01 12:51:05 archM systemd[1]: Looping too fast. Throttling execution a little. May 01 12:51:07 archM systemd[1]: Looping too fast. Throttling execution a little. May 01 12:51:07 archM dbus[286]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out May 01 12:51:07 archM ModemManager[275]: <warn> failed to create PolicyKit authority: 'Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached'
May 01 12:51:07 archM NetworkManager[276]: <error> [1430464867.217039] [nm-auth-manager.c:449] _dbus_new_proxy_cb(): auth: could not get polkit proxy: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out
May 01 12:51:05 archM systemd[1]: Looping too fast. Throttling execution a little. May 01 12:51:07 archM systemd[1]: Looping too fast. Throttling execution a little. May 01 12:51:07 archM dbus[286]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out .... May 01 12:51:08 archM systemd[1]: Looping too fast. Throttling execution a little. May 01 12:51:08 archM dbus[286]: [system] Failed to activate service 'fi.w1.wpa_supplicant1': timed out ...
====================================
Every line in /etc/systemd/logind.conf is commented out ------- $ grep '^[^#]' /etc/systemd/logind.conf [Login] -------
For me, multiple (3-4 times) reboots did not fix it, the systemd-logind service failed each time and I never saw any of the ttys or display manager (sddm). I was able to do some basic debugging and use pacman via the systemd debug shell on tty9
As per the pacman logs systemd 219 was installed on 24th and I have booted up the machine at least a couple of times since then but only hit the issue this morning.
----- [2015-04-24 23:31] [ALPM] upgraded systemd (219-5 -> 219-6) -----
I am not sure whether it is related but the difference between booting the machine yesterday and this morning, were these package upgrades from last night.
----------------
[2015-05-01 01:12] [PACMAN] starting full system upgrade [2015-05-01 01:12] [ALPM] transaction started [2015-05-01 01:12] [ALPM] upgraded readline (6.3.006-1 -> 6.3.008-1) [2015-05-01 01:12] [ALPM] upgraded kdelibs (4.14.7-1 -> 4.14.7-2) [2015-05-01 01:12] [ALPM] upgraded kdebase-lib (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kio (5.9.0-1 -> 5.9.0-2) [2015-05-01 01:13] [ALPM] upgraded kdebase-dolphin (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kdebase-kdialog (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kdebase-keditbookmarks (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kdebase-kfind (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kdebase-konqueror (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded kdebase-konq-plugins (15.04.0-2 -> 15.04.0-3) [2015-05-01 01:13] [ALPM] upgraded mlt (0.9.6-5 -> 0.9.6-6) [2015-05-01 01:13] [ALPM] transaction completed
----------------
Using pacman via the debug shell I downgraded these packages and reinstalled polkit, polkit-kde and polkit-kde-frameworks. ---------------- [2015-05-01 14:41] [ALPM] transaction started [2015-05-01 14:41] [ALPM] downgraded readline (6.3.008-1 -> 6.3.006-1) [2015-05-01 14:41] [ALPM] downgraded kdelibs (4.14.7-2 -> 4.14.7-1) [2015-05-01 14:41] [ALPM] downgraded kdebase-lib (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kio (5.9.0-2 -> 5.9.0-1) [2015-05-01 14:41] [ALPM] downgraded kdebase-dolphin (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kdebase-kdialog (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kdebase-keditbookmarks (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kdebase-kfind (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kdebase-konqueror (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded kdebase-konq-plugins (15.04.0-3 -> 15.04.0-2) [2015-05-01 14:41] [ALPM] downgraded mlt (0.9.6-6 -> 0.9.6-5) [2015-05-01 14:41] [ALPM] transaction completed ..... [2015-05-01 14:43] [ALPM] transaction started [2015-05-01 14:43] [ALPM] reinstalled polkit (0.112-2) [2015-05-01 14:43] [ALPM] reinstalled polkit-kde-frameworks (5.2.2-1) [2015-05-01 14:43] [ALPM] reinstalled polkit-kde (0.99.0-5) [2015-05-01 14:43] [ALPM] transaction completed ----------------
After that my system booted up normally as it had done yesterday (with the ttys and sddm)
Sorry for the long post !
On Fri, May 1, 2015 at 4:11 AM, Mark Lee mark@markelee.com wrote: ...
This is unrelated, but does Arch Linux respect rootwait?
Linux does, :-) I don't need on this laptop, but I have Arch also on a USB disk, and for that one, at times linux doesn't find root, so I found it just needed to wait for it to become available...
I don't see any issues in there that'd cause your systemd issues. Did you try reinstalling systemd?
No I haven't. Though I wouldn't suppose such re-install (if no new version implied) would help. I'll upgrade Arch to see. The other option is to tried the systemd patches, or the patched systemd offered by Christian. I haven't done that either...
Regards, Mark
Thanks,
On Fri, May 1, 2015 at 6:10 PM, Javier Vasquez j.e.vasquez.v@gmail.com wrote:
On Fri, May 1, 2015 at 4:11 AM, Mark Lee mark@markelee.com wrote: ...
This is unrelated, but does Arch Linux respect rootwait?
Linux does, :-) I don't need on this laptop, but I have Arch also on a USB disk, and for that one, at times linux doesn't find root, so I found it just needed to wait for it to become available...
I don't see any issues in there that'd cause your systemd issues. Did you try reinstalling systemd?
No I haven't. Though I wouldn't suppose such re-install (if no new version implied) would help. I'll upgrade Arch to see. The other option is to tried the systemd patches, or the patched systemd offered by Christian. I haven't done that either...
For what it's worth I've been having these same issues. systemd-logind fails to start with "connection timed out" and then everything is useless until the machine is reset. On most of my machines it happens in maybe 1 out of every 10 boots, but on one of my machines it's *every* boot. I can't figure out what's causing it, even with systemd.log_level=debug.
I'm noticing that right before the systemd-logind timeout messages it tries to start "dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation" -- it seems like this should have happened much earlier though, when dbus.socket started. Or am I misunderstanding the relationship between dbus.socket and dbus.service?
- Steven
On 09/05/15 00:03, Steven Noonan wrote:
On Fri, May 1, 2015 at 6:10 PM, Javier Vasquez j.e.vasquez.v@gmail.com wrote:
On Fri, May 1, 2015 at 4:11 AM, Mark Lee mark@markelee.com wrote: ...
This is unrelated, but does Arch Linux respect rootwait?
Linux does, :-) I don't need on this laptop, but I have Arch also on a USB disk, and for that one, at times linux doesn't find root, so I found it just needed to wait for it to become available...
I don't see any issues in there that'd cause your systemd issues. Did you try reinstalling systemd?
No I haven't. Though I wouldn't suppose such re-install (if no new version implied) would help. I'll upgrade Arch to see. The other option is to tried the systemd patches, or the patched systemd offered by Christian. I haven't done that either...
For what it's worth I've been having these same issues. systemd-logind fails to start with "connection timed out" and then everything is useless until the machine is reset. On most of my machines it happens in maybe 1 out of every 10 boots, but on one of my machines it's *every* boot. I can't figure out what's causing it, even with systemd.log_level=debug.
I'm noticing that right before the systemd-logind timeout messages it tries to start "dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation" -- it seems like this should have happened much earlier though, when dbus.socket started. Or am I misunderstanding the relationship between dbus.socket and dbus.service?
- Steven
I made some research some time ago and I found this: http://cgit.freedesktop.org/systemd/systemd/commit/?id=13790add4bf64 which seems that is the commit that make a regression in journald. That causes boot failures due to logind. This Debian bug report has more information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970
So applying this patch in systemd package should avoid the bug: http://hastebin.com/idaquqarud.coffee
Just add to prepare() in the PKGBUILD. Something like this: http://hastebin.com/roqabepilo.vhdl
I've been running this patched version for a few months and it works fine.
Joan Figueras
On Fri, May 8, 2015 at 3:45 PM, Figue ffigue@gmail.com wrote:
On 09/05/15 00:03, Steven Noonan wrote:
On Fri, May 1, 2015 at 6:10 PM, Javier Vasquez j.e.vasquez.v@gmail.com wrote:
On Fri, May 1, 2015 at 4:11 AM, Mark Lee mark@markelee.com wrote: ...
This is unrelated, but does Arch Linux respect rootwait?
Linux does, :-) I don't need on this laptop, but I have Arch also on a USB disk, and for that one, at times linux doesn't find root, so I found it just needed to wait for it to become available...
I don't see any issues in there that'd cause your systemd issues. Did you try reinstalling systemd?
No I haven't. Though I wouldn't suppose such re-install (if no new version implied) would help. I'll upgrade Arch to see. The other option is to tried the systemd patches, or the patched systemd offered by Christian. I haven't done that either...
For what it's worth I've been having these same issues. systemd-logind fails to start with "connection timed out" and then everything is useless until the machine is reset. On most of my machines it happens in maybe 1 out of every 10 boots, but on one of my machines it's *every* boot. I can't figure out what's causing it, even with systemd.log_level=debug.
I'm noticing that right before the systemd-logind timeout messages it tries to start "dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation" -- it seems like this should have happened much earlier though, when dbus.socket started. Or am I misunderstanding the relationship between dbus.socket and dbus.service?
- Steven
I made some research some time ago and I found this: http://cgit.freedesktop.org/systemd/systemd/commit/?id=13790add4bf64 which seems that is the commit that make a regression in journald. That causes boot failures due to logind. This Debian bug report has more information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970
So applying this patch in systemd package should avoid the bug: http://hastebin.com/idaquqarud.coffee
Just add to prepare() in the PKGBUILD. Something like this: http://hastebin.com/roqabepilo.vhdl
I've been running this patched version for a few months and it works fine.
Joan Figueras
I found a lead elsewhere about a different patch, and it unbroke the system that was reproing most frequently:
http://git.uplinklabs.net/snoonan/projects/archlinux/ec2/ec2-packages.git/co...
Here's mine which is a little different than yours [Login] #NAutoVTs=6 #ReserveVT=6 #KillUserProcesses=no #KillOnlyUsers= #KillExcludeUsers=root #Controllers= #ResetControllers=cpu #InhibitDelayMaxSec=5 HandlePowerKey=ignore HandleSuspendKey=ignore HandleHibernateKey=ignore HandleLidSwitch=ignore #PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no #LidSwitchIgnoreInhibited=yes
On 04/29/2015 10:21 PM, Javier Vasquez wrote:
On Wed, Apr 29, 2015 at 8:30 PM, Marshall Neill ramien43@windstream.net wrote:
logind.conf is in /etc/systemd
Yeap:
% grep '^[^#]' /etc/systemd/logind.conf [Login] HandlePowerKey=reboot HandleLidSwitch=ignore
The rest are commentaries...
-- Javier
On Wed, Apr 29, 2015 at 11:40 PM, Javier Vasquez j.e.vasquez.v@gmail.com wrote:
I haven't identified under which circumstances, when booting the system hangs, and the only thing that can be related to that is the message:
Failed to start Login Service
Of course the recommendation to see the output of:
systemctl status systemd-logind.service
Is useless when that happens. That because the system hangs.
A phisical hard power down is what I've done, and then usually by starting the system again everything works.
Has anyone experienced this? Any suggestion?
You can enable the debug shell with:
# systemctl enable debug-shell.service
And then when the boot fails, switch to the debugging shell with CTRL+ALT+F9 and get the status of the system:
# systemctl status systemd-logind.service # journalctl # systemctl list-jobs
Do not forget to disable the debug-shell.service when/if your problem is solved or it will become a big security hole.
On Wed, Apr 29, 2015 at 4:24 PM, Rodrigo Rivas rodrigorivascosta@gmail.com wrote: ...
You can enable the debug shell with:
# systemctl enable debug-shell.service
And then when the boot fails, switch to the debugging shell with CTRL+ALT+F9 and get the status of the system:
# systemctl status systemd-logind.service # journalctl # systemctl list-jobs
Do not forget to disable the debug-shell.service when/if your problem is solved or it will become a big security hole.
Do you by any chance know how to get a readable/writeable terminal? I couldn't read a thing, it was like very cryptic terminal... Just lots of symbols, but no letters.
Notice:
% grep Environment /etc/systemd/system/sysinit.target.wants/debug-shell.service Environment=TERM=linux Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=
Not sure if that's what's causing problems...
Javier Vasquez j.e.vasquez.v@gmail.com on Wed, 2015/04/29 15:40:
I haven't identified under which circumstances, when booting the system hangs, and the only thing that can be related to that is the message:
Failed to start Login Service
Of course the recommendation to see the output of:
systemctl status systemd-logind.service
Is useless when that happens. That because the system hangs.
A phisical hard power down is what I've done, and then usually by starting the system again everything works.
Has anyone experienced this? Any suggestion?
Possibly this is related:
FS#44016 - [systemd] journald regression in v219 makes boot hang https://bugs.archlinux.org/task/44016
You could try to rebuild system with patches included, see my upload of systemd.diff.
participants (9)
-
Christian Hesse
-
Figue
-
Genes Lists
-
Javier Vasquez
-
Mark Lee
-
Marshall Neill
-
nandan.reddevilz＠gmail.com
-
Rodrigo Rivas
-
Steven Noonan