Re: [systemd-devel] [PATCH] man/systemctl.xml: Add missing space for »stopcommand«
Am Donnerstag, den 24.05.2012, 22:29 +0200 schrieb Paul Menzel: Date: Thu, 24 May 2012 22:20:39 +0200 --- I do not know if that has been fixed already. $ git remote update Fetching origin fatal: The remote end hung up unexpectedly error: Could not fetch origin with `url = git://anongit.freedesktop.org/systemd`. It was updated to `git://anongit.freedesktop.org/systemd/systemd` I guess. man/systemctl.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index 2ea6fe9..9c9d2fe 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -697,7 +697,7 @@ command does not implicitly stop the units that is being disabled. If this is desired an additional -commandstop/commandcommand should +commandstop/command command should be executed afterwards./para paraThis command will print the This patch was not committed yet. Hopefully Lennart or Kay can push it. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man/systemctl.xml: Add missing space for »stopcommand«
On Tue, May 29, 2012 at 11:11 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -697,7 +697,7 @@ command does not implicitly stop the units that is being disabled. If this is desired an additional - commandstop/commandcommand should + commandstop/command command should be executed afterwards./para paraThis command will print the This patch was not committed yet. Hopefully Lennart or Kay can push it. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to modify files from within systemd *.service? (for example using /bin/echo and stdout redirection)
Am 26.05.2012 08:34, schrieb shawn: On Sat, 2012-05-26 at 02:27 -0400, Peter Lemenkov wrote: Hello All! I've got Apple Mac keyboard which behaviour depends on a value stored in /sys/module/hid_apple/parameters/fnmode file (default is 1). Before systemd I did the following - I added the echo 2 /sys/module/hid_apple/parameters/fnmode line to the end of /etc/rc.d/rc.local . Recently I tried to do the same using native systemd *.service file and quickly created the following one: I have the same keyboard. You are doing this the hard (and slow) way. just add options hid_apple fnmode=2 to /etc/modprobe.d/hid_apple.conf and then run: update-initramfs -u or whatever the equivilent is for dracut or see here https://help.ubuntu.com/community/AppleKeyboard (applicable to all distributions) Adding hid_apple.fnmode=2 to the kernel command line might also work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ cat /usr/lib/systemd/user/dbus.service [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStartPre=/usr/bin/dbus-uuidgen --ensure ExecStartPre=-/bin/rm -f /var/run/messagebus.pid ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ cat /usr/lib/systemd/user/dbus.service [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStartPre=/usr/bin/dbus-uuidgen --ensure ExecStartPre=-/bin/rm -f /var/run/messagebus.pid ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... good observation, they should be dropped. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] confusing output with a swap device missing
'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 23/05/12 15:36 did gyre and gimble: Hi, I booted a system after (inadvertently) changing the UUID of a swap device. This causes the .swap unit to time-out, and since swap.target wants the .swap unit, this makes the whole boot very slow. Unfortunately, understanding what is the cause of the timeout is not trivial, unless one knows what to look for. $ journalctl -a |grep Startup May 23 15:44:31 fedora-15 systemd[1]: Startup finished in 740ms 270us (kernel) + 1s 934ms 75us (initrd) + 1min 33s 387ms 780us (userspace) = 1min 36s 62ms 125us. $ systemd-analyze blame 2746ms network.service 355ms udev-settle.service ... (nothing here) $ systemctl status swap.target swap.target - Swap Loaded: loaded (/usr/lib/systemd/system/swap.target; static) Active: active since Wed, 23 May 2012 15:44:28 +0200; 34min ago (Completely misleading -- no swap devices were activated...) $ systemctl --failed ... (nothing interesting here) $ systemctl --failed --all ... (nothing interesting here) $ systemd-analyze plot Here one can see that swap.target is the first thing which is active a long delay. $ systemctl show swap.target ... Wants=dev-disk-by\x2duuid-xx.swap $ systemctl status dev-disk-by\x2duuid-xx.swap ... Active: inactive (dead) (OK, now it becomes obvious... but such information should be more visible.) $ journalctl ... May 23 15:42:59 fedora-15 systemd-tmpfile[519]: Successfully loaded SELinux database in 21ms 628us, size on heap is 536K. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.device/start timed out. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.swap/start failed with result 'dependency'. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.device/start failed with result 'timeout'. It would be really nice if this information which is buried in the logs could be displayed more prominently when one uses other diagnostic tools. Zbyszek Yup, this can sometimes get pretty hidden. I've also seen some strange situations where some swap units are active but others are failed when they are, in actual fact, just aliases for each other (e.g. one unit is by-uuid and another is the traditional /dev/sda2 name...) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgtop: useful error messages when bootup fails
On Fri, 25.05.12 16:34, shawn (shawnland...@gmail.com) wrote: On Tue, 2012-05-22 at 13:12 +0200, Lennart Poettering wrote: Hmm, this is misleading. THis has little to do with being ready, as the cgroup VFS are mounted synchronously very early in PID 1 and it is basically very hard to run in parallel with that. So this check actually would check for something different: whether the system was booted with systemd at all, and whether the respective cgroup controller has been enabled in the kernel at all. But for the former an excplicit early check for sd_booted() would probably a nicer choice (though I must say I shiver at the idea that we add this to all our tools). And for the latter we should probably fix things so that the tool works fine even if cpuacct, memory and blkio (or any subset of them are not available), after all those controllers should be optional. How did you start cgtop so that you ran into this problem? Lennart Amazingly enough, cgtop works just fine if we just silently ignore the missing ones here. Patch looks good! Applied. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
'Twas brillig, and Lennart Poettering at 21/05/12 17:37 did gyre and gimble: On Wed, 16.05.12 12:07, Colin Guthrie (gm...@colin.guthr.ie) wrote: I thought that the actual end point of the symlink was not all that important... e.g. if I have: /usr/lib/systemd/system/getty@.service /etc/lib/systemd/system/getty@.service /etc/lib/systemd/system/multi-user.target.wants/getty@tty1.service - /usr/lib/systemd/system/getty@.service I thought that the unit file /etc/lib/systemd/system/getty@.service was still the one used. i.e. the symlink is merely indicative of whether the service is enabled or not, and the actual physical file that it points to is not relevant. This is not correct. The destination is important. The algorithm works like this: we traverse the chain of symlinks and add all their names as alias names to the unit and load the final unit file as source and use its name as main name of the unit file. (OK, it's a bit more complicated, since when there is a non-instaniated unit name in one of the symlink/filenames we implicitly instantiate it as necessary) This logic would suggest that I cannot override any units that are enabled statically via a .wants symlink in /lib/... tree. Is that correct? (or does your comment above only apply to template unit names?) i.e. The .wants symlink only really states I'm enabled as an instance of getty@.service and then the normal inheritance rules of getty@.service resolution apply *after* that, i.e. getty@.service in /etc/... overrides the one in /lib/... When looking for a unit file we first look for the instance, and follow the symlinks there, and if that was not sucessful we look for the template doing the same. Hmmm, so what happens if I have: /etc/.../x.target.wants/foo@bar.service - /lib/.../foo@.service /etc/.../x.target.wants/foo@baz.service - /etc/.../foo@.service Which foo@.service unit is actually used? Will there be two distinct units loaded in memory and each instantiation uses the right one? Or will they both get the /etc one? Or maybe both get the /lib one? Or maybe it's random? Can you maybe also comment on Michal's reply in this thread too where he comments that he considers this behaviour a bug? It would be nice if you could agree on how things should work :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-183 build error with --disable-logind
On Sun, 27.05.12 20:15, Stephan Raue (mailingli...@openelec.tv) wrote: Hi, building systemd-183 with --disable-logind i get the follow error: journald.c:(.text+0x2088): undefined reference to `sd_pid_get_session' journald.c:(.text+0x20e8): undefined reference to `sd_pid_get_unit' journald.c:(.text+0x2144): undefined reference to `sd_pid_get_owner_uid' Ah, yikes, journald uses libsystemd-login to determine some additional meta data of logging clients. This should probably be ifdeffed out when logind isnt around. The fix should be fairly easy, i will have a look. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help with pam_systemd..
On Tue, May 29, 2012 at 7:56 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: $ cat /usr/lib/systemd/user/dbus.service [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStartPre=/usr/bin/dbus-uuidgen --ensure ExecStartPre=-/bin/rm -f /var/run/messagebus.pid ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Just a random observation from an uneducated user... but does the two ExecStartPre's really belong here for a user session? Those commands look like something that should be done only for the system dbus daemon to me... good observation, they should be dropped. Just stumbled on some more issues related to this file, so, I had some time to reflect on why this service file was entirely broken, apart from the nitpick above, which won't do much unless you run systemd --user as root, which is quite unlikely. However, the dbus-daemon args are entirely wrong, and it bit me badly trying to figure out why dbus activation was horribly broken on my system to get things like gconfd-2 or gio working. For reference, here is the proper dbus.service file: [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=unix:path=%t/dbus/user_bus_socket --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 Note that we should probably not use --address=systemd: since it passes DBUS_SESSION_BUS_ADDRESS=systemd:,guid=hash to all dbus-activated services, which is entirely broken. However, we want to point to the user bus for this user, which is conveniently in %t/dbus/user_bus_socket, just as it is written in the user@.service as well. Dbus will append a ,guid=hash but I didn't see that causing a problem. I'm still seeing the initial systemd --user message: May 29 21:18:39 testbox systemd[4954]: Failed to register to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. But that still seems harmless. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
