Re: [systemd-devel] /etc/systemd/system/darkice.service
On 22 July 2013 23:56, Andrey Borzenkov arvidj...@gmail.com wrote: network-online.target has no requirement for pingtest.service. All that this configuration does is delaying network-online.target by at most 60 seconds, that's all. If network is not up at this point - too bad. That ping switch Lennart proposed, -w 60 or -W 60 doesn't actually wait if there is no network. So I've ended up with a shell script: ExecStart=/usr/bin/bash -c 'for i in `seq 60`; do ping -c 1 -nq 8.8.8.8 exit; sleep 1; done; exit 1' http://sprunge.us/KbUZ Which seems to work, however I can't seem to make network-online.target depend on pingtest.service with `RequiredBy=network-online.target` in the pingtest.service file. So even if pingtest fails, network-online.target ends up being active. :/ With the darkice service file, I ended up with http://sprunge.us/VXRU Restart=on-failure was needed since sometimes it would fail to start. No idea why. I can't confirm it was restarted in that cases since `systemctl status darkice.service` doesn't tell me this. Another problem is that if someone manages to connect the USB microphone in the wrong USB port, it fails to start: http://ix.io/6Ql Not sure how to wildcard bind the USB GO Mic here. Any tips? Kind regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd service file type
Hi all, Is there any limitation on file types which can act as a valid unit file for systemd? I have seen .socket, .mount, .path and of-course .service. Or any file with valid syntax can act as a systemd unit file? Thanks Shakeel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd service file type
On Wed, Jul 24, 2013 at 12:21:00PM +0500, Muhammad Shakeel wrote: Hi all, Is there any limitation on file types which can act as a valid unit file for systemd? I have seen .socket, .mount, .path and of-course .service. Or any file with valid syntax can act as a systemd unit file? No, each suffix you mentioned above has a specific usage and type. If you look at systemd.unit(5) you can see most of the unit types and what they do. http://www.freedesktop.org/software/systemd/man/systemd.unit.html Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpvpAm37wQsn.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev/systemd/pulseaudio/lirc please improve hotplugging
'Twas brillig, and Damian Ivanov at 23/07/13 13:01 did gyre and gimble: Hey guys, udev/systemd/pulseaudio/lirc should provide a maximum amount of hotplugging, there are dozens of questions and bug reports on the net about the creative X-fi USB sound card on Linux. The sound itself works, also 5.1 channels work though standard is set to stereo. The sound card has a remote control with it, which is very difficult to set up, a lot of people don't manage it. Wouldn't it be much smoother if a) pulseaudio sets the best available channel configuration for the card and also the default channels and sample rate - sound rattling ( http://community.linuxmint.com/hardware/view/7476 ) PulseAudio already reads udev properties on the devices (PULSE_PROFILE_SET) to see if the a specific (i.e. non-probed) profile set is needed for that h/w. It would be relatively trivial to improve that to read e.g. PULSE_PREFERRED_PROFILE_NAME or similar such that a default profile was picked (assuming no other override), but that said all profiles have a built in priority calculated in PA, the highest of which is used in the even of no other configuration. So really this is something you can pretty much create with a custom profile-set for the X-fi and add it to the udev rules. (all of this is in PulseAudio and thus should really be directed to that mailing list). As a side note, the udev rules in PA should probably be converted to the hwdb format now I guess (although they are not to large, it's still the new shiny way to do things :D) b) if udev registers the card set up/recommend/message the user accordingly: lircd - --device=hw:Pro --driver=alsa_usb How would udev message the user? At present there are a few horrible hacky mechanisms in place to do similar udev-userspace stuff (including installing missing packages on plug) such as the system-config-printer stuff. I guess it would be nice to create a slightly more generic udev-userspace communicator protocol/applet for handling things like this for desktop scenarios. Has anyone given this any thought? 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 for Smack labelling support in udev
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Tuesday, July 16, 2013 10:12 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
-static int node_permissions_apply(struct udev_device *dev, bool
apply, mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool
+apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct
+udev_list xattr_list)
Guess we better pass the udev_list as a const pointer here.
Ups, sorry, missed this one, of course it won't even work this way (I
haven't tried to run it yet ...
It looks like it could work, but please test it and make sure it does the
right thing before we go ahead from here.
OK, so now I have tested it and with one minor fix (passing a list entry and
not the whole list in udev-node) it works just fine.
I am able to setup one or more xattrs on device node using the syntax
XATTR{attr_name}=value
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really meaningful
on device nodes), but proves that functionality works.
I am attaching the patch.
Best Regards,
Elena.
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
'Twas brillig, and Kai Hendry at 24/07/13 08:10 did gyre and gimble: On 22 July 2013 23:56, Andrey Borzenkov arvidj...@gmail.com wrote: network-online.target has no requirement for pingtest.service. All that this configuration does is delaying network-online.target by at most 60 seconds, that's all. If network is not up at this point - too bad. That ping switch Lennart proposed, -w 60 or -W 60 doesn't actually wait if there is no network. So I've ended up with a shell script: ExecStart=/usr/bin/bash -c 'for i in `seq 60`; do ping -c 1 -nq 8.8.8.8 exit; sleep 1; done; exit 1' http://sprunge.us/KbUZ Which seems to work, however I can't seem to make network-online.target depend on pingtest.service with `RequiredBy=network-online.target` in the pingtest.service file. So even if pingtest fails, network-online.target ends up being active. :/ I've not really played much with RequiredBy= stuff for targets (mostly use WantedBy) so not sure if this is something that is misbehaving. That said, the [Install] section is completely inactive unless you run systemctl enable/disable etc. So I guess one question would be: have you done that after editing the unit? You will also likely need to run systemctl --system daemon-reload to make it reread the unit file after editing too. Also as the previous enable would have written the .wants symlink, ti's probably work doing a rm -f /etc/systemd/system/network-online.target.wants/pingtest.service to ensure it's cleaned out properly (in theory it shouldn't do any harm, but perhaps an existing symlink here is somehow overriding the requires one...) With the darkice service file, I ended up with http://sprunge.us/VXRU Restart=on-failure was needed since sometimes it would fail to start. No idea why. I can't confirm it was restarted in that cases since `systemctl status darkice.service` doesn't tell me this. Another problem is that if someone manages to connect the USB microphone in the wrong USB port, it fails to start: http://ix.io/6Ql Not sure how to wildcard bind the USB GO Mic here. Any tips? So this smells like something you should trigger via a udev rule instead. Certainly the starting of it (you can specify SYSTEMD_UNIT= to make it start a unit on hotplug). Not sure how you'd handle the killing of it (unless the SYSTEMD_UNIT property magically stops it too?) 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] I caught a something wrong when I analyzed a systemd on my board by systemd-analyze plot
'Twas brillig, and Tony Seo at 24/07/13 01:57 did gyre and gimble: Hello. I had analyzed my systemd by using systemd-analyze plot. But I caught a something wrong related with boot sequence time. After I started my board, I checked the first boot image about 8 sec. What do you use to determine that the system has finished booting? Is it just the fact you can log in? But the plot resulted by systemd-analyze plot showed that it took about 1min 30s to complete all system unit. I was confused how to understand between plot result and physical screen out. Just because you are able to login, does not mean the system has finished booting. e.g. on my machine, I have NFS mount points configured. This requires the network to be up before these can be mounted. But my user login does not depend on these mount points (they are marked as nofail in fstab) and thus I can login happily before this has happened. The system is still booting but I can login happily. Does explain your confusion? Perhaps posting a link to your plot svg would be useful? 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 shutdown vs ostree
'Twas brillig, and Colin Walters at 20/07/13 23:50 did gyre and gimble: So OSTree sets up systemd inside a chroot - /usr is a read-only bind mount, and /var is a bind mount outside the root to a shared location. Furthermore, /sysroot points to the real root. Since last time we discussed this: http://lists.freedesktop.org/archives/systemd-devel/2012-September/006668.html I now use this service inside dracut: https://git.gnome.org/browse/ostree/tree/src/dracut/ostree-prepare-root.service Which executes: https://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-prepare-root.c Then finally we do dracut's normal systemctl switch-root, and everything continues as normal. I haven't had to patch the systemd codebase at all for this. The problem is that on shutdown, systemd will synthesize usr.mount and var.mount from /proc/self/mountinfo, but it can't really unmount them until the same point as the rootfs. Because these units fail to unmount, the normal shutdown process wedges. I can shutdown fine with systemctl --force poweroff, but then I don't get plymouth integration etc. One way to fix this might be to somehow tell systemd to just ignore these mount points during shutdown. Or possibly, switch back to the initramfs and unmount them from there. The ugly thing about switching back to the initramfs is that it requires unpacking it from the cpio blob again, which requires /boot to be mounted, only to run a few unmount syscalls, and then finally power off. But if there was a way to tell systemd to just ignore the mounts, then we'd drop into the final poweroff SIGTERM/SIGKILL/umount spree like sysvinit did, and things would work. Anyone else doing bind mount tricks like this? Interestingly, I asked something similar a while back. See the thread: x-initrd.mount + shutdown umount logic question http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/11210 In my case it was pretty much a cosmetic issue but you want a harder exclusion I think... 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 v2] shell-completion: Add machinectl zsh completion
On Tue, Jul 23, 2013 at 09:55:22PM -0500, William Giokas wrote: shell-completion/systemd-zsh-completion.zsh | 49 - 1 file changed, 48 insertions(+), 1 deletion(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Error handling problems with systemd-machined
I'm working on integrating libvirt with systemd-machined for cgroups
setup and hitting a number of problems
The first was that v205 ignores all parameters passed though as scope
properties in the DBus CreateMachine call. So I upgraded to v206 which
seems to have fixed that.
When something goes wrong with the CreateMachine DBus call though all I
ever seem to get back is Input/output error.
After strace'ing systemd-machined I find the real error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\1\0\1\334\0\0\0\2\0\0\0\277\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/machine1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.machine1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.machine1.Manager\0\0\0\0\0\0\0\0\3\1s\0\r\0\0\0CreateMachine\0\0\0\10\1g\0\fsayssusa(sv)\0\0\0\0\0\0\0\7\1s\0\6\0\0\0:1.130\0\0\t\0\0\0lxc-busy2\0\0\0\20\0\0\0\335\247\271G\10F\27Y(s\0177]\367\327\353\v\0\0\0libvirt-lxc\0\t\0\0\0container\0\0\0\210:\0\0\0\0\0\0\0\0\0\0\204\0\0\0\0\0\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 428
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\1\0\1D\1\0\0\n\0\0\0\255\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\22\0\0\0StartTransientUnit\0\0\0\0\0\0\10\1g\0\7ssa(sv)\0\0\0\0,
192},
{\32\0\0\0machine-lxc\\x2dbusy2.scope\0\0\4\0\0\0fail\0\0\0\0\24\1\0\0\5\0\0\0Slice\0\1s\0\0\0\0\r\0\0\0machine.slice\0\0\0\0\0\0\0\v\0\0\0Description\0\1s\0\0\23\0\0\0Container
lxc-busy2\0\0\0\0\0\17\0\0\0TimeoutStopUSec\0\1t\0\0
\241\7\0\0\0\0\0\4\0\0\0PIDs\0\2au\0\0\0\0\4\0\0\0\210:\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
324}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 516
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\1+\0\0\0\265\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0$\0\0\0org.freedesktop.systemd1.InvalidName\0\0\0\0\5\1u\0\n\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0\0\0\0Unit
name /machine.slice is not valid.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 155
sendmsg(3, {msg_name(0)=NULL,
msg_iov(4)=[{PRIORITY=3\nSYSLOG_FACILITY=4\nCODE_FILE=src/machine/machine.c\nCODE_LINE=246\nCODE_FUNCTION=machine_start_scope\nSYSLOG_IDENTIFIER=systemd-machined\n,
144}, {MESSAGE=, 8}, {Failed to start machine scope: Unit name
/machine.slice is not valid., 69}, {\n, 1}], msg_controllen=0, msg_flags=0},
MSG_NOSIGNAL) = 222
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\3\1\1\27\0\0\0\v\0\0\0O\0\0\0\6\1s\0\6\0\0\0:1.130\0\0\4\1s\0\\0\0\0org.freedesktop.DBus.Error.IOError\0\0\0\0\0\0\5\1u\0\2\0\0\0\10\1g\0\1s\0\0,
96}, {\22\0\0\0Input/output error\0, 23}], msg_controllen=0, msg_flags=0},
MSG_NOSIGNAL) = 119
So machined is getting a useful error back from systemd
Unit name /machine.slice is not valid.
and syslog'ing that error, and then sending back the dbus client a useless
Input/output error message :-(
Once I fixed the unit name to removing the leading '/', I hit a second
error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\0014\0\0\0\301\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0#\0\0\0org.freedesktop.systemd1.UnitExists\0\0\0\0\0\5\1u\0\f\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0/\0\0\0Unit
machine-lxc\\x2dbusy2.scope already exists.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 164
Unit machine-lxc\\x2dbusy2.scope already exists
But neither machinectl list or systemctl --full show any such machine
or unit existing. It seems like when it reported the bogus slice name,
it did not fully clean up the transient scope unit it created. This is
then blocking further attempts to create the same transient scope.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd shutdown vs ostree
On Sat, Jul 20, 2013 at 06:50:13PM -0400, Colin Walters wrote: So OSTree sets up systemd inside a chroot - /usr is a read-only bind mount, and /var is a bind mount outside the root to a shared location. Furthermore, /sysroot points to the real root. Since last time we discussed this: http://lists.freedesktop.org/archives/systemd-devel/2012-September/006668.html I now use this service inside dracut: https://git.gnome.org/browse/ostree/tree/src/dracut/ostree-prepare-root.service Which executes: https://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-prepare-root.c Then finally we do dracut's normal systemctl switch-root, and everything continues as normal. I haven't had to patch the systemd codebase at all for this. The problem is that on shutdown, systemd will synthesize usr.mount and var.mount from /proc/self/mountinfo, but it can't really unmount them until the same point as the rootfs. Because these units fail to unmount, the normal shutdown process wedges. I can shutdown fine with systemctl --force poweroff, but then I don't get plymouth integration etc. One way to fix this might be to somehow tell systemd to just ignore these mount points during shutdown. Or possibly, switch back to the initramfs and unmount them from there. The ugly thing about switching back to the initramfs is that it requires unpacking it from the cpio blob again, which requires /boot to be mounted, only to run a few unmount syscalls, and then finally power off. But if there was a way to tell systemd to just ignore the mounts, then we'd drop into the final poweroff SIGTERM/SIGKILL/umount spree like sysvinit did, and things would work. Anyone else doing bind mount tricks like this? A while back had a similar-ish kind of problem with LXC, when the original FS had something mounted at say /foo/bar/wizz, and then libvirt bind mounted something at /foo, making /foo/bar/wizz inaccessible. systemd would still see these over-mounted mounts and fail to unmount them at shutdown. I fixed libvirt LXC to remove all sub-mounts before bind mounting the new thing at /foo, so not sure if the problems I saw with systemd would still exist or not. There is also a change proposed for the kernel namespaces yesterday to make it possible to stop a process inside a container from unmounting things that wasn't originally mounted inside the namespace. So if that is merged, systemd inside a container wouldn't be able to assume it has the privileges to unmount all filesystems it can see. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot
We used to call
systemd-tmpfiles --prefix=/dev --create --remove
systemd-udevd
systemd-tmpfiles --create --remove
which caused a bug:
The first call would create dead device nodes, udev would change
permissions on these nodes, before the second call to tmpfiles would
reset the permissions to what they used to be.
Instead allow negation in the prefix filtering, to restrict the
second call to apply to everything but /dev:
systemd-tmpfiles --prefix=!/dev --create --remove
Fixes: https://bugs.archlinux.org/task/36259
Reported-by: Gaetan Bisson bis...@archlinux.org
---
src/tmpfiles/tmpfiles.c | 5 -
units/systemd-tmpfiles-setup.service.in | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index eae993e..9840bba 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1119,9 +1119,12 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
path_kill_slashes(i-path);
-if (arg_prefix !path_startswith(i-path, arg_prefix))
+if (arg_prefix arg_prefix[0] != '!' !path_startswith(i-path,
arg_prefix))
return 0;
+ if (arg_prefix arg_prefix[0] == '!' path_startswith(i-path,
arg_prefix + 1))
+ return 0;
+
if (user !streq(user, -)) {
const char *u = user;
diff --git a/units/systemd-tmpfiles-setup.service.in
b/units/systemd-tmpfiles-setup.service.in
index 67c7d4a..c49ce51 100644
--- a/units/systemd-tmpfiles-setup.service.in
+++ b/units/systemd-tmpfiles-setup.service.in
@@ -21,4 +21,4 @@ ConditionDirectoryNotEmpty=|/run/tmpfiles.d
[Service]
Type=oneshot
RemainAfterExit=yes
-ExecStart=@rootbindir@/systemd-tmpfiles --create --remove
+ExecStart=@rootbindir@/systemd-tmpfiles --prefix=!/dev --create --remove
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Error handling problems with systemd-machined
On Wed, Jul 24, 2013 at 02:13:30PM +0100, Daniel P. Berrange wrote: I'm working on integrating libvirt with systemd-machined for cgroups setup and hitting a number of problems A further discovery - if I pass MemoryAccounting=yes as a scope property, then the process gets immediately killed by the OOM killer Jul 24 14:30:26 localhost systemd[1]: Starting Container lxc-busy3. Jul 24 14:30:26 localhost systemd[1]: Started Container lxc-busy3. Jul 24 14:30:26 localhost systemd-machined[14756]: New machine lxc-busy3. Jul 24 14:30:26 localhost kernel: [ 4326.760834] libvirt_lxc invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0 Jul 24 14:30:26 localhost kernel: [ 4326.760839] libvirt_lxc cpuset=/ mems_allowed=0 Jul 24 14:30:26 localhost kernel: [ 4326.760841] Pid: 26196, comm: libvirt_lxc Not tainted 3.9.0-0.rc1.git0.1.fc19.x86_64 #1 Jul 24 14:30:26 localhost kernel: [ 4326.760843] Call Trace: Jul 24 14:30:26 localhost kernel: [ 4326.760852] [810d2da6] ? cpuset_print_task_mems_allowed+0x96/0xc0 Jul 24 14:30:26 localhost kernel: [ 4326.760857] [8163cc20] dump_header+0x7a/0x1b3 Jul 24 14:30:26 localhost kernel: [ 4326.760860] [8113242e] oom_kill_process+0x1be/0x310 Jul 24 14:30:26 localhost kernel: [ 4326.760864] [811913d5] __mem_cgroup_try_charge+0xad5/0xb20 Jul 24 14:30:26 localhost kernel: [ 4326.760866] [81191c80] ? mem_cgroup_charge_common+0x120/0x120 Jul 24 14:30:26 localhost kernel: [ 4326.760869] [81191be6] mem_cgroup_charge_common+0x86/0x120 Jul 24 14:30:26 localhost kernel: [ 4326.760871] [8119349b] mem_cgroup_newpage_charge+0x4b/0xb0 Jul 24 14:30:26 localhost kernel: [ 4326.760874] [8115954c] handle_pte_fault+0x71c/0xa30 Jul 24 14:30:26 localhost kernel: [ 4326.760877] [81217039] ? ext4_file_write+0x99/0x3f0 Jul 24 14:30:26 localhost kernel: [ 4326.760880] [815223e2] ? __sys_recvmsg+0x112/0x290 Jul 24 14:30:26 localhost kernel: [ 4326.760882] [8115a671] handle_mm_fault+0x291/0x660 Jul 24 14:30:26 localhost kernel: [ 4326.760887] [816498e1] __do_page_fault+0x171/0x4f0 Jul 24 14:30:26 localhost kernel: [ 4326.760890] [811d7bd1] ? fsnotify+0x241/0x320 Jul 24 14:30:26 localhost kernel: [ 4326.760892] [81649c6e] do_page_fault+0xe/0x10 Jul 24 14:30:26 localhost kernel: [ 4326.760894] [816493aa] do_async_page_fault+0x2a/0xa0 Jul 24 14:30:26 localhost kernel: [ 4326.760896] [81646388] async_page_fault+0x28/0x30 Jul 24 14:30:26 localhost kernel: [ 4326.760899] Task in /machine.slice/machine-lxc\x2dbusy3.scope killed as a result of limit of /machine.slice/machine-lxc\x2dbusy3.scope Jul 24 14:30:26 localhost kernel: [ 4326.760901] memory: usage 0kB, limit 0kB, failcnt 7 Jul 24 14:30:26 localhost kernel: [ 4326.760920] memory+swap: usage 0kB, limit 9007199254740991kB, failcnt 0 Jul 24 14:30:26 localhost kernel: [ 4326.760921] kmem: usage 0kB, limit 9007199254740991kB, failcnt 0 Jul 24 14:30:26 localhost kernel: [ 4326.760923] Memory cgroup stats for /machine.slice/machine-lxc\x2dbusy3.scope: cache:0KB rss:0KB mapped_file:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB Jul 24 14:30:26 localhost kernel: [ 4326.760931] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name Jul 24 14:30:26 localhost kernel: [ 4326.760956] [26196] 0 2619629225 1732 560 0 libvirt_lxc Jul 24 14:30:26 localhost kernel: [ 4326.760958] Memory cgroup out of memory: Kill process 26196 (libvirt_lxc) score 0 or sacrifice child Jul 24 14:30:26 localhost kernel: [ 4326.761064] Killed process 26196 (libvirt_lxc) total-vm:116900kB, anon-rss:3256kB, file-rss:3672kB Jul 24 14:30:26 localhost kernel: [ 4326.776462] virbr0: port 2(veth0) entered disabled state Jul 24 14:30:26 localhost kernel: [ 4326.777526] device veth0 left promiscuous mode Jul 24 14:30:26 localhost kernel: [ 4326.777548] virbr0: port 2(veth0) entered disabled state Jul 24 14:30:26 localhost avahi-daemon[431]: Withdrawing workstation service for veth1. Jul 24 14:30:26 localhost avahi-daemon[431]: Withdrawing workstation service for veth0. Jul 24 14:30:26 localhost systemd-machined[14756]: Machine lxc-busy3 terminated. It looks like when passing MemoryAccount=yes, then systemd is accidentally initializing the cgroup memory limit to 0 kb, with obvious results. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot
On Wed, Jul 24, 2013 at 03:32:55PM +0200, Tom Gundersen wrote: Instead allow negation in the prefix filtering, to restrict the second call to apply to everything but /dev: systemd-tmpfiles --prefix=!/dev --create --remove It's unfortunate that ! is a shell meta character. Maybe - would be better? This way when someone takes the line from the unit file and executes it in their shell, they won't be surprised by the shell messing up their command. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot
On Wed, Jul 24, 2013 at 3:49 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Jul 24, 2013 at 03:32:55PM +0200, Tom Gundersen wrote: Instead allow negation in the prefix filtering, to restrict the second call to apply to everything but /dev: systemd-tmpfiles --prefix=!/dev --create --remove It's unfortunate that ! is a shell meta character. Maybe - would be better? This way when someone takes the line from the unit file and executes it in their shell, they won't be surprised by the shell messing up their command. That's a good point. If no one objects to the overloading of =- (which usually means 'suppress errors'), then I'm fine with using that instead as the usual meaning of =- doesn't really make any sense in this context. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] tmpfiles: don't apply --create to /dev twice during boot
We used to call
systemd-tmpfiles --prefix=/dev --create --remove
systemd-udevd
systemd-tmpfiles --create --remove
which caused a bug:
The first call would create dead device nodes, udev would change
permissions on these nodes, before the second call to tmpfiles would
reset the permissions to what they used to be.
Instead allow negation in the prefix filtering, to restrict the
second call to apply to everything but /dev:
systemd-tmpfiles --prefix=-/dev --create --remove
Fixes: https://bugs.archlinux.org/task/36259
Reported-by: Gaetan Bisson bis...@archlinux.org
---
v2: use --prefix=-/dev, rather than --prefix=!/dev to avoid problems with shell
src/tmpfiles/tmpfiles.c | 5 -
units/systemd-tmpfiles-setup.service.in | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index eae993e..39341b4 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1119,9 +1119,12 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
path_kill_slashes(i-path);
-if (arg_prefix !path_startswith(i-path, arg_prefix))
+if (arg_prefix arg_prefix[0] != '-' !path_startswith(i-path,
arg_prefix))
return 0;
+ if (arg_prefix arg_prefix[0] == '-' path_startswith(i-path,
arg_prefix + 1))
+ return 0;
+
if (user !streq(user, -)) {
const char *u = user;
diff --git a/units/systemd-tmpfiles-setup.service.in
b/units/systemd-tmpfiles-setup.service.in
index 67c7d4a..0227608 100644
--- a/units/systemd-tmpfiles-setup.service.in
+++ b/units/systemd-tmpfiles-setup.service.in
@@ -21,4 +21,4 @@ ConditionDirectoryNotEmpty=|/run/tmpfiles.d
[Service]
Type=oneshot
RemainAfterExit=yes
-ExecStart=@rootbindir@/systemd-tmpfiles --create --remove
+ExecStart=@rootbindir@/systemd-tmpfiles --prefix=-/dev --create --remove
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot
On Wed, 24.07.13 15:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Jul 24, 2013 at 03:32:55PM +0200, Tom Gundersen wrote: Instead allow negation in the prefix filtering, to restrict the second call to apply to everything but /dev: systemd-tmpfiles --prefix=!/dev --create --remove It's unfortunate that ! is a shell meta character. Maybe - would be better? This way when someone takes the line from the unit file and executes it in their shell, they won't be surprised by the shell messing up their command. I'd much rather prefer --exclude-prefix=. Magic chars generaly suck. Sometimes that's acceptible to keep the number of options down, but I don't think this applies in this case, do just add an explicit option, please. 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] [PATCHv2] tmpfiles: don't apply --create to /dev twice during boot
On Wed, 24.07.13 16:08, Tom Gundersen (t...@jklm.no) wrote:
Indentation is borked. Please fix.
Please use two strv arrays, one prefix array, and one exclude_prefix
array.
And introduce --exclude-prefix= to control the latter.
---
v2: use --prefix=-/dev, rather than --prefix=!/dev to avoid problems with
shell
src/tmpfiles/tmpfiles.c | 5 -
units/systemd-tmpfiles-setup.service.in | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index eae993e..39341b4 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1119,9 +1119,12 @@ static int parse_line(const char *fname, unsigned
line, const char *buffer) {
path_kill_slashes(i-path);
-if (arg_prefix !path_startswith(i-path, arg_prefix))
+if (arg_prefix arg_prefix[0] != '-' !path_startswith(i-path,
arg_prefix))
return 0;
+ if (arg_prefix arg_prefix[0] == '-' path_startswith(i-path,
arg_prefix + 1))
+ return 0;
+
if (user !streq(user, -)) {
const char *u = user;
diff --git a/units/systemd-tmpfiles-setup.service.in
b/units/systemd-tmpfiles-setup.service.in
index 67c7d4a..0227608 100644
--- a/units/systemd-tmpfiles-setup.service.in
+++ b/units/systemd-tmpfiles-setup.service.in
@@ -21,4 +21,4 @@ ConditionDirectoryNotEmpty=|/run/tmpfiles.d
[Service]
Type=oneshot
RemainAfterExit=yes
-ExecStart=@rootbindir@/systemd-tmpfiles --create --remove
+ExecStart=@rootbindir@/systemd-tmpfiles --prefix=-/dev --create --remove
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] Error handling problems with systemd-machined
On Wed, Jul 24, 2013 at 02:36:44PM +0100, Daniel P. Berrange wrote: On Wed, Jul 24, 2013 at 02:13:30PM +0100, Daniel P. Berrange wrote: I'm working on integrating libvirt with systemd-machined for cgroups setup and hitting a number of problems A further discovery - if I pass MemoryAccounting=yes as a scope property, then the process gets immediately killed by the OOM killer [snip] It looks like when passing MemoryAccount=yes, then systemd is accidentally initializing the cgroup memory limit to 0 kb, with obvious results. It can be reproduced with simple '.slice' units defined outside of systemd-machined too # cat /etc/systemd/system/machine-demo.slice [Unit] Description=Demo slice [Slice] CPUAccounting=yes MemoryAccounting=yes # systemctl start machine-demo.slice # cat /sys/fs/cgroup/memory/machine.slice/machine-demo.slice/memory.limit_in_bytes 0 Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] tmpfiles: support passing --prefix multiple times
---
man/systemd-tmpfiles.xml | 3 ++-
src/tmpfiles/tmpfiles.c | 24 +---
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml
index 405a9f1..b0f2d9c 100644
--- a/man/systemd-tmpfiles.xml
+++ b/man/systemd-tmpfiles.xml
@@ -121,7 +121,8 @@
termoption--prefix=PATH/option/term
listitemparaOnly apply rules that
apply to paths with the specified
-prefix./para/listitem
+prefix. This option can be specified
+multiple times./para/listitem
/varlistentry
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index eae993e..cb15133 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -105,7 +105,7 @@ static bool arg_create = false;
static bool arg_clean = false;
static bool arg_remove = false;
-static const char *arg_prefix = NULL;
+static char **include_prefixes = NULL;
static const char conf_file_dirs[] =
/etc/tmpfiles.d\0
@@ -1018,6 +1018,21 @@ static bool item_equal(Item *a, Item *b) {
return true;
}
+static bool should_include_path(const char *path) {
+char **prefix;
+
+/* no explicit paths specified for inclusion, so everything is valid */
+if (strv_length(include_prefixes) == 0)
+return true;
+
+STRV_FOREACH(prefix, include_prefixes) {
+if (path_startswith(path, *prefix))
+return true;
+}
+
+return false;
+}
+
static int parse_line(const char *fname, unsigned line, const char *buffer) {
_cleanup_item_free_ Item *i = NULL;
Item *existing;
@@ -1119,7 +1134,7 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
path_kill_slashes(i-path);
-if (arg_prefix !path_startswith(i-path, arg_prefix))
+if (!should_include_path(i-path))
return 0;
if (user !streq(user, -)) {
@@ -1258,7 +1273,8 @@ static int parse_argv(int argc, char *argv[]) {
break;
case ARG_PREFIX:
-arg_prefix = optarg;
+if (strv_extend(include_prefixes, optarg) 0)
+return log_oom();
break;
case '?':
@@ -1423,6 +1439,8 @@ finish:
hashmap_free(items);
hashmap_free(globs);
+strv_free(include_prefixes);
+
set_free_free(unix_sockets);
label_finish();
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] tmpfiles: introduce --exclude-prefix
The opposite of --prefix, allows specifying path prefixes which should
be skipped when processing rules.
---
man/systemd-tmpfiles.xml| 7
shell-completion/systemd-zsh-completion.zsh | 1 +
src/tmpfiles/tmpfiles.c | 50 +
3 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml
index b0f2d9c..403592d 100644
--- a/man/systemd-tmpfiles.xml
+++ b/man/systemd-tmpfiles.xml
@@ -124,6 +124,13 @@
prefix. This option can be specified
multiple times./para/listitem
/varlistentry
+varlistentry
+
termoption--exclude-prefix=PATH/option/term
+listitemparaIgnore rules that
+apply to paths with the specified
+prefix. This option can be specified
+multiple times./para/listitem
+/varlistentry
varlistentry
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index b62b6df..1ab1311 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -249,6 +249,7 @@ _ctls()
'--clean[Clean up all files and directories with an age
parameter configured.]' \
'--remove[All files and directories marked with r, R in the
configuration files are removed.]' \
'--prefix=[Only apply rules that apply to paths with the
specified prefix.]' \
+'--exclude-prefix=[Ignore rules that apply to paths with the
specified prefix.]' \
'--help[Prints a short help text and exits.]' \
'*::files:_files'
;;
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index cb15133..bc001ac 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -106,6 +106,7 @@ static bool arg_clean = false;
static bool arg_remove = false;
static char **include_prefixes = NULL;
+static char **exclude_prefixes = NULL;
static const char conf_file_dirs[] =
/etc/tmpfiles.d\0
@@ -1018,6 +1019,21 @@ static bool item_equal(Item *a, Item *b) {
return true;
}
+static bool should_exclude_path(const char *path) {
+char **prefix;
+
+/* no explicit paths specified for exclusion, so everything is valid */
+if (strv_length(exclude_prefixes) == 0)
+return false;
+
+STRV_FOREACH(prefix, exclude_prefixes) {
+if (path_startswith(path, *prefix))
+return true;
+}
+
+return false;
+}
+
static bool should_include_path(const char *path) {
char **prefix;
@@ -1134,7 +1150,7 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
path_kill_slashes(i-path);
-if (!should_include_path(i-path))
+if (should_exclude_path(i-path) || !should_include_path(i-path))
return 0;
if (user !streq(user, -)) {
@@ -1219,11 +1235,12 @@ static int help(void) {
printf(%s [OPTIONS...] [CONFIGURATION FILE...]\n\n
Creates, deletes and cleans up volatile and temporary files
and directories.\n\n
- -h --help Show this help\n
---create Create marked files/directories\n
---cleanClean up marked directories\n
---remove Remove marked files/directories\n
---prefix=PATH Only apply rules that apply to paths
with the specified prefix\n,
+ -h --help Show this help\n
+--create Create marked files/directories\n
+--cleanClean up marked directories\n
+--remove Remove marked files/directories\n
+--prefix=PATH Only apply rules that apply to
paths with the specified prefix\n
+--exclude-prefix=PATH Ignore rules that apply to paths
with the specified prefix\n,
program_invocation_short_name);
return 0;
@@ -1235,16 +1252,18 @@ static int parse_argv(int argc, char *argv[]) {
ARG_CREATE,
ARG_CLEAN,
ARG_REMOVE,
-ARG_PREFIX
+ARG_PREFIX,
+ARG_SKIP_PREFIX,
};
static const struct option options[] = {
-{ help, no_argument, NULL, 'h' },
-{ create,no_argument, NULL, ARG_CREATE},
-{ clean, no_argument, NULL, ARG_CLEAN },
-{ remove,no_argument,
Re: [systemd-devel] [PATCH 2/2] tmpfiles: introduce --exclude-prefix
On Wed, 24.07.13 11:25, Dave Reisner (dreis...@archlinux.org) wrote:
static char **include_prefixes = NULL;
+static char **exclude_prefixes = NULL;
static const char conf_file_dirs[] =
/etc/tmpfiles.d\0
@@ -1018,6 +1019,21 @@ static bool item_equal(Item *a, Item *b) {
return true;
}
+static bool should_exclude_path(const char *path) {
+char **prefix;
+
+/* no explicit paths specified for exclusion, so everything is valid
*/
+if (strv_length(exclude_prefixes) == 0)
+return false;
+
+STRV_FOREACH(prefix, exclude_prefixes) {
+if (path_startswith(path, *prefix))
+return true;
+}
+
+return false;
+}
+
I'd probably fold this into the same function as for the positive check...
return 0;
@@ -1235,16 +1252,18 @@ static int parse_argv(int argc, char *argv[]) {
ARG_CREATE,
ARG_CLEAN,
ARG_REMOVE,
-ARG_PREFIX
+ARG_PREFIX,
+ARG_SKIP_PREFIX,
Please don't rename this internally. Please call this ARG_EXCLUDE_PREFIX
rather than ARG_SKIP_PREFIX.
Looks good otherwise.
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] I caught a something wrong when I analyzed a systemd on my board by systemd-analyze plot (Colin Guthrie)
Hi Tony, Please keep the replies on the list as others may find your posts useful or be able to help. The full plot svg would still be useful. Ideally post it somewhere and then include a link. I'm not sure why dietsplash.service wasn't tracked, but it should really be shown if it is indeed started by systemd. It can't be faster than systemd if systemd starts it, but if the same functionality of the dietsplash.service unit is implemented independently in, say, say some initrd code, then systemd won't track it. Without seeing the contents of the units and the systemctl status output for dietsplash.service, it's hard to debug further. As mentioned above, please keep the replies on list as I am probably at the end of my useful replies on this topic ;) Col 'Twas brillig, and Tony Seo at 24/07/13 16:05 did gyre and gimble: First of all, thanks for your answer about my question. Yes, you are right and I know that it doesn't mean to determine the boot time as a splash image on a board. Actually, I made mistake to determined the end of boot sequence, because of showing a splash image by dietsplash.service. By the way, I wonder why dietsplash.servie is not presented on the image which is made by systemd-analyze plot command. there is only dietsplash-quit.service on the image. I doubt that systemd didn't catch the dietsplash.service, because start time of dietspash.service was faster than systemd. Is it right? And I attach some part of plot image for explaing my situation more clear. Thanks Tony Seo -- 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] Error handling problems with systemd-machined
On Wed, 24.07.13 14:13, Daniel P. Berrange (berra...@redhat.com) wrote:
I'm working on integrating libvirt with systemd-machined for cgroups
setup and hitting a number of problems
The first was that v205 ignores all parameters passed though as scope
properties in the DBus CreateMachine call. So I upgraded to v206 which
seems to have fixed that.
Yes, this is fixed in 206, please only use that, the array was indeed
completely ignored in 205.
BTW, I have add this a few days ago:
http://www.freedesktop.org/wiki/Software/systemd/machined/
and this:
http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/
Still missing is documentation for the bus api to create
scopes/transient units and changing their params.
When something goes wrong with the CreateMachine DBus call though all I
ever seem to get back is Input/output error.
After strace'ing systemd-machined I find the real error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\1\0\1\334\0\0\0\2\0\0\0\277\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/machine1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.machine1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.machine1.Manager\0\0\0\0\0\0\0\0\3\1s\0\r\0\0\0CreateMachine\0\0\0\10\1g\0\fsayssusa(sv)\0\0\0\0\0\0\0\7\1s\0\6\0\0\0:1.130\0\0\t\0\0\0lxc-busy2\0\0\0\20\0\0\0\335\247\271G\10F\27Y(s\0177]\367\327\353\v\0\0\0libvirt-lxc\0\t\0\0\0container\0\0\0\210:\0\0\0\0\0\0\0\0\0\0\204\0\0\0\0\0\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) =
428
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\1\0\1D\1\0\0\n\0\0\0\255\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\22\0\0\0StartTransientUnit\0\0\0\0\0\0\10\1g\0\7ssa(sv)\0\0\0\0,
192},
{\32\0\0\0machine-lxc\\x2dbusy2.scope\0\0\4\0\0\0fail\0\0\0\0\24\1\0\0\5\0\0\0Slice\0\1s\0\0\0\0\r\0\0\0machine.slice\0\0\0\0\0\0\0\v\0\0\0Description\0\1s\0\0\23\0\0\0Container
lxc-busy2\0\0\0\0\0\17\0\0\0TimeoutStopUSec\0\1t\0\0
\241\7\0\0\0\0\0\4\0\0\0PIDs\0\2au\0\0\0\0\4\0\0\0\210:\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
324}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 516
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\1+\0\0\0\265\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0$\0\0\0org.freedesktop.systemd1.InvalidName\0\0\0\0\5\1u\0\n\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0\0\0\0Unit
name /machine.slice is not valid.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 155
sendmsg(3, {msg_name(0)=NULL,
msg_iov(4)=[{PRIORITY=3\nSYSLOG_FACILITY=4\nCODE_FILE=src/machine/machine.c\nCODE_LINE=246\nCODE_FUNCTION=machine_start_scope\nSYSLOG_IDENTIFIER=systemd-machined\n,
144}, {MESSAGE=, 8}, {Failed to start machine scope: Unit name
/machine.slice is not valid., 69}, {\n, 1}], msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 222
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\3\1\1\27\0\0\0\v\0\0\0O\0\0\0\6\1s\0\6\0\0\0:1.130\0\0\4\1s\0\\0\0\0org.freedesktop.DBus.Error.IOError\0\0\0\0\0\0\5\1u\0\2\0\0\0\10\1g\0\1s\0\0,
96}, {\22\0\0\0Input/output error\0, 23}], msg_controllen=0, msg_flags=0},
MSG_NOSIGNAL) = 119
So machined is getting a useful error back from systemd
Unit name /machine.slice is not valid.
and syslog'ing that error, and then sending back the dbus client a useless
Input/output error message :-(
Yeah, we really suck at handing out good errors. But usually should
should have gotten an (equally useless) EINVAL in most cases.
Once I fixed the unit name to removing the leading '/', I hit a second
error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\0014\0\0\0\301\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0#\0\0\0org.freedesktop.systemd1.UnitExists\0\0\0\0\0\5\1u\0\f\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0/\0\0\0Unit
machine-lxc\\x2dbusy2.scope already exists.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 164
Unit machine-lxc\\x2dbusy2.scope already exists
But neither machinectl list or systemctl --full show any such machine
or unit existing. It seems like when it reported the bogus slice name,
it did not fully clean up the transient scope unit it created. This is
then blocking further attempts to create the same transient scope.
Hmm, that's interesting. What does systemctl status say for the unit
in question when this happens? Could you paste?
Kay had some issues where the kernel's release_agent wouldn't be called
on recent kernels, but I never had issues with that...
Re: [systemd-devel] [PATCH 2/2] tmpfiles: introduce --exclude-prefix
On Wed, Jul 24, 2013 at 05:40:21PM +0200, Lennart Poettering wrote:
On Wed, 24.07.13 11:25, Dave Reisner (dreis...@archlinux.org) wrote:
static char **include_prefixes = NULL;
+static char **exclude_prefixes = NULL;
static const char conf_file_dirs[] =
/etc/tmpfiles.d\0
@@ -1018,6 +1019,21 @@ static bool item_equal(Item *a, Item *b) {
return true;
}
+static bool should_exclude_path(const char *path) {
+char **prefix;
+
+/* no explicit paths specified for exclusion, so everything is
valid */
+if (strv_length(exclude_prefixes) == 0)
+return false;
+
+STRV_FOREACH(prefix, exclude_prefixes) {
+if (path_startswith(path, *prefix))
+return true;
+}
+
+return false;
+}
+
I'd probably fold this into the same function as for the positive check...
Yeah, this was me being lazy. Applied brain, folded it in.
return 0;
@@ -1235,16 +1252,18 @@ static int parse_argv(int argc, char *argv[]) {
ARG_CREATE,
ARG_CLEAN,
ARG_REMOVE,
-ARG_PREFIX
+ARG_PREFIX,
+ARG_SKIP_PREFIX,
Please don't rename this internally. Please call this ARG_EXCLUDE_PREFIX
rather than ARG_SKIP_PREFIX.
Done.
Looks good otherwise.
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] systemd service file type
On Wed, 24.07.13 12:21, Muhammad Shakeel (muhammad_shak...@mentor.com) wrote: Hi all, Is there any limitation on file types which can act as a valid unit file for systemd? I have seen .socket, .mount, .path and of-course .service. Or any file with valid syntax can act as a systemd unit file? Try the man pages. For example systemd(1) has a list of all 12 currently defined unit types. Right at the beginning of the Concepts section. Pretty hard to miss. http://www.freedesktop.org/software/systemd/man/systemd.html 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] Error handling problems with systemd-machined
On Wed, Jul 24, 2013 at 05:59:48PM +0200, Lennart Poettering wrote:
When something goes wrong with the CreateMachine DBus call though all I
ever seem to get back is Input/output error.
After strace'ing systemd-machined I find the real error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\1\0\1\334\0\0\0\2\0\0\0\277\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/machine1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.machine1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.machine1.Manager\0\0\0\0\0\0\0\0\3\1s\0\r\0\0\0CreateMachine\0\0\0\10\1g\0\fsayssusa(sv)\0\0\0\0\0\0\0\7\1s\0\6\0\0\0:1.130\0\0\t\0\0\0lxc-busy2\0\0\0\20\0\0\0\335\247\271G\10F\27Y(s\0177]\367\327\353\v\0\0\0libvirt-lxc\0\t\0\0\0container\0\0\0\210:\0\0\0\0\0\0\0\0\0\0\204\0\0\0\0\0\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) =
428
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\1\0\1D\1\0\0\n\0\0\0\255\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\22\0\0\0StartTransientUnit\0\0\0\0\0\0\10\1g\0\7ssa(sv)\0\0\0\0,
192},
{\32\0\0\0machine-lxc\\x2dbusy2.scope\0\0\4\0\0\0fail\0\0\0\0\24\1\0\0\5\0\0\0Slice\0\1s\0\0\0\0\r\0\0\0machine.slice\0\0\0\0\0\0\0\v\0\0\0Description\0\1s\0\0\23\0\0\0Container
lxc-busy2\0\0\0\0\0\17\0\0\0TimeoutStopUSec\0\1t\0\0
\241\7\0\0\0\0\0\4\0\0\0PIDs\0\2au\0\0\0\0\4\0\0\0\210:\0\0\5\0\0\0Slice\0\1s\0\0\0\0\16\0\0\0/machine.slice\0\0\0\0\0\0\r\0\0\0CPUAccounting\0\1b\0\0\0\0\1\0\0\0\0\0\0\0\21\0\0\0BlockIOAccounting\0\1b\0\0\0\0\1\0\0\0\20\0\0\0MemoryAccounting\0\1b\0\1\0\0\0,
324}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 516
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\1+\0\0\0\265\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0$\0\0\0org.freedesktop.systemd1.InvalidName\0\0\0\0\5\1u\0\n\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0\0\0\0Unit
name /machine.slice is not valid.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 155
sendmsg(3, {msg_name(0)=NULL,
msg_iov(4)=[{PRIORITY=3\nSYSLOG_FACILITY=4\nCODE_FILE=src/machine/machine.c\nCODE_LINE=246\nCODE_FUNCTION=machine_start_scope\nSYSLOG_IDENTIFIER=systemd-machined\n,
144}, {MESSAGE=, 8}, {Failed to start machine scope: Unit name
/machine.slice is not valid., 69}, {\n, 1}], msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 222
sendmsg(5, {msg_name(0)=NULL,
msg_iov(2)=[{l\3\1\1\27\0\0\0\v\0\0\0O\0\0\0\6\1s\0\6\0\0\0:1.130\0\0\4\1s\0\\0\0\0org.freedesktop.DBus.Error.IOError\0\0\0\0\0\0\5\1u\0\2\0\0\0\10\1g\0\1s\0\0,
96}, {\22\0\0\0Input/output error\0, 23}], msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 119
So machined is getting a useful error back from systemd
Unit name /machine.slice is not valid.
and syslog'ing that error, and then sending back the dbus client a useless
Input/output error message :-(
Yeah, we really suck at handing out good errors. But usually should
should have gotten an (equally useless) EINVAL in most cases.
Once I fixed the unit name to removing the leading '/', I hit a second
error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\0014\0\0\0\301\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0#\0\0\0org.freedesktop.systemd1.UnitExists\0\0\0\0\0\5\1u\0\f\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0/\0\0\0Unit
machine-lxc\\x2dbusy2.scope already exists.\0, 2048}], msg_controllen=0,
msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 164
Unit machine-lxc\\x2dbusy2.scope already exists
But neither machinectl list or systemctl --full show any such machine
or unit existing. It seems like when it reported the bogus slice name,
it did not fully clean up the transient scope unit it created. This is
then blocking further attempts to create the same transient scope.
Hmm, that's interesting. What does systemctl status say for the unit
in question when this happens? Could you paste?
# systemctl status 'machine-lxc\x2dbusy4.scope'
machine-lxc\x2dbusy4.scope
Loaded: stub (/run/systemd/system/machine-lxc\x2dbusy4.scope; static)
Active: inactive (dead)
Kay had some issues where the kernel's release_agent wouldn't be called
on recent kernels, but I never had issues with that...
If systemd is complaining about the bogus slice name /machine.slice
is it possible that it has returned this error, before it ever placed
the init PID into the cgroup? The kernel release_agent would never
trigger if there was no process any cgroup to exit, and thus the
slice may not get cleaned up.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o-
Re: [systemd-devel] Error handling problems with systemd-machined
On Wed, Jul 24, 2013 at 05:10:59PM +0100, Daniel P. Berrange wrote:
On Wed, Jul 24, 2013 at 05:59:48PM +0200, Lennart Poettering wrote:
Once I fixed the unit name to removing the leading '/', I hit a second
error
recvmsg(5, {msg_name(0)=NULL,
msg_iov(1)=[{l\3\1\0014\0\0\0\301\1\0\0]\0\0\0\6\1s\0\6\0\0\0:1.126\0\0\4\1s\0#\0\0\0org.freedesktop.systemd1.UnitExists\0\0\0\0\0\5\1u\0\f\0\0\0\10\1g\0\1s\0\0\7\1s\0\4\0\0\0:1.1\0\0\0\0/\0\0\0Unit
machine-lxc\\x2dbusy2.scope already exists.\0, 2048}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 164
Unit machine-lxc\\x2dbusy2.scope already exists
But neither machinectl list or systemctl --full show any such machine
or unit existing. It seems like when it reported the bogus slice name,
it did not fully clean up the transient scope unit it created. This is
then blocking further attempts to create the same transient scope.
Hmm, that's interesting. What does systemctl status say for the unit
in question when this happens? Could you paste?
# systemctl status 'machine-lxc\x2dbusy4.scope'
machine-lxc\x2dbusy4.scope
Loaded: stub (/run/systemd/system/machine-lxc\x2dbusy4.scope; static)
Active: inactive (dead)
Kay had some issues where the kernel's release_agent wouldn't be called
on recent kernels, but I never had issues with that...
If systemd is complaining about the bogus slice name /machine.slice
is it possible that it has returned this error, before it ever placed
the init PID into the cgroup? The kernel release_agent would never
trigger if there was no process any cgroup to exit, and thus the
slice may not get cleaned up.
FYI, I can reproduce this with systemd-nspawn too
# systemd-nspawn --slice /machine.slice -D /mnt/demo/ -M foo /bin/sh
Spawning namespace container on /mnt/demo (console is /dev/pts/5).
Init process in the container running as PID 32057.
Failed to register machine: Input/output error
Container failed with error code 251.
Run that multiple times and you'll see the 2nd time machined gets the
error about pre-existing unit.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I want to ask you a fundamental question to you about dependency and starting sequence among units.
Hello. As I'm a starter in systemd, I want to ask you a fundamental question. That is how to understand existing relation from dependent and starting perspective. If you check a image file I attached, it' more clear. Actually, I have studied systemd structure to add my processes in systemd structure. Although I have read many manpage whicn is on freedesktop.org, I thought that I might not yet understand dependency and boot sequence among units after comparing results from systemd-analyze plot and dot tool. So, I want to get clear conception of dependency and boot sequence. When I first read a manpage which explains [Unit] option, I find a Wants=. For example, I make a A.service which has an Want = B.service. If A.service is started by systemd, I think that B.service will be started after A.service is totally completed. ( Is it right to use a words totally completed to explain execution of A.sevice? And I'm confused words which explain some parts of Wants=, I couldn't understand the expression start-up. Does it mean that a unit listed in Want= option will be started after the configuring unit is finished? ) if so, I think this relationship like below 1. B.service is a dependency of A.service. 2. A.service is started before B.service is started in sequential perspective of boot sequence among units. 3. if B.service is in A.service.want folder, a implicit dependency is made between A.service and B.service( result will be same as No.1) In my view, this is a critical time to develop the knowledge of systemd. I wait someone who explains those things more definite than before. Thanks Tony Seo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
В Wed, 24 Jul 2013 15:10:01 +0800 Kai Hendry hen...@iki.fi пишет: On 22 July 2013 23:56, Andrey Borzenkov arvidj...@gmail.com wrote: network-online.target has no requirement for pingtest.service. All that this configuration does is delaying network-online.target by at most 60 seconds, that's all. If network is not up at this point - too bad. That ping switch Lennart proposed, -w 60 or -W 60 doesn't actually wait if there is no network. So I've ended up with a shell script: ExecStart=/usr/bin/bash -c 'for i in `seq 60`; do ping -c 1 -nq 8.8.8.8 exit; sleep 1; done; exit 1' http://sprunge.us/KbUZ Which seems to work, however I can't seem to make network-online.target depend on pingtest.service with `RequiredBy=network-online.target` in the pingtest.service file. So even if pingtest fails, network-online.target ends up being active. :/ Do you really want all your services that depend on network being up to fail if your AP is busy and needs 61 seconds to establish connection? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I want to ask you a fundamental question to you about dependency and starting sequence among units.
On Wed, Jul 24, 2013 at 7:15 PM, Tony Seo tonys...@gmail.com wrote: When I first read a manpage which explains [Unit] option, I find a Wants=. For example, I make a A.service which has an Want = B.service. If A.service is started by systemd, I think that B.service will be started after A.service is totally completed. ( Is it right to use a words totally completed to explain execution of A.sevice? And I'm confused words which explain some parts of Wants=, I couldn't understand the expression start-up. Does it mean that a unit listed in Want= option will be started after the configuring unit is finished? ) if so, I think this relationship like below 1. B.service is a dependency of A.service. 2. A.service is started before B.service is started in sequential perspective of boot sequence among units. 3. if B.service is in A.service.want folder, a implicit dependency is made between A.service and B.service( result will be same as No.1) #1 and #3 are correct, but #2 is not. Properties like Wants= or Requires= only define *dependencies* – if A has Wants=B, then starting A will also make systemd try to start B – but they do not define any sort of *order*. There is a separate set of properties, After= and Before=, that specify order, but do not add any dependencies. For example, if A has After=B, or if B has Before=A, then they will be started sequentially (A will be started after B has started). If order is not specified, both will be started at the same time. As for the terms... it seems that the general stages are inactive, activating (in the startup process), active (has finished startup), and deactivating. I'm not entirely sure what stages apply to .service units. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [206] Randomly on shutdown, stop timeout for user@.service
Hello I am using Arch Linux, and testing systemd-206 with linux-3.10.2 on shutdown, sometimes randomly there is a long delay until user@0.service timeouts then systemd kills it. 1) Boot machine 2) Login as root 3) Execute systemctl reboot or reboot/poweroff/etc. I see this behaviour in a real machine and in a new clean install inside qemu. I am using ttyS0 just for testing, but this does not care, using normal console also happens. systemctl status [#1] journalctl [#2] If more info or any tests are needed please let me know. Thanks. [#1] http://pastebin.com/7JXNyv0T [#2] http://pastebin.com/2MTr3M1n -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [206] Randomly on shutdown, stop timeout for user@.service
On 24.7.2013 20:50, Cristian Rodríguez wrote: El 24/07/13 14:07, Gerardo Exequiel Pozzi escribió: Hello I am using Arch Linux, and testing systemd-206 with linux-3.10.2 on shutdown, sometimes randomly there is a long delay until user@0.service timeouts then systemd kills it. I am seeing a similar behaviour here, but it hangs shutting down the session-1.scope unit. I have been seeing the same behaviour for a long time (since 19x releases). It hangs for about a minute before shutting down. I never narrowed which unit hangs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Profiling systemctl daemon-reload
With thousands of units, doing a daemon-reload puts a surprisingly huge CPU and memory burden on the system. Has anyone profiled why? I'd like to get started on optimizing this, but I'll obviously need to understand where the problem is first. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) diff --git a/units/systemd-udev-settle.service.in b/units/systemd-udev-settle.service.in index 037dd9a..148aa9d 100644 --- a/units/systemd-udev-settle.service.in +++ b/units/systemd-udev-settle.service.in @@ -16,7 +16,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udev-trigger.service Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udev-trigger.service.in b/units/systemd-udev-trigger.service.in index 604c369..ea3cb62 100644 --- a/units/systemd-udev-trigger.service.in +++ b/units/systemd-udev-trigger.service.in @@ -12,7 +12,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udevd-kernel.socket systemd-udevd-control.socket Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udevd-control.socket b/units/systemd-udevd-control.socket index ca17102..12a66d2 100644 --- a/units/systemd-udevd-control.socket +++ b/units/systemd-udevd-control.socket @@ -10,7 +10,6 @@ Description=udev Control Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service diff --git a/units/systemd-udevd-kernel.socket b/units/systemd-udevd-kernel.socket index 4b8a5b0..64e6f63 100644 --- a/units/systemd-udevd-kernel.socket +++ b/units/systemd-udevd-kernel.socket @@ -10,7 +10,6 @@ Description=udev Kernel Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service -- 1.8.3.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [206] Randomly on shutdown, stop timeout for user@.service
El 24/07/13 15:40, Armin K. escribió: I have been seeing the same behaviour for a long time (since 19x releases). Can't be the same, there were no .scope units in that releases. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] shell-completion: Add new journalctl options
New options:
* -e, --pager-end
* -r, --reverse
* -x, --catalog
* -k, --dmesg
* --after-cursor
* --file
* --root
* --dump-catalog
* --force
Modified options:
* --this-boot - --boot=
Also reorganized the options to match the manual page, similar to
systemctl.
---
Using --boot now completes to something like this:
wgiokas@wst420:~/git/systemd % journalctl --boot=tab
boot offsets
-1 -2 -3 -4 -5 -6 -7
-8
boot ids
044c72e6535d43a1a69c326c983f8db3 4e16c6cd6ece413d9ef2726592f2e3a5
e98663898e144e68a469ff8f595fe161
3dfaadf1e1724d37baf494eef1ec8926 7e776bf9c11e474c9c556c59e8ddc4fc
ee89bf9326c445a49c5d9314733489f8
48470a7aa0984274b00837015efe799c e6e83fd5e4ee4dfab0589a5214d9fbd0
shell-completion/systemd-zsh-completion.zsh | 55 +++--
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index e26bba2..55fcabc 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -73,37 +73,46 @@ _ctls()
;;
journalctl)
_arguments -s \
-'--since=[Start showing entries newer or of the specified
date]:-MM-DD HH\:MM\:SS' \
-'--until=[Stop showing entries older or of the specified
date]:-MM-DD HH\:MM\:SS' \
-{-c,--cursor=}'[Start showing entries from specified
cursor]:cursors:_journal_fields __CURSORS' \
-'--system[Show system and kernel messages]' \
-'--user[Show messages from user services]' \
-{-b,--this-boot}'[Show data only from current boot]' \
-{-u,--unit=}'[Show data only from the specified
unit]:units:_journal_fields _SYSTEMD_UNIT' \
-'--user-unit[Show data only from the specified user session
unit]:units:_journal_fields _SYSTEMD_USER_UNIT' \
-{-p,--priority=}'[Show only messages within the specified
priority range]:priority:_journal_fields PRIORITY' \
+{-h,--help}'[Show this help]' \
+'--version[Show package version]' \
+'--no-pager[Do not pipe output into a pager]' \
+{-l,--full}'[Show long fields in full]' \
+{-a,--all}'[Show all fields, including long and unprintable]' \
{-f,--follow}'[Follow journal]' \
+{-e,--pager-end}'[Jump to the end of the journal in the
pager]' \
{-n,--lines=}'[Number of journal entries to show]:integer' \
'--no-tail[Show all lines, even in follow mode]' \
+{-r,--reverse}'[Reverse output]' \
{-o,--output=}'[Change journal output mode]:output
modes:_outputmodes' \
-{-l,--full}'[Show long fields in full]' \
-{-a,--all}'[Show all fields, including long and unprintable]' \
+{-x,--catalog}'[Show explanatory texts with each log line]' \
{-q,--quiet}[Don't show privilege warning] \
-'--no-pager[Do not pipe output into a pager]' \
{-m,--merge}'[Show entries from all available journals]' \
+{-b,--boot=}'[Show data only from the specified boot or
offset]:boot id or offset:_journal_boots' \
+{-k,--dmesg}'[Show only kernel messages, Implies -b]' \
+{-u,--unit=}'[Show data only from the specified
unit]:units:_journal_fields _SYSTEMD_UNIT' \
+'--user-unit[Show data only from the specified user session
unit]:units:_journal_fields _SYSTEMD_USER_UNIT' \
+{-p,--priority=}'[Show only messages within the specified
priority range]:priority:_journal_fields PRIORITY' \
+{-c,--cursor=}'[Start showing entries from specified
cursor]:cursors:_journal_fields __CURSORS' \
+'--after-cursor=[Start showing entries from the location in
the journal after the cursor]:cursors:_journal_fields __CURSORS' \
+'--since=[Start showing entries newer or of the specified
date]:-MM-DD HH\:MM\:SS' \
+'--until=[Stop showing entries older or of the specified
date]:-MM-DD HH\:MM\:SS' \
+{-F,--field=}'[List all values a certain field
takes]:Fields:_list_fields' \
+'--system[Show system and kernel messages]' \
+'--user[Show messages from user services]' \
{-D,--directory=}'[Show journal files from
directory]:directories:_directories' \
-'--interval=[Time interval for changing the FSS sealing
key]:time interval' \
-'--verify-key=[Specify FSS verification key]:FSS key' \
-{-h,--help}'[Show this help]' \
-'--version[Show package version]' \
+'--file=[Operate on specified journal files]:file:_files' \
+'--root=[Operate on
Re: [systemd-devel] Profiling systemctl daemon-reload
On Wed, Jul 24, 2013 at 10:26 PM, David Strauss da...@davidstrauss.net wrote: With thousands of units, doing a daemon-reload puts a surprisingly huge CPU and memory burden on the system. Has anyone profiled why? I'd like to get started on optimizing this, but I'll obviously need to understand where the problem is first. You might want to try the below, it should give a rough idea what's going on in your setup: Attach perf: perf record -p 1 Trigger the work in PID1 from another shell: systemctl daemon-reload Ctrl-C perf, and run: perf report to see the results. Here it shows stuff like: Samples: 79 of event 'cycles', Event count (approx.): 71757534 24.12% systemd libdbus-1.so.3.7.4 [.] 0x0001cb84 3.79% systemd [kernel.kallsyms] [k] system_call 3.62% systemd systemd [.] string_hash_func 3.03% systemd systemd [.] hash_scan 2.61% systemd libc-2.17.so[.] __strlen_sse2_pminub 2.46% systemd [kernel.kallsyms] [k] _raw_spin_lock 2.44% systemd systemd [.] unit_add_name 2.42% systemd systemd [.] config_parse 2.41% systemd libc-2.17.so[.] __strchr_sse42 2.39% systemd systemd [.] strjoin 2.38% systemd libc-2.17.so[.] __strcmp_sse42 Cheers, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 25 July 2013 00:56, Andrey Borzenkov arvidj...@gmail.com wrote: Do you really want all your services that depend on network being up to fail if your AP is busy and needs 61 seconds to establish connection? Firstly I use a PI with a wired connection with netctl ifplugd. I don't know if there is a sane replacement for ifplugd / network hotplug, but anyway it takes alarmingly about 10secs to get an IP. http://ix.io/6RA There should be only *one* darkice.service, that depends on network-online.target atm. Though if you take a look at http://ix.io/6Rz you can see `systemctl show -p Requires network-online.target` does not work for some reason. I was expecting it to say darkice.service. I probably just don't understand how dependencies work in systemd. Nightmare. Without being pedantic, I would be happy to make pingtest.service run continually until it gets the first taste of the Internet. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 24 July 2013 20:26, Colin Guthrie gm...@colin.guthr.ie wrote: Also as the previous enable would have written the .wants symlink, ti's probably work doing a rm -f /etc/systemd/system/network-online.target.wants/pingtest.service to ensure it's cleaned out properly (in theory it shouldn't do any harm, but perhaps an existing symlink here is somehow overriding the requires one...) Ah, that was the problem. I had to disable and enable it again to have my s,Wants,Requires, change to work. Crikey, systemd has some gotchas. Putting stanzas under wrong headings and this sucked hours from my life. So this smells like something you should trigger via a udev rule instead. Certainly the starting of it (you can specify SYSTEMD_UNIT= to make it start a unit on hotplug). Not sure how you'd handle the killing of it (unless the SYSTEMD_UNIT property magically stops it too?) I would prefer to rely on the `systemctl -t device --all --full | grep net`. It's a bit sad I can use a wildcard, or some logical OR statement in BindsTo IIUC=. I find /etc/udev/rules.d a bit gnarly to say the least! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 25 July 2013 12:55, Kai Hendry hen...@iki.fi wrote: Though if you take a look at http://ix.io/6Rz you can see `systemctl show -p Requires network-online.target` does not work for some reason. I was expecting it to say darkice.service. I probably just don't understand how dependencies work in systemd. Nightmare. Oh the problem here as Colin earlier pointed out is that I had to disable and `systemctl enable pingtest.service` for the requires symlnk to properly written. Going back to the timeout, I started the PI without a network. Waited a minute or two. Then I started pingtest.service manually. I was surprised that network-online.target doesn't turn active. I had to manually start it. http://ix.io/6RD ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
