Component: systemd pid 1 OS: centos 7.0 Summary: systemd --system dbus interface not working after systemd received SIGQUIT (3) from root. E. g. `kill -SIGQUIT 1` by root leads to logging something like this: Dec 22 20:31:39 test systemd[1]: Caught <QUIT>, dumped core as pid 3871. Dec 22 20:31:39 test systemd[1]: Freezing execution. After that `systemctl` is useless since systemd isn't responding to dbus interface: [root@test ~]# systemctl reboot Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused Also, `reboot` doesn't work: [root@test ~]# reboot Failed to open /dev/initctl: No such device or address Failed to talk to init daemon. Reproduce: run `kill -SIGQUIT 1` under root. Env: - Linux test 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu Nov 6 15:06:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux - systemd-208-11.el7_0.5.x86_64 See also: https://gist.github.com/grossws/545fdcbc2c5d2703c89c
By comparison: sysvinit: doesn't catch/ignore SIGQUIT upstart: doesn't catch/ignore SIGQUIT openrc: catches SIGQUIT and then aborts I don't think systemd needs to change its behavior here. Doing this is already a privileged operation, and as such, there's limitless other ways of shooting yourself in the foot as well.
Well. And why precisely is that a problem? I mean, you had priviliges and asked systemd to die while coredumping, and that's precisely what it did. if you don't want it to die and coredump don't send a sigquit... Note that only sufficiently privileged processes can issue the sigquit hence there's no security problem here.
As I see in http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init.c?annotate=159&root=sysvinit (around line 1146) sysvinit set SIG_IGN for SIGQUIT. It seems that OpenRC isn't an init (it provides rc but not /sbin/init), so it's behavior depends on underlying sysvinit/bsd-init. I don't see any SIGQUIT handler in upstart (and libnih), so it should behave like systemd, with pid 1 core dumped and broken system after `kill -SIGQUIT 1`. It's not a security problem, of course. It's at most an usability problem. Is default core dump required for debugging systemd? Is there any reason not to ignore it?
(In reply to Konstantin Gribov from comment #3) > As I see in > http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/init. > c?annotate=159&root=sysvinit (around line 1146) sysvinit set SIG_IGN for > SIGQUIT. > > It seems that OpenRC isn't an init (it provides rc but not /sbin/init), so > it's behavior depends on underlying sysvinit/bsd-init. > > I don't see any SIGQUIT handler in upstart (and libnih), so it should behave > like systemd, with pid 1 core dumped and broken system after `kill -SIGQUIT > 1`. > > It's not a security problem, of course. It's at most an usability problem. > Is default core dump required for debugging systemd? Is there any reason not > to ignore it? Usability? I really don't see that. The usual expection on Unix is that SIGQUIT results in an abnormal process exit with a coredump. I really don't see why PID 1 should not support that too. It's not user-friendly to add different logic here to PID 1 without a really good reason for it.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.