Re: [systemd-devel] serialization bug, swap bug, etc.
On Tue, 16.12.14 17:22, Filipe Brandenburger (filbran...@google.com) wrote: On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering lenn...@poettering.net wrote: In fact, I think we should drop the libcap dependency altogether and just do the two syscalls it offers to us natively in systemd code. Neither is libcap a particularly nice library, nor is the stuff it does particularly complex, hence we can as well wrap the two calls we need in our code. I started looking at this and I just sent a patch set to remove the include of sys/capability.h where it was not really in use. Regarding the valid uses of libcap, it looks like the non-trivial part is cap_to_text/cap_from_text which we would have to reimplement and possibly keep them in sync with libcap. Yeah, this is indeed not the nicest code to hack up, but should be quite doable still. libcap also tries to support kernels which only support 32-bit capabilities. If we replace that code, should we make an assumption of 64-bit capabilities and just use a uint64_t to represent the bits? I think 64bit caps have been standard since a lng time already. AFAIK though the kernel/userspace API is built around arrays of 64bit values currently though, to allow extension one day. This is how we expose it in sd-bus for the message metadata caps currently, maybe we should do it everywhere the same. Let me know if you think this is something worth doing and I can contribute an implementation. Absolutely. Would love to drop the dep! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering lenn...@poettering.net wrote: In fact, I think we should drop the libcap dependency altogether and just do the two syscalls it offers to us natively in systemd code. Neither is libcap a particularly nice library, nor is the stuff it does particularly complex, hence we can as well wrap the two calls we need in our code. I started looking at this and I just sent a patch set to remove the include of sys/capability.h where it was not really in use. Regarding the valid uses of libcap, it looks like the non-trivial part is cap_to_text/cap_from_text which we would have to reimplement and possibly keep them in sync with libcap. libcap also tries to support kernels which only support 32-bit capabilities. If we replace that code, should we make an assumption of 64-bit capabilities and just use a uint64_t to represent the bits? Let me know if you think this is something worth doing and I can contribute an implementation. Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Wed, 10.12.14 09:10, Mantas Mikulėnas (graw...@gmail.com) wrote: On Thu, Nov 20, 2014 at 9:13 AM, Mantas Mikulėnas graw...@gmail.com wrote: ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). Seems like this no longer shows up on my machine, since Arch seems to be building libcap against linux-api-headers now (instead of its internal copy, I guess). I also added some code to systemd yesterday that uses its own cap list, which is more up-to-date. In fact, I think we should drop the libcap dependency altogether and just do the two syscalls it offers to us natively in systemd code. Neither is libcap a particularly nice library, nor is the stuff it does particularly complex, hence we can as well wrap the two calls we need in our code. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Thu, Nov 20, 2014 at 9:13 AM, Mantas Mikulėnas graw...@gmail.com wrote: ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). Seems like this no longer shows up on my machine, since Arch seems to be building libcap against linux-api-headers now (instead of its internal copy, I guess). -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Thu, 20.11.14 09:13, Mantas Mikulėnas (graw...@gmail.com) wrote: ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). We currently need one actual operation from libcap, plus the capability string tables. THat's all. Which really makes me wonder whether we shouldn't simply do the table and the one syscall in systemd and get rid of the dep, it's not really that complex, and we have some caps code anyway in place... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Mon, Nov 24, 2014 at 07:48:17AM +0200, Mantas Mikulėnas wrote: On Mon, Nov 24, 2014 at 2:59 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Nov 20, 2014 at 09:13:02AM +0200, Mantas Mikulėnas wrote: ~ If there are two .swap units for the same partition (one made by fstab-generator, another by gpt-generator), systemd tries to swapon it twice, resulting in swapon failed: Device or resource busy. IIUC, the problem is that swapons are called concurently, and one fails. If they were started sequentially, systemd would notice that they both refer to the same device and make one of the follow the other. What I'm guessing happens is that initially the units use different device names, so they are not merged. Could you post both units (systemctl cat would probably be best), so we can see what is going wrong? Right, after all, since .swap unit names directly depend on device names, then it's pretty much guaranteed that the latter will differ... What I have is: --- # /run/systemd/generator/dev-disk-by\x2dpartlabel-swap.swap # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) [Swap] What=/dev/disk/by-partlabel/swap Options=rw --- --- # /run/systemd/generator.late/dev-sda7.swap # Automatically generated by systemd-gpt-auto-generator [Unit] Description=Swap Partition Documentation=man:systemd-gpt-auto-generator(8) [Swap] What=/dev/sda7 --- And what does 'udevadm info /dev/sda7' and 'systemctl show dev-sda7.swap' and the same for dev-disk-by\x2dpartlabel-swap.swap? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Mon, Nov 24, 2014 at 5:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: And what does 'udevadm info /dev/sda7' and 'systemctl show dev-sda7.swap' and the same for dev-disk-by\x2dpartlabel-swap.swap? Attached both. -- Mantas Mikulėnas graw...@gmail.com a.sd-show Description: Binary data a.udev-info Description: Binary data b.sd-show Description: Binary data b.udev-info Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Thu, Nov 20, 2014 at 09:13:02AM +0200, Mantas Mikulėnas wrote: ~ I'm getting this on every reload: systemd[1]: Unknown serialization item 'subscribed=:1.1' Lukas' patch should fix that. Doesn't seem to break anything though. ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). Yeah, that's annoying. We could add a wrapper around cap_from_name... ~ If there are two .swap units for the same partition (one made by fstab-generator, another by gpt-generator), systemd tries to swapon it twice, resulting in swapon failed: Device or resource busy. IIUC, the problem is that swapons are called concurently, and one fails. If they were started sequentially, systemd would notice that they both refer to the same device and make one of the follow the other. What I'm guessing happens is that initially the units use different device names, so they are not merged. Could you post both units (systemctl cat would probably be best), so we can see what is going wrong? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Mon, Nov 24, 2014 at 2:59 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Nov 20, 2014 at 09:13:02AM +0200, Mantas Mikulėnas wrote: ~ If there are two .swap units for the same partition (one made by fstab-generator, another by gpt-generator), systemd tries to swapon it twice, resulting in swapon failed: Device or resource busy. IIUC, the problem is that swapons are called concurently, and one fails. If they were started sequentially, systemd would notice that they both refer to the same device and make one of the follow the other. What I'm guessing happens is that initially the units use different device names, so they are not merged. Could you post both units (systemctl cat would probably be best), so we can see what is going wrong? Right, after all, since .swap unit names directly depend on device names, then it's pretty much guaranteed that the latter will differ... What I have is: --- # /run/systemd/generator/dev-disk-by\x2dpartlabel-swap.swap # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) [Swap] What=/dev/disk/by-partlabel/swap Options=rw --- --- # /run/systemd/generator.late/dev-sda7.swap # Automatically generated by systemd-gpt-auto-generator [Unit] Description=Swap Partition Documentation=man:systemd-gpt-auto-generator(8) [Swap] What=/dev/sda7 --- -- 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] serialization bug, swap bug, etc.
~ I'm getting this on every reload: systemd[1]: Unknown serialization item 'subscribed=:1.1' Doesn't seem to break anything though. ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). ~ If there are two .swap units for the same partition (one made by fstab-generator, another by gpt-generator), systemd tries to swapon it twice, resulting in swapon failed: Device or resource busy. This was broken first when systemd-gpt-generator appeared, then systemd was taught to recognize duplicates, but now it seems to be broken again. (I *think* it broke around commit 3018d31238caabc2e.) -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
