[arch-general] Polishing systemd
Hi all, I've been playing with systemd for a few hours now and I must say I'm impressed, it's a very powerful tool. I want to thanks the devs for making the transition to it really smooth :) Now, as I'm still learning my way through it -that means I'm reading a lot!- I find that there are in my system here and there some small rough edges I would like to fix, these rough edges are: 1. Units with errors shown in systemctl --all: arch-modules-load.service error inactive dead arch-modules auditd.service error inactive dead auditd.servi plymouth-quit-wait.service error inactive dead plymouth-qui plymouth-start.service error inactive dead plymouth-sta rc-local-shutdown.service error inactive dead rc-local-shu rc-local.service error inactive dead rc-local.ser syslog.service error inactive dead syslog.servi A journalctl --this-boot shows: Cannot add dependency job for unit arch-modules-load.service, ignoring: Unit arch-modules-load.service failed to load: No such file or directory. See system logs and 'systemctl status arch-modules-load.service' for details. That's because there isn't such file, right, but why is systemd trying to start it in first place? Since I strictly followed the wiki I don't know what I did wrong, in any case I would like to know how to fix them. By the way: what is the auditd.service? There's even isn't any related file in /lib/systemd/system. 2. KDE-related issues: a) It seems a bit buggy to launch KDE SC through xinit: KDE's power options will not be present (KDE will not enable it's own reboot and shutdown options). This don't really worry me too much since I've read somewhere there're plans to rebuild all login managers to systemd-logind enabled - while dropping ConsoleKit. b) If KDE is launched through xinit it will not see the built-in sound card and will offer to remove it from it's supported devices. Otherwise if KDE is initiated via KDM every- things works right. c) KDM reboot and poweroff commands must be updated to systemd's way or else the traditional shutdown command will hang the system on reboot/shutdown. 3. $ systemctl reboot and $ systemctl shutdown features: I feel a bit uncomfortable with the idea of having restricted users with the hability to reboot or shutdown the system, is there any way to change this so only r00t can issue these orders? (Without going dirty.) 4. Is there any place for e4rat(lite)? Since I activated systemd's built-in ureadahead feature, will e4rat still add any improve- ment? What do you say? I think that's all for now! Once again I want to thanks everyone involved in porting systemd to AL and making this an overall relaxed transition, systemd is an incredible tool and I'm delighted with it. Boot and shutdown times are faster than ever (blazing fast to be honest), configuration is quite clean and easy and the journal feature is incredible useful giving a *lot* of informa- tion about almost everything. Regards.
Am 16.10.2012 09:25, schrieb Martín Cigorraga:
1. Units with errors shown in systemctl --all: arch-modules-load.service error inactive dead arch-modules auditd.service error inactive dead auditd.servi plymouth-quit-wait.service error inactive dead plymouth-qui plymouth-start.service error inactive dead plymouth-sta rc-local-shutdown.service error inactive dead rc-local-shu rc-local.service error inactive dead rc-local.ser syslog.service error inactive dead syslog.servi
Some active services have Wants dependencies on those, I think. If you want a good overview over your systemd, rather look at 'systemctl --failed' and 'systemctl list-unit-files'.
A journalctl --this-boot shows: Cannot add dependency job for unit arch-modules-load.service, ignoring: Unit arch-modules-load.service failed to load: No such file or directory. See system logs and 'systemctl status arch-modules-load.service' for details.
That's because there isn't such file, right, but why is systemd trying to start it in first place?
No idea why it shows that, but arch-modules-load.service is part of initscripts.
2. KDE-related issues: a) It seems a bit buggy to launch KDE SC through xinit: KDE's power options will not be present (KDE will not enable it's own reboot and shutdown options). This don't really worry me too much since I've read somewhere there're plans to rebuild all login managers to systemd-logind enabled - while dropping ConsoleKit.
Reboot and Shutdown only work in KDE when you use kdm, not with xinit. There's some special care to be taken when using xinit/startx with logind - explained here: http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html
b) If KDE is launched through xinit it will not see the built-in sound card and will offer to remove it from it's supported devices. Otherwise if KDE is initiated via KDM every- things works right.
Same logind issue as above.
c) KDM reboot and poweroff commands must be updated to systemd's way or else the traditional shutdown command will hang the system on reboot/shutdown.
If you install systemd-sysvcompat (now the default), you can keep using KDM's default poweroff and reboot commands.
3. $ systemctl reboot and $ systemctl shutdown features: I feel a bit uncomfortable with the idea of having restricted users with the hability to reboot or shutdown the system, is there any way to change this so only r00t can issue these orders? (Without going dirty.)
Interesting, but I don't know. This may be a polkit setting. If you find out, I'd be interested.
On 10/16/12, Martín Cigorraga <msx@archlinux.us> wrote:
4. Is there any place for e4rat(lite)? Since I activated systemd's built-in ureadahead feature, will e4rat still add any improve- ment? What do you say?
I would suggest that you benchmark this for yourself. I found pretty good results using e4rat along with systemd readahead. It will end up taking quite a bit longer in "initrd" that way, but once it starts booting services end up taking a lot less time. A friend of mine, however, had bad results doing this, and found that Preload did a better job with Readahead and e4rat. He didn't have the benchmarks to back up his assertation tho. So ymmv, but make sure you're using some tool to benchmark the performance. What "feels" faster isn't always.
On Tue, Oct 16, 2012 at 9:19 AM, Joshua Collins <jeoshua@gmail.com> wrote:
On 10/16/12, Martín Cigorraga <msx@archlinux.us> wrote:
4. Is there any place for e4rat(lite)? Since I activated systemd's built-in ureadahead feature, will e4rat still add any improve- ment? What do you say?
I would suggest that you benchmark this for yourself. I found pretty good results using e4rat along with systemd readahead. It will end up taking quite a bit longer in "initrd" that way, but once it starts booting services end up taking a lot less time. A friend of mine, however, had bad results doing this, and found that Preload did a better job with Readahead and e4rat. He didn't have the benchmarks to back up his assertation tho.
That's was what I was looking for, thanks.
So ymmv, but make sure you're using some tool to benchmark the performance. What "feels" faster isn't always.
Totally, I will give'em a try then :) Regarding:
3. $ systemctl reboot and $ systemctl shutdown features: I feel a bit uncomfortable with the idea of having restricted users with the hability to reboot or shutdown the system, is there any way to change this so only r00t can issue these orders? (Without going dirty.)
Interesting, but I don't know. This may be a polkit setting. If you find out, I'd be interested. I was sugested in the #systemd channel that this may be associated with dbus: 06:31:17 Mithrandir | sounds like the dbus config isn't restrictive enough, you should get something like: 06:31:20 Mithrandir | > systemctl reboot 06:31:22 Mithrandir | Failed to issue method call: Access denied I'll keep you informed while I continue investigating this issue until I have enough info to file a bug.
Am 16.10.2012 20:15, schrieb Martín Cigorraga:
Interesting, but I don't know. This may be a polkit setting. If you find out, I'd be interested.
I was sugested in the #systemd channel that this may be associated with dbus: 06:31:17 Mithrandir | sounds like the dbus config isn't restrictive enough, you should get something like: 06:31:20 Mithrandir | > systemctl reboot 06:31:22 Mithrandir | Failed to issue method call: Access denied
I'll keep you informed while I continue investigating this issue until I have enough info to file a bug.
That's not it. It's intended that you can reboot/halt as user, if nobody else is logged in.
On Tue, 16 Oct 2012 23:08:33 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 16.10.2012 20:15, schrieb Martín Cigorraga:
Interesting, but I don't know. This may be a polkit setting. If you find out, I'd be interested.
I was sugested in the #systemd channel that this may be associated with dbus: 06:31:17 Mithrandir | sounds like the dbus config isn't restrictive enough, you should get something like: 06:31:20 Mithrandir | > systemctl reboot 06:31:22 Mithrandir | Failed to issue method call: Access denied
I'll keep you informed while I continue investigating this issue until I have enough info to file a bug.
That's not it. It's intended that you can reboot/halt as user, if nobody else is logged in.
Actually, I am seeing this too. More precisely, from console "systemctl reboot" works as a normal user. However, when X (and xfce4-session) is started via "startx -- vt1" I can no longer do that (with the same error message as Martin). In both cases "loginctl" shows an assigned seat0, and inside xfce "ck-list-session" shows an active session on /dev/tty1, so I can reboot/poweroff via ck/polkit/sysvcompat layer. I can't try gnome to check whether it is an issue with xfce4-session not being systemd-aware, because somehow gnome-shell segfaults on startup for me :( -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, Oct 16, 2012 at 6:37 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Tue, 16 Oct 2012 23:08:33 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 16.10.2012 20:15, schrieb Martín Cigorraga:
Interesting, but I don't know. This may be a polkit setting. If you find out, I'd be interested.
I was sugested in the #systemd channel that this may be associated with dbus: 06:31:17 Mithrandir | sounds like the dbus config isn't restrictive enough, you should get something like: 06:31:20 Mithrandir | > systemctl reboot 06:31:22 Mithrandir | Failed to issue method call: Access denied
I'll keep you informed while I continue investigating this issue until I have enough info to file a bug.
That's not it. It's intended that you can reboot/halt as user, if nobody else is logged in.
Actually, I am seeing this too.
More precisely, from console "systemctl reboot" works as a normal user. However, when X (and xfce4-session) is started via "startx -- vt1" I can no longer do that (with the same error message as Martin). In both cases "loginctl" shows an assigned seat0, and inside xfce "ck-list-session" shows an active session on /dev/tty1, so I can reboot/poweroff via ck/polkit/sysvcompat layer.
I can't try gnome to check whether it is an issue with xfce4-session not being systemd-aware, because somehow gnome-shell segfaults on startup for me :(
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
"That's not it. It's intended that you can reboot/halt as user, if nobody else is logged in." Ahh, ok, that explains a lot. I can reboot/shutdown with my user account from both CLI and inside X. However when I switch to another user if I try to reboot/shutdown from CLI I'm asked for the first logged user password (instead the root password!) while when inside X I just have the "Access denied" message - with not chance to enter any password to authorize the command.
On Wed, Oct 17, 2012 at 8:40 PM, Martín Cigorraga <msx@archlinux.us> wrote:
I can reboot/shutdown with my user account from both CLI and inside X. However when I switch to another user if I try to reboot/shutdown from CLI I'm asked for the first logged user password (instead the root password!) while when inside X I just have the "Access denied" message - with not chance to enter any password to authorize the command.
A Polkit authentication agent must be running. Polkit itself only ships an agent for TTYs. Both polkit-gnome and polkit-kde contain an agent for X.
participants (5)
-
Jan Steffens
-
Joshua Collins
-
Leonid Isaev
-
Martín Cigorraga
-
Thomas Bächler