You are not logged in.
Hi Community,
I tried to disable the legacy rc-local.service, provided by initscripts.
$ systemctl disable rc-local.service
This resulted in a black screen and I was thrown to TTY 1. The xorg server was still running, so I could switch back to "TTY 7".
But I had to notice that systemctl stopped working and whatever I tried, it resulted in the following error message:
$ systemctl status rc-local
Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
$
Even when I try to restart dbus, I get:
$ systemctl restart dbus
Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Okay, who is to blame for this crap? And how can I get again a working systemctl?
Edit: I should mention that the system has already rebootet several times since the installation of systemd. Further I should mention, that EVERY single call of systemctl results in the error message above.
Thanks!
Last edited by indianahorst (2012-10-30 21:18:18)
Offline
Okay, who is to blame for this crap? And how can I get again a working systemctl?
With that sort of attitude, I'd be surprised if anyone was willing to help you...
Offline
Did you, perchance, try to run that with root permissions?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Did you, perchance, try to run that with root permissions?
Systemctl status does not require root permissions, but it failed with the same error message.
systemctl disable rc-local.service
This resulted in a black screen and I was thrown to TTY 1
As the rc-local.service is NOT stopped by the 'disable' command , this is unexpected.
This call implicitly reloads the systemd daemon configuration
after completing the disabling of the units. Note that this command does not implicitly stop the units that is being disabled. If this is desired an
additional stop command should be executed afterwards.
The problems usually show up after rebooting, but in this case you get the black screen immediatly?
Offline
ewaller wrote:Did you, perchance, try to run that with root permissions?
Systemctl status does not require root permissions, but it failed with the same error message.
Yes. And no.
If running it with root permissions had worked, we would be going off in a different direction. For it to not need root permissions, systemd-login has to be active for the session. Does not seem to necessarily be the case
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Did you, perchance, try to run that with root permissions?
Yes, every execution of systemctl was done as root.
Offline
The problems usually show up after rebooting, but in this case you get the black screen immediatly?
Yes, the black screen and then TTY1 came immediatly after the execution of "systemctl disable rc-local.service"
Now I tried to reboot and found out that systemd itself seems to have died:
Rebooting via the XFCE button "Restart" throw me again to TTY1. I logged in as root and tried to reboot:
$ reboot
Failed to open /dev/initctl: No such device or adress
Failed to talk to init daemon
$
Offline
Edit: I should mention that the system has already rebootet several times since the installation of systemd. Further I should mention, that EVERY single call of systemctl results in the error message above.
Installation of systemd is not sufficient, you need to actually activate it. Here's a quick test that tells if you use systemd:
$ cat /proc/1/comm
systemd
Another quick test:
$ findmnt | grep /sys/fs/cgroup
│ ├─/sys/fs/cgroup tmpfs tmpfs rw,nosuid,nodev,noexec,mode=755
│ │ ├─/sys/fs/cgroup/systemd cgroup cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
│ │ ├─/sys/fs/cgroup/cpuset cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuset
│ │ ├─/sys/fs/cgroup/cpu,cpuacct cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu
│ │ ├─/sys/fs/cgroup/devices cgroup cgroup rw,nosuid,nodev,noexec,relatime,devices
│ │ ├─/sys/fs/cgroup/freezer cgroup cgroup rw,nosuid,nodev,noexec,relatime,freezer
│ │ ├─/sys/fs/cgroup/net_cls cgroup cgroup rw,nosuid,nodev,noexec,relatime,net_cls
│ │ └─/sys/fs/cgroup/blkio cgroup cgroup rw,nosuid,nodev,noexec,relatime,blkio
Offline
I was seeing systemd from "cat /proc/1/comm"
but wasnt seing any control groups /sys/fs/cgroup.
Solution was to update my kernel
Last edited by bx (2012-11-27 21:56:21)
Offline
I was seeing systemd from "cat /proc/1/comm"
but wasnt seing any control groups /sys/fs/cgroup.Solution was to update my kernel
How old was it?
Offline
How old was it?
Seriously old!! Specifically v2.6.39. It's a linode hosted server - never even thought to check the kernel version...
I had something crazy like 300+ day uptime and was really resistent to any sort of activity that would require a reboot.
Good news is they make it stupid easy to do an update and I'm currently at 3.6.5.
Offline
IIRC, you can even use Arch's kernel with linode. In particular (according to a friend who I talked to several years ago), linode allows using pv-grub, which will read a grub configuration file and boot a kernel from the guest hard drive - and the Arch x86_64 kernel has Xen support (you need to configure mkinitcpio.conf properly to have xenblock support, and drive names change etc etc.). No idea if that still works, but I know it used to work.
Offline