Re: [systemd-devel] serialization bug, swap bug, etc.

2015-02-03 Thread Lennart Poettering
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.

2014-12-16 Thread Filipe Brandenburger
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.

2014-12-10 Thread Lennart Poettering
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.

2014-12-09 Thread Mantas Mikulėnas
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.

2014-12-01 Thread Lennart Poettering
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.

2014-11-24 Thread Zbigniew Jędrzejewski-Szmek
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.

2014-11-24 Thread Mantas Mikulėnas
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.

2014-11-23 Thread Zbigniew Jędrzejewski-Szmek
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.

2014-11-23 Thread Mantas Mikulėnas
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