Re: [systemd-devel] [PATCH] libudev: fix check for too long packet

2015-01-23 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jan 23, 2015 at 05:29:46PM +, Topi Miettinen wrote:
 On 01/23/15 03:06, Lennart Poettering wrote:
  On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote:
  
  Don't use recvmsg(2) return value to check for too long packets
  (it doesn't work) but MSG_TRUNC flag.
  
  Why precisely doesn't this work? I mean, it will consider messages
  that are exactly as large as the buffer as too long, but otherwise the
  old check should be fine, no?
 
 It doesn't work because the return value of recvmsg() never exceeds the
 buffer size, so too large packets are never detected.
It doesn't have to exceed the buffer size, it just has to equal it.
So packets of size sizeof(buf) and packets greater than that would
be detected as overlong. So the check wasn't wrong, just inefficient-by-one.

  (The new check is much nicer though, admittedly)
Agreed.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

 El 23/01/15 a las 10:31, Lennart Poettering escribió:
 
 The rc-local generator only exists to add compat support for those
 systems where it never was a sysvinit script anyway...
 
 
 They are not init scripts though. but plain shell scripts with no dependency
 information. they are installed in /etc/init.d, therefore we end with units
 generated by both the sysv-generator and the rc-local generator.

Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
Debian places it in /etc/init.d, that it is a proper sysvinit script...

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] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-01-23 Thread Holger Winkelmann [TP]
HI,

While reading this I'm just thinking about RFC5880 ff. BFD support. Anybody in 
the
networks universe already thinking about this? 

Holger

- On 23 Jan, 2015, at 18:20, Alin Rauta alin.ra...@intel.com wrote:

 Hi,
 
 Uplink Failure Detection (UFD) is a key enhancement to networkd, that will
 provide support for the switch use case.
 The links can be configured as uplinks or as downlinks inside an UFD group.
 When all uplinks for a group are down, the failure is propagated to the
 downlinks, so the devices connected to them
 can take a defined action. When at least one uplink become available, the 
 daemon
 tries to bring the downlink ports up.
 
 Multiple UFD groups can be configured through .netdev files. See below a
 configuration example:
 
 [NetDev]
 Name=group1
 Kind=ufd
 
 [UFDGroup]
 Id=10
 
 [UFDLink]
 Name=sw0p1,sw0p2
 Type=uplink
 
 [UFDLink]
 Name=sw0p3
 Type=downlink
 
 [UFDLink]
 Name=sw0p4
 Type=downlink
 
 
 Few details on implementation:
 
 Networkd waits until all links are enumerated (either static configured or
 unmanaged).
 Only then it starts enumerating the groups.
 networkctl command was also updated to support listing of ufd groups 
 configuration. See below a print-out:
 
 # networkctl ufd 10
 ? UFD Group: 10
 Config File: /etc/systemd/network/ufd_to_test.netdev
  State: configured
Uplinks:
   ? 3: sw0p1
   ? 4: sw0p2
  Downlinks:
   ? 6: sw0p4
   ? 5: sw0p3
 
 Please let me know what you think.
 
 Thanks,
 Alin
 
 Alin Rauta (1):
  Added Uplink failure detection feature to networkd
 
 Makefile.am |4 +
 man/systemd.netdev.xml  |   72 +-
 src/libsystemd/sd-network/sd-network.c  |  117 +++
 src/network/networkctl.c|  153 
 src/network/networkd-link.c |   35 +
 src/network/networkd-manager.c  |   36 +
 src/network/networkd-netdev-gperf.gperf |3 +
 src/network/networkd-netdev-ufd-group.c |  298 +++
 src/network/networkd-netdev-ufd-group.h |   85 ++
 src/network/networkd-netdev.c   |   36 +
 src/network/networkd-netdev.h   |6 +
 src/network/networkd-ufd-daemon.c   | 1321 +++
 src/network/networkd-ufd-daemon.h   |   34 +
 src/network/networkd.c  |7 +
 src/network/networkd.h  |6 +
 src/systemd/sd-network.h|   20 +
 16 files changed, 2231 insertions(+), 2 deletions(-)
 create mode 100644 src/network/networkd-netdev-ufd-group.c
 create mode 100644 src/network/networkd-netdev-ufd-group.h
 create mode 100644 src/network/networkd-ufd-daemon.c
 create mode 100644 src/network/networkd-ufd-daemon.h
 
 --
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
Holger Winkelmann
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] po: update Russian translation

2015-01-23 Thread Sergey Ptashnick
Add strings for importd.
From 64baca737227adef94b9b02000ce018777b1c989 Mon Sep 17 00:00:00 2001
From: Sergey Ptashnick 0comff...@inbox.ru
Date: Fri, 23 Jan 2015 20:56:36 +0300
Subject: [PATCH] po: update Russian translation

Add strings for importd.
---
 po/ru.po |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/po/ru.po b/po/ru.po
index 23002cd..4dda604 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -7,7 +7,7 @@ msgstr 
 Project-Id-Version: systemd\n
 Report-Msgid-Bugs-To: 0comff...@inbox.ru\n
 POT-Creation-Date: 2013-03-24 19:22+0300\n
-PO-Revision-Date: 2015-01-01 21:29+0300\n
+PO-Revision-Date: 2015-01-23 20:55+0300\n
 Last-Translator: Sergey Ptashnick 0comff...@inbox.ru\n
 Language: ru\n
 MIME-Version: 1.0\n
@@ -38,6 +38,14 @@ msgstr Настроить информацию о компьютере
 msgid Authentication is required to set local machine information.
 msgstr Чтобы настроить информацию о компьютере, необходимо пройти аутентификацию.
 
+#: ../src/import/org.freedesktop.import1.policy.in.h:1
+msgid Download a VM or container image
+msgstr Загрузить образ виртуальной машины или контейнера
+
+#: ../src/import/org.freedesktop.import1.policy.in.h:2
+msgid Authentication is required to download a VM or container image
+msgstr Чтобы загрузить образ виртуальной машины или контейнера, необходимо пройти аутентификацию.
+
 #: ../src/locale/org.freedesktop.locale1.policy.in.h:1
 msgid Set system locale
 msgstr Настроить системную локаль
-- 
1.7.2.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] mount-setup: Do not bother with /proc/bus/usb

2015-01-23 Thread Lennart Poettering
1;3802;0cOn Fri, 23.01.15 13:25, Cristian Rodríguez (crrodrig...@opensuse.org) 
wrote:

 Current systemd requires kernel = 3.7 per the README file
 but CONFIG_USB_DEVICEFS disappeared from the kernel in
 upstream commit fb28d58b72aa9215b26f1d5478462af394a4d253
 (kernel 3.5-rc1)

THanks. Applied!

 ---
  src/core/mount-setup.c | 2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
 index 5919f77..521545e 100644
 --- a/src/core/mount-setup.c
 +++ b/src/core/mount-setup.c
 @@ -120,8 +120,6 @@ static const MountPoint mount_table[] = {
  static const char ignore_paths[] =
  /* SELinux file systems */
  /sys/fs/selinux\0
 -/* Legacy kernel file system */
 -/proc/bus/usb\0
  /* Container bind mounts */
  /proc/sys\0
  /dev/console\0
 -- 
 2.2.2
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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] [PATCH] build-sys: lookup for sulogin, it might not be in /sbin

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 14:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

Thanks! Applied!

 ---
  Makefile.am   | 1 +
  configure.ac  | 2 ++
  units/console-shell.service.m4.in | 2 +-
  units/emergency.service.in| 2 +-
  units/rescue.service.in   | 2 +-
  5 files changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/Makefile.am b/Makefile.am
 index 45d7a34..c463f23 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -6220,6 +6220,7 @@ substitutions = \
 '|rootprefix=$(rootprefix)|' \
 '|udevlibexecdir=$(udevlibexecdir)|' \
 '|SUSHELL=$(SUSHELL)|' \
 +   '|SULOGIN=$(SULOGIN)|' \
 '|DEBUGTTY=$(DEBUGTTY)|' \
 '|KILL=$(KILL)|' \
 '|KMOD=$(KMOD)|' \
 diff --git a/configure.ac b/configure.ac
 index 6bd095c..12e4ab2 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -98,6 +98,8 @@ AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], 
 [$PATH:/usr/sbin:/sbin])
  
  AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/sbin:/sbin])
  
 +AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
 [$PATH:/usr/sbin:/sbin])
 +
  AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln 
 doesn't support --relative ***])])
  
  M4_DEFINES=
 diff --git a/units/console-shell.service.m4.in 
 b/units/console-shell.service.m4.in
 index 3f4904a..5c80722 100644
 --- a/units/console-shell.service.m4.in
 +++ b/units/console-shell.service.m4.in
 @@ -17,7 +17,7 @@ Before=getty.target
  [Service]
  Environment=HOME=/root
  WorkingDirectory=/root
 -ExecStart=-/sbin/sulogin
 +ExecStart=-@SULOGIN@
  ExecStopPost=-@SYSTEMCTL@ poweroff
  Type=idle
  StandardInput=tty-force
 diff --git a/units/emergency.service.in b/units/emergency.service.in
 index 18973e7..2695d7b 100644
 --- a/units/emergency.service.in
 +++ b/units/emergency.service.in
 @@ -18,7 +18,7 @@ Environment=HOME=/root
  WorkingDirectory=/root
  ExecStartPre=-/bin/plymouth quit
  ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, 
 type journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
 systemctl default or ^D to\\ntry again to boot into default mode.'
 -ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
 +ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
  Type=idle
  StandardInput=tty-force
  StandardOutput=inherit
 diff --git a/units/rescue.service.in b/units/rescue.service.in
 index fc93f1e..de73fee 100644
 --- a/units/rescue.service.in
 +++ b/units/rescue.service.in
 @@ -18,7 +18,7 @@ Environment=HOME=/root
  WorkingDirectory=/root
  ExecStartPre=-/bin/plymouth quit
  ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, 
 type journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
 systemctl default or ^D to\\nboot into default mode.'
 -ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
 +ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
  Type=idle
  StandardInput=tty-force
  StandardOutput=inherit
 -- 
 2.2.2
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Christian Seiler
Am 23.01.2015 um 18:57 schrieb Lennart Poettering:
 Am 2015-01-23 08:29, schrieb Mantas Mikulėnas:
 IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas...
 if thats still a problem, maybe there could be one tmpfs at /run/user,
 still preventing users from touching root-only /run?

 Yes, that's a good idea. Initially when posting this thread I thought
 that there just had to be a trade-off between dropping CAP_SYS_ADMIN
 (and making it more difficult to escape the container), and a user
 inside the container DOSing the container by filling up /run.

 But with your idea, I can at least separate /run/user from /run
 itself 
 
 Hmm, which container manager are you using?

LXC 1.0.6 (which comes with Debian Jessie). I use the following
configuration for containers w/o CAP_SYS_ADMIN (note: I'm not claiming
this is secure (non-userns-containers may never be), and also this is
still work in progress and I'm only posting this as a proof of concept
and so that other people can reproduce it):

/etc/lxc/lxc.conf:

lxc.cgroup.use = @all

/etc/lxc/jessie-container.conf:

# This is still work in progress, I can probably get rid of some of
# those FSs, I'm not really comfortable with e.g. debugfs there.
# But if I remove them, I'll probably have to mask the units unless I
# want error messages on every container startup, and I would really
# like to keep the delta low... Still thinking about that.
lxc.mount.auto = proc sys cgroup:mixed
lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0
lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0
lxc.mount.entry = tmpfs run/lock tmpfs
rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0
lxc.mount.entry = debugfs sys/kernel/debug debugfs rw,relatime 0 0
lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir 0 0
lxc.mount.entry = hugetlbfs dev/hugepages hugetlbfs
rw,relatime,create=dir 0 0
# here I'll probably add the /run/user entry
lxc.tty = 4
lxc.pts = 1024

lxc.cap.drop = sys_admin sys_module mac_admin mac_override net_admin
sys_time syslog

lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
lxc.cgroup.devices.allow = c 1:3 rwm   #/dev/null
lxc.cgroup.devices.allow = c 1:5 rwm   #/dev/zero
lxc.cgroup.devices.allow = c 1:7 rwm   #/dev/full
lxc.cgroup.devices.allow = c 5:0 rwm   #/dev/tty
lxc.cgroup.devices.allow = c 1:8 rwm   #/dev/random
lxc.cgroup.devices.allow = c 1:9 rwm   #/dev/urandom
lxc.cgroup.devices.allow = c 1:9 rwm   #/dev/urandom
lxc.cgroup.devices.allow = c 5:2 rwm   #/dev/pts/ptmx
lxc.cgroup.devices.allow = c 136:* rwm #/ev/pts/*
lxc.cgroup.devices.allow = c 254:0 rm  #/dev/rtc{,0}
lxc.cgroup.devices.allow = c 10:228 rm #/dev/hpet

# this is just the Debian default, I didn't change anything
# there (so far):
lxc.seccomp = /usr/share/lxc/config/common.seccomp

lxc.autodev = 1
lxc.kmsg = 0

lxc.haltsignal = SIGRTMIN+14

/var/lib/lxc/$container/config:

lxc.include = /etc/lxc/jessie-container.conf
lxc.utsname = something
lxc.rootfs  = /path/to/something
lxc.arch= amd64

# network:
lxc.network.type = veth
# (and other directives that specify IP etc.)

Also inside the container the following changes w.r.t. vanilla Jessie:

 - explicitly enable getty@tty{1,2,3,4}.service
 - no ConditrionPathExists=/dev/tty0 for getty@.service
 - mask systemd-udevd.service (haven't tested if that's actually needed,
   the lxc-debian template also does this however)
 - touch /etc/fstab if you debootstrap it directly
 - I hope I didn't forget anything

Didn't try other Distros inside the containers yet (or LXC w/ systemd on
other distros for that matter).

Also, on the host, I DON'T have cgmanager or similar installed.

 I am tempted to just
 change nspawn to mount a private tmpfs into /run/user, too, as it
 already mounts /run anyway.

That would solve /run-quota issues for CAP_SYS_ADMIN-less containers,
but is unnecessary (although harmless) for those that do have it.

 (the same way mode=1777 /run/lock is a separate tmpfs already)
 by just a simple static mount entry for the container.
 
 Hmm, /run/lock is a sepatate tmpfs? /run/lock is a pretty useless,
 legacy thing. Which distro is this?

Debian Jessie. But a box with Fedora 19 here also has it (although not
mode=1777 but mode=0755) and in both Debian Jessie and Fedora 19 there
is some stuff in there. Although on Fedora it's not a separate tmpfs.

(Note that in Debian you can also configure it to be on the same tmpfs
as /run, but since on Debian it has mode 1777, there's a good reason NOT
to do that.)

Christian

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] build-sys: lookup for sulogin, it might not be in /sbin

2015-01-23 Thread Cristian Rodríguez
---
 Makefile.am   | 1 +
 configure.ac  | 2 ++
 units/console-shell.service.m4.in | 2 +-
 units/emergency.service.in| 2 +-
 units/rescue.service.in   | 2 +-
 5 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 45d7a34..c463f23 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6220,6 +6220,7 @@ substitutions = \
'|rootprefix=$(rootprefix)|' \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
+   '|SULOGIN=$(SULOGIN)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
diff --git a/configure.ac b/configure.ac
index 6bd095c..12e4ab2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,6 +98,8 @@ AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], 
[$PATH:/usr/sbin:/sbin])
 
 AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/sbin:/sbin])
 
+AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
[$PATH:/usr/sbin:/sbin])
+
 AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln doesn't 
support --relative ***])])
 
 M4_DEFINES=
diff --git a/units/console-shell.service.m4.in 
b/units/console-shell.service.m4.in
index 3f4904a..5c80722 100644
--- a/units/console-shell.service.m4.in
+++ b/units/console-shell.service.m4.in
@@ -17,7 +17,7 @@ Before=getty.target
 [Service]
 Environment=HOME=/root
 WorkingDirectory=/root
-ExecStart=-/sbin/sulogin
+ExecStart=-@SULOGIN@
 ExecStopPost=-@SYSTEMCTL@ poweroff
 Type=idle
 StandardInput=tty-force
diff --git a/units/emergency.service.in b/units/emergency.service.in
index 18973e7..2695d7b 100644
--- a/units/emergency.service.in
+++ b/units/emergency.service.in
@@ -18,7 +18,7 @@ Environment=HOME=/root
 WorkingDirectory=/root
 ExecStartPre=-/bin/plymouth quit
 ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type 
journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
systemctl default or ^D to\\ntry again to boot into default mode.'
-ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
+ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
 Type=idle
 StandardInput=tty-force
 StandardOutput=inherit
diff --git a/units/rescue.service.in b/units/rescue.service.in
index fc93f1e..de73fee 100644
--- a/units/rescue.service.in
+++ b/units/rescue.service.in
@@ -18,7 +18,7 @@ Environment=HOME=/root
 WorkingDirectory=/root
 ExecStartPre=-/bin/plymouth quit
 ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type 
journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
systemctl default or ^D to\\nboot into default mode.'
-ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
+ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
 Type=idle
 StandardInput=tty-force
 StandardOutput=inherit
-- 
2.2.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 15:45, Christian Seiler (christ...@iwakd.de) wrote:

 Am 2015-01-23 08:29, schrieb Mantas Mikulėnas:
 IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas...
 if thats still a problem, maybe there could be one tmpfs at /run/user,
 still preventing users from touching root-only /run?
 
 Yes, that's a good idea. Initially when posting this thread I thought
 that there just had to be a trade-off between dropping CAP_SYS_ADMIN
 (and making it more difficult to escape the container), and a user
 inside the container DOSing the container by filling up /run.
 
 But with your idea, I can at least separate /run/user from /run
 itself 

Hmm, which container manager are you using? I am tempted to just
change nspawn to mount a private tmpfs into /run/user, too, as it
already mounts /run anyway.

 (the same way mode=1777 /run/lock is a separate tmpfs already)
 by just a simple static mount entry for the container.

Hmm, /run/lock is a sepatate tmpfs? /run/lock is a pretty useless,
legacy thing. Which distro is this?

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] Docker vs PrivateTmp

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 11:31, Daniel J Walsh (dwa...@redhat.com) wrote:

You just sent a full quote without any comment of yours?

 
 On 01/22/2015 10:02 PM, Lennart Poettering wrote:
  On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:
 
  See the `devicemapper` mountpoint created by Docker for the container:
 
  # grep devicemapper/mnt /proc/mounts
  
  /dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
  
  /var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
  ext4
  
  rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
  0 0
  I am not sure why docker makes these mounts visible in the host
  namespace at all. This smells like a bug.
 
  Watch Docker fail to destroy the container because it is unable to remove 
  the mountpoint directory:
 
  Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
  time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
  /containers/{name:.*} returned error: Cannot destroy container 
  e68df3f45d61:
  Driver devicemapper failed to remove root filesystem
  e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62: 
  Device is
  Busy
  This smells as if Docker incorrectly sets the mount propagation bits
  on its own mounts.
 
  It would be good checking /proc/self/mountinfo inside and outside of
  docker's own namespace, and checking how the propagation bits are set
  for the individual mounts. It's a bit hard to read, but the
  interesting bits are in the 7th column of that file.
 
  In general: docker should do the equivalent of mount --make-rslave /
  as first thing after opening its mount namespace, so that from that
  point on mounts and especiall *un*mounts propagate from the host into
  the container, but not vice versa.
 
  If they do not invoke that, then the propagation will stay at
  shared, which means the mounts will appear in the host and vice
  versa, which is certainly undesired.
 
  Also, they should not use mount --make-rprivate /, as that means
  anything the host mounted will stay mounted in the container forever,
  which is a problem.
 
  Also, they really need to make this recursive, so that all mount
  points they have access too are detached from the host!
 
  Lennart
 
 
 


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] [logind] retroactive lid close handle upon vt switch

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 15:43, b3nmore (b3nm...@googlemail.com) wrote:

  Why precisely does your original session inhibit the lid switch? If
  you want to turn off the lid switch then turn it off properly,
  inhibition is not really about turning something fully off. It's about
  temporarily making logind not process it, for example, because you
  want to process it yourself or so.
  
  GNOME for example never inhibits the lid switch, because there's
  really no reason to. Why does your DE inhibit it?
 
 xfpm (the power manager of xfce) allows to configure how the system
 should react to certain power events. In this case you can configure it
 to either suspend or hibernate or lock the screen or just switch off the
 screen, when the lid is closed. In order to do so, xfpm inhibits the
 handle of the lid switch and initiates the configured pm action on its own.
 It works as intended with one exception, when one uses a screen locker,
 which switches vt's (other lockers are o.k.).

I'd strongly recommend not doing this this way. Inhibitors aren't
really for that. Change logind.conf, or so, to make this a system-wide
change. But doing this with inhibitors, only does this temproarily.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] Added Uplink failure detection feature to networkd

2015-01-23 Thread Alin Rauta
---
 Makefile.am |4 +
 man/systemd.netdev.xml  |   72 +-
 src/libsystemd/sd-network/sd-network.c  |  117 +++
 src/network/networkctl.c|  153 
 src/network/networkd-link.c |   35 +
 src/network/networkd-manager.c  |   36 +
 src/network/networkd-netdev-gperf.gperf |3 +
 src/network/networkd-netdev-ufd-group.c |  298 +++
 src/network/networkd-netdev-ufd-group.h |   85 ++
 src/network/networkd-netdev.c   |   36 +
 src/network/networkd-netdev.h   |6 +
 src/network/networkd-ufd-daemon.c   | 1321 +++
 src/network/networkd-ufd-daemon.h   |   34 +
 src/network/networkd.c  |7 +
 src/network/networkd.h  |6 +
 src/systemd/sd-network.h|   20 +
 16 files changed, 2231 insertions(+), 2 deletions(-)
 create mode 100644 src/network/networkd-netdev-ufd-group.c
 create mode 100644 src/network/networkd-netdev-ufd-group.h
 create mode 100644 src/network/networkd-ufd-daemon.c
 create mode 100644 src/network/networkd-ufd-daemon.h

diff --git a/Makefile.am b/Makefile.am
index 45d7a34..604173b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5575,6 +5575,8 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-netdev-tuntap.h \
src/network/networkd-netdev-bond.h \
src/network/networkd-netdev-bridge.h \
+   src/network/networkd-netdev-ufd-group.h \
+   src/network/networkd-ufd-daemon.h \
src/network/networkd-netdev.c \
src/network/networkd-netdev-tunnel.c \
src/network/networkd-netdev-veth.c \
@@ -5586,6 +5588,8 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-netdev-tuntap.c \
src/network/networkd-netdev-bond.c \
src/network/networkd-netdev-bridge.c \
+   src/network/networkd-netdev-ufd-group.c \
+   src/network/networkd-ufd-daemon.c \
src/network/networkd-link.c \
src/network/networkd-ipv4ll.c \
src/network/networkd-dhcp4.c \
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 7edec36..3c60441 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -168,8 +168,8 @@
 literalipip/literal, 
literalgre/literal,
 literalgretap/literal, 
literalsit/literal,
 literalvti/literal, 
literalveth/literal,
-literaltun/literal, 
literaltap/literal and
-literaldummy/literal
+literaltun/literal, 
literaltap/literal,
+literalufd/literal and 
literaldummy/literal
 are supported. This option is 
compulsory./para
 /listitem
 /varlistentry
@@ -553,6 +553,52 @@
 /refsect1
 
 refsect1
+title[UFDGroup] Section Options/title
+
+paraThe literal[UFDGroup]/literal section is 
used to define uplink failure detection group parameters.
+The section only applies for netdevs of kind 
literalufd/literal, and accepts the following key:/para
+
+variablelist class='network-directives'
+
+varlistentry
+termvarnameId=/varname/term
+listitem
+paraUplink failure detection 
group Id. This option is compulsory./para
+/listitem
+/varlistentry
+/variablelist
+/refsect1
+
+refsect1
+title[UFDLink] Section Options/title
+
+paraThe literal[UFDLink]/literal section is used 
to define one or more uplink failure detection links.
+The section only applies for netdevs of kind 
literalufd/literal, and accepts the following key:/para
+
+variablelist class='network-directives'
+
+varlistentry
+termvarnameName=/varname/term
+listitem
+paraAn interface name or an 
enumeration of interface names separated by comma.
+This option is 
compulsory./para
+/listitem
+/varlistentry
+
+varlistentry
+termvarnameType=/varname/term
+listitem
+

[systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd

2015-01-23 Thread Alin Rauta
Hi,

Uplink Failure Detection (UFD) is a key enhancement to networkd, that will 
provide support for the switch use case.
The links can be configured as uplinks or as downlinks inside an UFD group.
When all uplinks for a group are down, the failure is propagated to the 
downlinks, so the devices connected to them
can take a defined action. When at least one uplink become available, the 
daemon tries to bring the downlink ports up.

Multiple UFD groups can be configured through .netdev files. See below a 
configuration example:

[NetDev]
Name=group1
Kind=ufd

[UFDGroup]
Id=10

[UFDLink]
Name=sw0p1,sw0p2
Type=uplink

[UFDLink]
Name=sw0p3
Type=downlink

[UFDLink]
Name=sw0p4
Type=downlink


Few details on implementation:

Networkd waits until all links are enumerated (either static configured or 
unmanaged).
Only then it starts enumerating the groups.
networkctl command was also updated to support listing of ufd groups  
configuration. See below a print-out:

# networkctl ufd 10
? UFD Group: 10
Config File: /etc/systemd/network/ufd_to_test.netdev
  State: configured
Uplinks:
   ? 3: sw0p1
   ? 4: sw0p2
  Downlinks:
   ? 6: sw0p4
   ? 5: sw0p3

Please let me know what you think.

Thanks,
Alin

Alin Rauta (1):
  Added Uplink failure detection feature to networkd

 Makefile.am |4 +
 man/systemd.netdev.xml  |   72 +-
 src/libsystemd/sd-network/sd-network.c  |  117 +++
 src/network/networkctl.c|  153 
 src/network/networkd-link.c |   35 +
 src/network/networkd-manager.c  |   36 +
 src/network/networkd-netdev-gperf.gperf |3 +
 src/network/networkd-netdev-ufd-group.c |  298 +++
 src/network/networkd-netdev-ufd-group.h |   85 ++
 src/network/networkd-netdev.c   |   36 +
 src/network/networkd-netdev.h   |6 +
 src/network/networkd-ufd-daemon.c   | 1321 +++
 src/network/networkd-ufd-daemon.h   |   34 +
 src/network/networkd.c  |7 +
 src/network/networkd.h  |6 +
 src/systemd/sd-network.h|   20 +
 16 files changed, 2231 insertions(+), 2 deletions(-)
 create mode 100644 src/network/networkd-netdev-ufd-group.c
 create mode 100644 src/network/networkd-netdev-ufd-group.h
 create mode 100644 src/network/networkd-ufd-daemon.c
 create mode 100644 src/network/networkd-ufd-daemon.h

-- 
1.9.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 15:57, Michael Biebl (mbi...@gmail.com) wrote:

 2015-01-23 14:32 GMT+01:00 Lennart Poettering lenn...@poettering.net:
  On Fri, 23.01.15 04:24, Michael Biebl (mbi...@gmail.com) wrote:
 
  If distros still ship such a rc.local sysv init script, shouldn't they
  rather symlink that to
  the native rc-local.service? Sounds like the better alternative to me.
  Or alternatively, mask that service.
 
  E.g in Debian we have /etc/init.d/rc.local and ship a
  /lib/systemd/system/rc.local.service - rc-local.service
  symlink in the systemd package.
 
  I'd recommend not shipping the rc-local generator at all in Debian
  then. It was simply compat for some crappy logic where Fedora was
  executing two special scripts, that were not sysv during bootup and
  shutdown.
 
 Hm, you're probably right.
 I guess we could just statically enable rc-local.service in
 multi-user.target.wants and drop rc-local-generator.

I'd even remove rc-local.service from Debian. If this is a normal
sysvinit script, treat it as such, and let sysv-generator do its deed
on it. 

Given that you don't have the shutdown counterpart like Fedora has you
are then completely safe, without any special magic that we needed for
Fedora...

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] [PATCH] libudev: fix check for too long packet

2015-01-23 Thread Topi Miettinen
On 01/23/15 17:43, Lennart Poettering wrote:
 On Fri, 23.01.15 17:29, Topi Miettinen (toiwo...@gmail.com) wrote:
 
 On 01/23/15 03:06, Lennart Poettering wrote:
 On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote:

 Don't use recvmsg(2) return value to check for too long packets
 (it doesn't work) but MSG_TRUNC flag.

 Why precisely doesn't this work? I mean, it will consider messages
 that are exactly as large as the buffer as too long, but otherwise the
 old check should be fine, no?

 It doesn't work because the return value of recvmsg() never exceeds the
 buffer size, so too large packets are never detected.
 
 But the test was =, not . So the old code *did* recognize all
 too large packets, though it would already do so one byte earlier than
 your new check...

True. What should be considered too large, a full buffer (which might
not contain a trailing zero, so the strcmp later could fall off of the
buffer...), or buffer size - 1 (the last byte is not explicitly set to
zero, so badness could happen anyway)?

-Topi

 
 Lennart
 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] libudev: fix check for too long packet

2015-01-23 Thread Topi Miettinen
On 01/23/15 03:06, Lennart Poettering wrote:
 On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote:
 
 Don't use recvmsg(2) return value to check for too long packets
 (it doesn't work) but MSG_TRUNC flag.
 
 Why precisely doesn't this work? I mean, it will consider messages
 that are exactly as large as the buffer as too long, but otherwise the
 old check should be fine, no?

It doesn't work because the return value of recvmsg() never exceeds the
buffer size, so too large packets are never detected.

-Topi

 
 (The new check is much nicer though, admittedly)
 
 ---
  src/libudev/libudev-monitor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
 index 484fefe..d8e551b 100644
 --- a/src/libudev/libudev-monitor.c
 +++ b/src/libudev/libudev-monitor.c
 @@ -609,7 +609,7 @@ retry:
  return NULL;
  }
  
 -if (buflen  32 || (size_t)buflen = sizeof(buf)) {
 +if (buflen  32 || smsg.msg_flags  MSG_TRUNC) {
  log_debug(invalid message length);
  return NULL;
  }
 -- 
 2.1.4

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
 
 Lennart
 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] libudev: fix check for too long packet

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 17:29, Topi Miettinen (toiwo...@gmail.com) wrote:

 On 01/23/15 03:06, Lennart Poettering wrote:
  On Sun, 18.01.15 23:57, Topi Miettinen (toiwo...@gmail.com) wrote:
  
  Don't use recvmsg(2) return value to check for too long packets
  (it doesn't work) but MSG_TRUNC flag.
  
  Why precisely doesn't this work? I mean, it will consider messages
  that are exactly as large as the buffer as too long, but otherwise the
  old check should be fine, no?
 
 It doesn't work because the return value of recvmsg() never exceeds the
 buffer size, so too large packets are never detected.

But the test was =, not . So the old code *did* recognize all
too large packets, though it would already do so one byte earlier than
your new check...

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] Docker vs PrivateTmp

2015-01-23 Thread Daniel J Walsh
Yes I was trying to get a comment from Alex, since he did the original
patch.

On 01/23/2015 12:26 PM, Lennart Poettering wrote:
 On Fri, 23.01.15 11:31, Daniel J Walsh (dwa...@redhat.com) wrote:

 You just sent a full quote without any comment of yours?

 On 01/22/2015 10:02 PM, Lennart Poettering wrote:
 On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:

 See the `devicemapper` mountpoint created by Docker for the container:

 # grep devicemapper/mnt /proc/mounts
 
 /dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
 
 /var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
 ext4
 
 rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
 0 0
 I am not sure why docker makes these mounts visible in the host
 namespace at all. This smells like a bug.

 Watch Docker fail to destroy the container because it is unable to remove 
 the mountpoint directory:

 Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
 time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
 /containers/{name:.*} returned error: Cannot destroy container 
 e68df3f45d61:
 Driver devicemapper failed to remove root filesystem
 e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62: 
 Device is
 Busy
 This smells as if Docker incorrectly sets the mount propagation bits
 on its own mounts.

 It would be good checking /proc/self/mountinfo inside and outside of
 docker's own namespace, and checking how the propagation bits are set
 for the individual mounts. It's a bit hard to read, but the
 interesting bits are in the 7th column of that file.

 In general: docker should do the equivalent of mount --make-rslave /
 as first thing after opening its mount namespace, so that from that
 point on mounts and especiall *un*mounts propagate from the host into
 the container, but not vice versa.

 If they do not invoke that, then the propagation will stay at
 shared, which means the mounts will appear in the host and vice
 versa, which is certainly undesired.

 Also, they should not use mount --make-rprivate /, as that means
 anything the host mounted will stay mounted in the container forever,
 which is a problem.

 Also, they really need to make this recursive, so that all mount
 points they have access too are detached from the host!

 Lennart



 Lennart


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Simon McVittie
On 23/01/15 17:52, Lennart Poettering wrote:
 On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
 El 23/01/15 a las 10:31, Lennart Poettering escribió:
 The rc-local generator only exists to add compat support for those
 systems where it never was a sysvinit script anyway...

 They are not init scripts though. but plain shell scripts with no dependency
 information. they are installed in /etc/init.d, therefore we end with units
 generated by both the sysv-generator and the rc-local generator.
 
 Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
 Debian places it in /etc/init.d, that it is a proper sysvinit script...

In Debian, /etc/init.d/rc.local is a sysvinit script with LSB init info.
It is a normal sysvinit script, except that it has Required-Start: $all
so that it will be sequenced after all other init scripts.

It runs /etc/rc.local, which is a simple shell script with no dependency
magic. If a sysadmin has not customized /etc/rc.local, it only contains
some comments and exit 0.

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Cristian Rodríguez

El 23/01/15 a las 14:52, Lennart Poettering escribió:

On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:


El 23/01/15 a las 10:31, Lennart Poettering escribió:


The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script anyway...



They are not init scripts though. but plain shell scripts with no dependency
information. they are installed in /etc/init.d, therefore we end with units
generated by both the sysv-generator and the rc-local generator.


Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
Debian places it in /etc/init.d, that it is a proper sysvinit script...


SUSE has this scripts..

Extra start script: /etc/init.d/boot.local
Extra stop script:   /etc/init.d/halt.local

The are not init scripts, but legacy shell scripts that naive people 
insist on wanting to use.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Michael Biebl
2015-01-23 18:51 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 I'd even remove rc-local.service from Debian. If this is a normal
 sysvinit script, treat it as such, and let sysv-generator do its deed
 on it.

The /etc/init.d/rc.local init script does nothing else then run
/etc/rc.local, in case this file is executable.

By using the native rc-local.service file, we avoid one bash invocation.
Not that big of a deal, but if we can avoid that, why not.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container

2015-01-23 Thread Lennart Poettering
On Fri, 16.01.15 19:32, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 В Thu, 15 Jan 2015 19:24:25 -0500
 Stéphane Graber stgra...@ubuntu.com пишет:
 
  @@ -871,6 +871,14 @@ static void mount_enter_unmounting(Mount *m) {
   m-control_command_id = MOUNT_EXEC_UNMOUNT;
   m-control_command = m-exec_command + MOUNT_EXEC_UNMOUNT;
   
  +/* Ignore any mounts under /dev, /proc or /sys */
  +if (path_startswith(m-where, /dev/) ||
  +path_startswith(m-where, /proc/) ||
  +path_startswith(m-where, /sys/)) {
  +mount_set_state(m, MOUNT_DEAD);
  +return;
  +}
  +
 
 This does not look right either. I'd rather expect to a) set
 DefaultDependencies=no for these special mounts so that they are left
 at shutdown and b) ignore them in the final killing spree if needed
 (unless happens already).

I pretty much implemented this now, though instead of setting
DefaultDependencies=no for these mounts I just made
DefaultDependencies=yes have no effect for them. But the general
approach I agree with.

 If I as user do systemctl stop /dev/pts I expect it to
 unmount /dev/pts not fake dead state.

Well, /dev/pts is not a mount point systemd picks up anyway, so the
unit for that doesn't even exist. It's already exempted. But I do get
your point and I agree.

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] persisting sriov_numvfs

2015-01-23 Thread Martin Polednik


- Original Message -
 From: Lennart Poettering lenn...@poettering.net
 To: Dan Kenigsberg dan...@redhat.com
 Cc: systemd-devel@lists.freedesktop.org, mpole...@redhat.com, 
 ibar...@redhat.com
 Sent: Friday, January 23, 2015 3:49:59 AM
 Subject: Re: [systemd-devel] persisting sriov_numvfs
 
 On Mon, 19.01.15 14:18, Dan Kenigsberg (dan...@redhat.com) wrote:
 
  Hello, list.
  
  I'm an http://oVirt.org developer, and we plan to (finally) support
  SR-IOV cards natively. Working on this feature, we've noticed that
  something is missing in the platform OS.
  
  If I maintain a host with sr-iov cards, I'd like to use the new kernel
  method of defining how many virtual functions (VFs) are to be exposed by
  each physical function:
 
 Quite frankly, I cannot make sense of these sentences. I have no clue
 what a SR-IOV, virtual function, physical function is supposed
 to be.
 
 Please explain what this all is, before we can think of adding any
 friendlier config option to udev/networkd/systemd for this.

Hello,

I'm oVirt developer responsible for VFIO/SR-IOV passthrough on the host
side.

SR-IOV is a specification from PCI SIG, where single hardware device
(we're using NICs for example) can actually act as a multiple devices.
This device is then considered PF (physical function) and spawned devices
are so called VFs (virtual functions). This functionality allows system
administrators to assign these devices to virtual machines to get near
bare metal performance of the device and possibly share it amongst multiple
VMs.

Spawning of the VFs was previously done via device driver, using max_vfs
attribute. This means that if you wanted to persist these VFs, you had to
add this to modules-load.d. Since some of the device driver creators used
different names, spawning of VFs was moved to sysfs and can be operated via
echo ${number}  /sys/bus/pci/devices/${device_name}/sriov_numvfs where
${number} = /sys/bus/pci/devices/${device_name}/sriov_totalvfs and if 
changing the number of VFs from nonzero value, it first needs to be set to 0.

We've encountered the need to persist this configuration and load it before
network scripts (and possibly in future other scripts) so that the hardware
can be referenced in those scripts. There is currently no such option. We
are seeking help in creating a standardized way of handling this persistence.

mpolednik
 
 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] [logind] retroactive lid close handle upon vt switch

2015-01-23 Thread Lennart Poettering
On Wed, 21.01.15 12:33, b3nmore (b3nm...@googlemail.com) wrote:

 Hello,
 
 consider two vt sessions vt1, vt2. On vt1 handle-lid-switch is
 inhibited. Now the lid is closed and than a vt switch takes place (e.g.
 sleep 10  loginctl activate vt2). Now the system suspends. I guess
 this is because the new active session has no inhibitor lock on
 handle-lid-switch and therefor retroactively reacts to the closed lid.
 
 Is this intentional or could it be changed?

Yeah, this is intentional, button inhibtiros are bound to the active
session, as they are about processing input keys, and only the fg
session should be able to do that.

Why precisely does your original session inhibit the lid switch? If
you want to turn off the lid switch then turn it off properly,
inhibition is not really about turning something fully off. It's about
temporarily making logind not process it, for example, because you
want to process it yourself or so.

GNOME for example never inhibits the lid switch, because there's
really no reason to. Why does your DE inhibit it?

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] service.d/.conf files and multi-valued options

2015-01-23 Thread Christian Seiler

Am 2015-01-23 14:27, schrieb Lennart Poettering:
Yes, it does, although only in the general systemd.unit(5), not in 
the

specific options, so maybe it's not that easy to find.


Actually, it kinda says it in the specific options. From the
explanation of ExecStart=:

...If the empty string is assigned to this option, the list of
commands to start is reset, prior assignments of this option will 
have

no effect...


Oh, I didn't see that while skimming the man page. Still, I think a
tutorial manpage as I described (different ways to override distro
configuration) would be a good idea. Would you accept a patch for
something like that? If so, what should the man page be called?


And at the explanation of ExecStartPre= says the syntax is identical
to ExecStart=. So I think we are covered here.


No, sure, I don't think ExecStartPre= needs additional information,
I just didn't see the sentence in ExecStart=, sorry about that.


Btw. it would also be nice to have a possibility to just remove a
specific entry from a list, not to reset it completely. Probably 
less

for things like Exec*=, but more for After=/Before=/...

For example, if there's a unit with After=b.service c.service und as
an admin I want to not order it after c.service, I will have to 
first

reset the list (empty After=) and then add all the current other
units it orders after again. If an update then makes the unit also 
be
ordered after d.service to fix some other bug, the local setting 
will

override the After=d.service too...

Maybe something like 'After-=c.service'? Although that would 
probably

break traditional ini parsers trying to process unit files...


I'd be very careful with coming up with more and more syntaxes like
this. People have also requested +=, to append things to existing
lines.


I agree that I also don't like that syntax, but:


I think for simplicity's sake the right approach to remove parts of a
unit file is to copy it from /usr to /etc, and then modify it
there. .d/ is not the answer to everything. I am aware of course that
copying the files from /usr to /etc will also disconnect you from
new unit files added by package updates, but I guess you cannot have 
a

cake and eat it too...


But if I want to add something to After=/Before=/..., I can easily do
that with a drop-in just containing After=foo.service. And that's 
indeed

very useful, I've used that a couple of times. So for symmetry reasons,
I think the converse would also be quite useful (although I haven't
needed it that often). I don't have a good idea for the syntax just 
now,

but would you be opposed to at least adding 'design a syntax for this'
to the TODO list?

Christian

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Swap gets activated twice (through fstab and gpt generators)

2015-01-23 Thread Martin Pitt
Hello all,

we just received a report (https://launchpad.net/bugs/1399595) that
swap gets activated twice:

| systemd[1]: Activating swap Swap Partition...
| systemd[1]: Activating swap 
/dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb...
| swapon[396]: swapon: /dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb: 
swapon failed: Device or resource busy
| systemd[1]: 
dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.swap swap 
process exited, code=exited status=255
| systemd[1]: Failed to activate swap 
/dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb.
| systemd[1]: Unit 
dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.swap 
entered failed state.
| systemd[1]: Activated swap Swap Partition.
| kernel: Adding 8298492k swap on /dev/sda3. Priority:-1 extents:1 
across:8298492k SSFS

It turns out that the fstab and the gpt generator are overlapping here. gpt
creates a unit dev-sda3.swap:

| # Automatically generated by systemd-gpt-auto-generator
|
| [Unit]
| Description=Swap Partition
| Documentation=man:systemd-gpt-auto-generator(8)
|
| [Swap]
| What=/dev/sda3
| /tmp/r/tmp/gpt/dev-sda3.swap (END)

while /etc/fstab has

| # sda3
| UUID=73d341f1-eedc-43fc-9e53-ba4194dae3fb none swap sw 0 0

and thus the fstab generator creates one for the UUID name
dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.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-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb
| Options=sw

Thus we get two units for the same swap device, and worse, the gpt one
won over the fstab one (just by sheer chance, this is a race).

So this is a bit tricky; obviously both units are justified: we want
the auto-discovery in gpt, and enable swap from fstab without GPT.

One idea would be to resolve symlinks after the generators (in
particular fstab) discovered the device names. Then fstab would also
create a dev-sda3.swap, and that unit would override the one generated
by gpt. As fstab should always win over gpt (as you might have
additional options there), gpt should write into .late and fstab
into early or normal?

There is a potential problem, though: at the time when the generator
runs, the device might not exist yet; it might take longer to be
detected, or it's on LVM or behind a still locked LUKS etc. In that
case the /dev/disks/... link doesn't even exist yet and we can't
resolve it.

So perhaps the more robust fix would be to make the gpt generator not
generate swap units if fstab already configures any swap device? I. e.
auto-discovery and swaps in fstab are mutually exclusive then.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 18:44, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

 On 23/01/15 17:52, Lennart Poettering wrote:
  On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
  El 23/01/15 a las 10:31, Lennart Poettering escribió:
  The rc-local generator only exists to add compat support for those
  systems where it never was a sysvinit script anyway...
 
  They are not init scripts though. but plain shell scripts with no 
  dependency
  information. they are installed in /etc/init.d, therefore we end with units
  generated by both the sysv-generator and the rc-local generator.
  
  Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
  Debian places it in /etc/init.d, that it is a proper sysvinit script...
 
 In Debian, /etc/init.d/rc.local is a sysvinit script with LSB init info.
 It is a normal sysvinit script, except that it has Required-Start: $all
 so that it will be sequenced after all other init scripts.
 
 It runs /etc/rc.local, which is a simple shell script with no dependency
 magic. If a sysadmin has not customized /etc/rc.local, it only contains
 some comments and exit 0.

I see. In this case I would remove all of systemd's special rc-local
magic from the package and just make use of the normal sysvinit
support for it.

We can even add a compile time option to systemd upstream that
disables this part without removing all of sysvinit support.

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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 15:51, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

 El 23/01/15 a las 14:52, Lennart Poettering escribió:
 On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
 
 El 23/01/15 a las 10:31, Lennart Poettering escribió:
 
 The rc-local generator only exists to add compat support for those
 systems where it never was a sysvinit script anyway...
 
 
 They are not init scripts though. but plain shell scripts with no dependency
 information. they are installed in /etc/init.d, therefore we end with units
 generated by both the sysv-generator and the rc-local generator.
 
 Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
 Debian places it in /etc/init.d, that it is a proper sysvinit script...
 
 SUSE has this scripts..
 
 Extra start script: /etc/init.d/boot.local
 Extra stop script:   /etc/init.d/halt.local
 
 The are not init scripts, but legacy shell scripts that naive people insist
 on wanting to use.

Hmm, and tools that enumerate sysv scripts will now find both the real
sysvinit scripts and this one that actually isn't and cannot make
sense of it? 

What does chkconfig boot.local on traditionally do on Suse then? 

This appears to be a really weird setup on suse...

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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Colin Guthrie
Michael Biebl wrote on 23/01/15 03:24:
 and ship a
 /lib/systemd/system/rc.local.service - rc-local.service
 symlink in the systemd package.

Hmm, doesn't that break the
/usr/lib/systemd/system-generators/systemd-rc-local-generator logic? Or
do you not ship that in Debian?

The whole point of this generator is to look for /etc/init.d/rc.local
and check that it's executable and then add it in with appropriate deps
so it runs at the correct time (i.e. quite late)

Maybe I'm missing something that the above trick would achieve?

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-sysv-generator *.service: File exists

2015-01-23 Thread poma
On 22.01.2015 23:21, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Jan 22, 2015 at 10:05:48PM +0100, poma wrote:

 Buena noches,

 Maybe someone knows how to get rid of these messages?
 Does systemd-216-17.fc21.x86_64 help?
 
 Zbyszek
 


I should have checked before, nx*3.5 files that was causing this noise is the 
backup leftover from nx4 testing.
Removing these two files, there is no need to upgrade.
Thanks for reply, man.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread David Herrmann
Hi

On Thu, Jan 22, 2015 at 3:53 PM, Christian Seiler christ...@iwakd.de wrote:
 [1] Note that the only other issue I stumbled upon has now been fixed,
 so in general I would say that systemd already works really well
 in containers without CAP_SYS_ADMIN if you know how to set them
 up properly.

Just as a heads-up: The device-delegation API
(src/logind/logind-session-device.c) will also fail if you run without
CAP_SYS_ADMIN. Admittedly, DRM and input devices usually don't matter
in containers, so it's fine. But on main systems, we really need
CAP_SYS_ADMIN.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Igor Bukanov
It is not clear from the systemd.unit manual page what happens when
foo.service.d/bar.conf sets an option like Service/ExecStartPre that
can be specified multiple times. From experimenting I see that *.conf
files supply additional values to the option and to overwrite or
remove already given values for the option one have to copy the whole
file into /etc and edit it there. Is it so?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-sysv-generator *.service: File exists

2015-01-23 Thread Martin Pitt
poma [2015-01-23 11:38 +0100]:
 I should have checked before, nx*3.5 files that was causing this noise is the 
 backup leftover from nx4 testing.
 Removing these two files, there is no need to upgrade.

This almost certainly needs this fix:

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=77354c7e6

which isn't included in the Fedora package AFAICS, at least not in

  
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f21id=e1b4cbef8aaca5e

But removing the backup files will work fine indeed.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Christian Seiler

Am 2015-01-23 12:21, schrieb Matthias Urlichs:

Igor Bukanov:

It is not clear from the systemd.unit manual page what happens when
foo.service.d/bar.conf sets an option like Service/ExecStartPre that
can be specified multiple times. From experimenting I see that 
*.conf

files supply additional values to the option and to overwrite or
remove already given values for the option one have to copy the 
whole

file into /etc and edit it there. Is it so?


Doesn't the manpage state that an empty entry clears the list?


Yes, it does, although only in the general systemd.unit(5), not in the
specific options, so maybe it's not that easy to find.

I think it would be nice to have some kind of man page that is a
tutorial as to what are the best practices to override distro service
files with your own site-specific configuration, which also includes
a couple of simple examples that cover the most common cases.

Btw. it would also be nice to have a possibility to just remove a
specific entry from a list, not to reset it completely. Probably less
for things like Exec*=, but more for After=/Before=/...

For example, if there's a unit with After=b.service c.service und as
an admin I want to not order it after c.service, I will have to first
reset the list (empty After=) and then add all the current other
units it orders after again. If an update then makes the unit also be
ordered after d.service to fix some other bug, the local setting will
override the After=d.service too...

Maybe something like 'After-=c.service'? Although that would probably
break traditional ini parsers trying to process unit files...

Christian

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-sysv-generator *.service: File exists

2015-01-23 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jan 23, 2015 at 11:53:03AM +0100, Martin Pitt wrote:
 poma [2015-01-23 11:38 +0100]:
  I should have checked before, nx*3.5 files that was causing this noise is 
  the backup leftover from nx4 testing.
  Removing these two files, there is no need to upgrade.
 
 This almost certainly needs this fix:
 
   http://cgit.freedesktop.org/systemd/systemd/commit/?id=77354c7e6
 
 which isn't included in the Fedora package AFAICS, at least not in
 
   
 http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f21id=e1b4cbef8aaca5e
 
 But removing the backup files will work fine indeed.
Thanks, I'll add that patch too.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 14:15, Christian Seiler (christ...@iwakd.de) wrote:

 Am 2015-01-23 12:21, schrieb Matthias Urlichs:
 Igor Bukanov:
 It is not clear from the systemd.unit manual page what happens when
 foo.service.d/bar.conf sets an option like Service/ExecStartPre that
 can be specified multiple times. From experimenting I see that *.conf
 files supply additional values to the option and to overwrite or
 remove already given values for the option one have to copy the whole
 file into /etc and edit it there. Is it so?
 
 Doesn't the manpage state that an empty entry clears the list?
 
 Yes, it does, although only in the general systemd.unit(5), not in the
 specific options, so maybe it's not that easy to find.

Actually, it kinda says it in the specific options. From the
explanation of ExecStart=:

...If the empty string is assigned to this option, the list of
commands to start is reset, prior assignments of this option will have
no effect...

And at the explanation of ExecStartPre= says the syntax is identical
to ExecStart=. So I think we are covered here. I mean, we could
certainly duplicate the discussion of ExecStart= at ExecStartPre=, but
I think it's nicer to just reference it again.

 Btw. it would also be nice to have a possibility to just remove a
 specific entry from a list, not to reset it completely. Probably less
 for things like Exec*=, but more for After=/Before=/...
 
 For example, if there's a unit with After=b.service c.service und as
 an admin I want to not order it after c.service, I will have to first
 reset the list (empty After=) and then add all the current other
 units it orders after again. If an update then makes the unit also be
 ordered after d.service to fix some other bug, the local setting will
 override the After=d.service too...
 
 Maybe something like 'After-=c.service'? Although that would probably
 break traditional ini parsers trying to process unit files...

I'd be very careful with coming up with more and more syntaxes like
this. People have also requested +=, to append things to existing
lines. 

I think for simplicity's sake the right approach to remove parts of a
unit file is to copy it from /usr to /etc, and then modify it
there. .d/ is not the answer to everything. I am aware of course that
copying the files from /usr to /etc will also disconnect you from
new unit files added by package updates, but I guess you cannot have a
cake and eat it too...

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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Thu, 22.01.15 23:52, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

 ---
  src/sysv-generator/sysv-generator.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/src/sysv-generator/sysv-generator.c 
 b/src/sysv-generator/sysv-generator.c
 index b8b77aa..d6e4dfa 100644
 --- a/src/sysv-generator/sysv-generator.c
 +++ b/src/sysv-generator/sysv-generator.c
 @@ -775,6 +775,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap 
 *all_services) {
  fpath = strjoin(*path, /, de-d_name, NULL);
  if (!fpath)
  return log_oom();
 +#ifdef RC_LOCAL_SCRIPT_PATH_START
 +if(streq(fpath, RC_LOCAL_SCRIPT_PATH_START))
 +continue;
 +#endif
 +#ifdef RC_LOCAL_SCRIPT_PATH_STOP
 +if(streq(fpath, RC_LOCAL_SCRIPT_PATH_STOP))
 +continue;
 +#endif

Hmm? If you distro ships the rc local stuff as normal sysv init
script, then use that it as such, and consider dropping the rc-local
generator entirely from your distro.

The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script anyway...

The whole idea of rc.local is pretty crazy anyway, we certainly
shouldn't add more code for this anymore...

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] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.

2015-01-23 Thread Kay Sievers
On Fri, Jan 23, 2015 at 2:13 PM, Robert Milasan rmila...@suse.com wrote:
 How to reproduce:

 run: udevadm control --stop-exec-queue
 add: new device, for example a usb stick/disk
  (it will create /run/udev/queue)
 run: udevadm settle --timeout=10

 The last command will hang/stall, because it checks constantly
 for /run/udev/queue, which exists and always will unless the user
 doesn't start the event execution or deletes manually /run/udev/queue.

 Signed-off-by: Robert Milasan rmila...@suse.com
 ---
  src/udev/udevadm-settle.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
 index 6bcb3a9..80529ce 100644
 --- a/src/udev/udevadm-settle.c
 +++ b/src/udev/udevadm-settle.c
 @@ -116,6 +116,11 @@ static int adm_settle(struct udev *udev, int argc,
 char *argv[]) { udev_ctrl_unref(uctrl);
  return EXIT_SUCCESS;
  }
 +if (udev_ctrl_get_stop_exec_queue(uctrl)  0) {

How does udev_ctrl_get_stop_exec_queue() operate on a ctrl object and not a msg?

How would udevadm process incoming control packets, or know that way
about the state of the running daemon?

If the event execution is disabled, there are pending events and
settle should block.

The entire idea of disabling the even handling is very questionable,
what are you trying to do/fix here?

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 04:24, Michael Biebl (mbi...@gmail.com) wrote:

 2015-01-23 3:52 GMT+01:00 Cristian Rodríguez crrodrig...@opensuse.org:
  ---
   src/sysv-generator/sysv-generator.c | 8 
   1 file changed, 8 insertions(+)
 
  diff --git a/src/sysv-generator/sysv-generator.c 
  b/src/sysv-generator/sysv-generator.c
  index b8b77aa..d6e4dfa 100644
  --- a/src/sysv-generator/sysv-generator.c
  +++ b/src/sysv-generator/sysv-generator.c
  @@ -775,6 +775,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap 
  *all_services) {
   fpath = strjoin(*path, /, de-d_name, NULL);
   if (!fpath)
   return log_oom();
  +#ifdef RC_LOCAL_SCRIPT_PATH_START
  +if(streq(fpath, RC_LOCAL_SCRIPT_PATH_START))
  +continue;
  +#endif
 
 If distros still ship such a rc.local sysv init script, shouldn't they
 rather symlink that to
 the native rc-local.service? Sounds like the better alternative to me.
 Or alternatively, mask that service.
 
 E.g in Debian we have /etc/init.d/rc.local and ship a
 /lib/systemd/system/rc.local.service - rc-local.service
 symlink in the systemd package.
 
  +#ifdef RC_LOCAL_SCRIPT_PATH_STOP
  +if(streq(fpath, RC_LOCAL_SCRIPT_PATH_STOP))
  +continue;
  +#endif
 
 Same here. Besides, isn't that stop script supposed to be /sbin/halt.local?
 Debian doesn't have such a halt.local script, so I assume this is/was
 some Red Hat / SuSE specific extension?

I'd recommend not shipping the rc-local generator at all in Debian
then. It was simply compat for some crappy logic where Fedora was
executing two special scripts, that were not sysv during bootup and
shutdown.

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] service.d/.conf files and multi-valued options

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 14:57, Christian Seiler (christ...@iwakd.de) wrote:

 Am 2015-01-23 14:27, schrieb Lennart Poettering:
 Yes, it does, although only in the general systemd.unit(5), not in the
 specific options, so maybe it's not that easy to find.
 
 Actually, it kinda says it in the specific options. From the
 explanation of ExecStart=:
 
 ...If the empty string is assigned to this option, the list of
 commands to start is reset, prior assignments of this option will have
 no effect...
 
 Oh, I didn't see that while skimming the man page. Still, I think a
 tutorial manpage as I described (different ways to override distro
 configuration) would be a good idea. Would you accept a patch for
 something like that? If so, what should the man page be called?

Sure, we can always use more man pages! Maybe simply call it
systemd.turorial or so, which could then get sections explainaining
how to best write new unit files, how to override/extend vendor unit
files, and so on.

 I think for simplicity's sake the right approach to remove parts of a
 unit file is to copy it from /usr to /etc, and then modify it
 there. .d/ is not the answer to everything. I am aware of course that
 copying the files from /usr to /etc will also disconnect you from
 new unit files added by package updates, but I guess you cannot have a
 cake and eat it too...
 
 But if I want to add something to After=/Before=/..., I can easily do
 that with a drop-in just containing After=foo.service. And that's indeed
 very useful, I've used that a couple of times. So for symmetry reasons,
 I think the converse would also be quite useful (although I haven't
 needed it that often). I don't have a good idea for the syntax just now,
 but would you be opposed to at least adding 'design a syntax for this'
 to the TODO list?

It's not just the syntax I am concerned about. It's more about
overloading the language with too many features. It's supposed to be
easy to parse, just a bunch of assigments. In fact the assignment of
the empty string to reset lists is already a bit in the territory of
this might be too complex...

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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Martin Pitt
Michael Biebl [2015-01-23 13:27 +0100]:
 - It avoids that a rc.local.service file is generated by the sysv-generator

Not with upstream systemd, the sysv generator doesn't check if there's
already a unit of that name (as it produces them in generator.late/).
The Debian package has a patch for this [1]; it might make sense to
upstream this as I think it's generally a good idea -- there's no need
to synthesize units which we are never going to call, it's just a
waste of resources.

Martin

[1] 
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Do-not-generate-systemd-units-from-sysv-init-scripts.patch?h=experimental

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/2] logind: remove per-user runtime dir again if setup fails

2015-01-23 Thread Christian Seiler
If setup of per-user runtime dir fails, clean up afterwards by removing
the directory before returning from the function, so we don't leave the
directory behind.

If this is not done, the second time the user logs in logind would
assume that the directory is already set up, even though it isn't.
---
 src/login/logind-user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 49c373b..d7930ad 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -336,6 +336,9 @@ static int user_mkdir_runtime_path(User *u) {
 
 r = mount(tmpfs, p, tmpfs, MS_NODEV|MS_NOSUID, t);
 if (r  0) {
+/* try to clean up, but ignore errors */
+r = -errno;
+rmdir(p);
 log_error_errno(r, Failed to mount per-user tmpfs 
directory %s: %m, p);
 goto fail;
 }
-- 
2.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/2] logind: chown+chmod /run/user/$UID if mount(tmpfs) fails with EPERM

2015-01-23 Thread Christian Seiler
In containers without CAP_SYS_ADMIN, it is not possible to mount tmpfs
(or any filesystem for that matter) on top of /run/user/$UID.
Previously, logind just failed in such a situation.

Now, logind will resort to chown+chmod of the directory instead. This
allows logind still to work in those environments, although without the
guarantees it provides (i.e. users not being able to DOS /run or other
users' /run/user/$UID space) when CAP_SYS_ADMIN is available.
---
 src/login/logind-user.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index d7930ad..3f7e3ce 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -335,12 +335,28 @@ static int user_mkdir_runtime_path(User *u) {
 }
 
 r = mount(tmpfs, p, tmpfs, MS_NODEV|MS_NOSUID, t);
-if (r  0) {
+if (r  0  errno != EPERM) {
 /* try to clean up, but ignore errors */
 r = -errno;
 rmdir(p);
 log_error_errno(r, Failed to mount per-user tmpfs 
directory %s: %m, p);
 goto fail;
+} else if (r  0  errno == EPERM) {
+/* we probably don't have CAP_SYS_ADMIN and are in a
+ * container, so just try to chown()/chmod() the
+ * directory. */
+log_debug(Failed to mount per-user tmpfs directory 
%s, just setting permissions., p);
+
+r = chown(p, u-uid, u-gid);
+if (r = 0)
+r = chmod(p, 0700);
+
+if (r  0) {
+r = -errno;
+rmdir(p);
+log_error_errno(r, Failed to change 
permissions of per-user tmpfs directory %s: %m, p);
+goto fail;
+}
 }
 }
 
@@ -513,8 +529,17 @@ static int user_remove_runtime_path(User *u) {
 if (r  0)
 log_error_errno(r, Failed to remove runtime directory %s: 
%m, u-runtime_path);
 
-if (umount2(u-runtime_path, MNT_DETACH)  0)
-log_error_errno(errno, Failed to unmount user runtime 
directory %s: %m, u-runtime_path);
+r = umount2(u-runtime_path, MNT_DETACH);
+if (r  0) {
+r = -errno;
+/* only log an error if the directory was a mount point,
+ * otherwise it could just be that we weren't able to
+ * mount it because we don't have CAP_SYS_AMDIN. */
+if (path_is_mount_point(u-runtime_path, false)  0)
+log_error_errno(r, Failed to unmount user runtime 
directory %s: %m, u-runtime_path);
+else
+log_debug_errno(r, Failed to unmount user runtime 
directory %s: %m, u-runtime_path);
+}
 
 r = rm_rf(u-runtime_path, false, true, false);
 if (r  0)
-- 
2.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Matthias Urlichs
Hi,

Dimitri John Ledkov:
  foo.service.d/bar.conf sets an option like Service/ExecStartPre that
  can be specified multiple times.
  Doesn't the manpage state that an empty entry clears the list?
 
 A snippet:
 [Unit]
 Wants=
 
 Does not remove want dependencies declared in the unit section in the
 unit file under /usr.

Meh. Obviously that works only for some unit file entries, not for others.

Time to impart more consistency?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [logind] retroactive lid close handle upon vt switch

2015-01-23 Thread b3nmore
On 01/23/2015 02:56 PM, Lennart Poettering wrote:
 Yeah, this is intentional, button inhibtiros are bound to the active
 session, as they are about processing input keys, and only the fg
 session should be able to do that.

One could argue here, that the lid close event has been already
processed by the than active session and a session, which gets activated
after the event, should not react retrospectively on it(?).

 Why precisely does your original session inhibit the lid switch? If
 you want to turn off the lid switch then turn it off properly,
 inhibition is not really about turning something fully off. It's about
 temporarily making logind not process it, for example, because you
 want to process it yourself or so.
 
 GNOME for example never inhibits the lid switch, because there's
 really no reason to. Why does your DE inhibit it?

xfpm (the power manager of xfce) allows to configure how the system
should react to certain power events. In this case you can configure it
to either suspend or hibernate or lock the screen or just switch off the
screen, when the lid is closed. In order to do so, xfpm inhibits the
handle of the lid switch and initiates the configured pm action on its own.
It works as intended with one exception, when one uses a screen locker,
which switches vt's (other lockers are o.k.).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Christian Seiler

Am 2015-01-23 08:29, schrieb Mantas Mikulėnas:

IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas...
if thats still a problem, maybe there could be one tmpfs at 
/run/user,

still preventing users from touching root-only /run?


Yes, that's a good idea. Initially when posting this thread I thought
that there just had to be a trade-off between dropping CAP_SYS_ADMIN
(and making it more difficult to escape the container), and a user
inside the container DOSing the container by filling up /run.

But with your idea, I can at least separate /run/user from /run
itself (the same way mode=1777 /run/lock is a separate tmpfs already)
by just a simple static mount entry for the container.

Thanks for bringing this up!

Christian

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Dimitri John Ledkov
On 23 January 2015 at 11:21, Matthias Urlichs matth...@urlichs.de wrote:
 Hi,

 Igor Bukanov:
 It is not clear from the systemd.unit manual page what happens when
 foo.service.d/bar.conf sets an option like Service/ExecStartPre that
 can be specified multiple times. From experimenting I see that *.conf
 files supply additional values to the option and to overwrite or
 remove already given values for the option one have to copy the whole
 file into /etc and edit it there. Is it so?

 Doesn't the manpage state that an empty entry clears the list?


A snippet:
[Unit]
Wants=

Does not remove want dependencies declared in the unit section in the
unit file under /usr.

/me continues my unwants ramblings.


-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service.d/.conf files and multi-valued options

2015-01-23 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jan 23, 2015 at 03:12:11PM +0100, Lennart Poettering wrote:
 On Fri, 23.01.15 14:57, Christian Seiler (christ...@iwakd.de) wrote:
 
  Am 2015-01-23 14:27, schrieb Lennart Poettering:
  Yes, it does, although only in the general systemd.unit(5), not in the
  specific options, so maybe it's not that easy to find.
  
  Actually, it kinda says it in the specific options. From the
  explanation of ExecStart=:
  
  ...If the empty string is assigned to this option, the list of
  commands to start is reset, prior assignments of this option will have
  no effect...
  
  Oh, I didn't see that while skimming the man page. Still, I think a
  tutorial manpage as I described (different ways to override distro
  configuration) would be a good idea. Would you accept a patch for
  something like that? If so, what should the man page be called?
 
 Sure, we can always use more man pages! Maybe simply call it
 systemd.turorial or so, which could then get sections explainaining
 how to best write new unit files, how to override/extend vendor unit
 files, and so on.
I think it might be better to stick it into systemd.unit. There's really
no reason not to, and this way it'll have more exposure. People are more
likely to miss a separate page.

I think it would be great to have an Examples section in systemd.{unit,
service,socket,path,...} giving a semi-realistic example of a unit that
can serve as a template. For systemd.socket there should be two: an
Accept=yes and Accept=no.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.

2015-01-23 Thread Robert Milasan
On Fri, 23 Jan 2015 14:31:28 +0100
Kay Sievers k...@vrfy.org wrote:
 
 How does udev_ctrl_get_stop_exec_queue() operate on a ctrl object and
 not a msg?
 
 How would udevadm process incoming control packets, or know that way
 about the state of the running daemon?
 
 If the event execution is disabled, there are pending events and
 settle should block.
 
 The entire idea of disabling the even handling is very questionable,
 what are you trying to do/fix here?
 
 Kay
 

Ahh, damn, I didn't even notice that. Sorry, ignore the patch, but at
least maybe --timeout option in man pages should be rewritten, its not
very clear if for example we stop the exec_queue.

-- 
Robert Milasan

L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] systemctl: bugfix for systemctl reboot command with argument

2015-01-23 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jan 23, 2015 at 08:21:57PM +0900, Sangjung Woo wrote:
 According to systemctl man page, 'systemctl reboot [arg]' should work
 without any errors. However, it does not work because of 'Invalid number
 of arguments' error, except for 'reboot [arg]'. This patch fixes the bug
 so that both of commands work in exactly the same way.
Applied.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Cristian Rodríguez

El 23/01/15 a las 10:31, Lennart Poettering escribió:


The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script anyway...



They are not init scripts though. but plain shell scripts with no 
dependency information. they are installed in /etc/init.d, therefore we 
end with units generated by both the sysv-generator and the rc-local 
generator.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Docker vs PrivateTmp

2015-01-23 Thread Daniel J Walsh

On 01/22/2015 10:02 PM, Lennart Poettering wrote:
 On Sat, 17.01.15 23:02, Lars Kellogg-Stedman (l...@redhat.com) wrote:

 See the `devicemapper` mountpoint created by Docker for the container:

 # grep devicemapper/mnt /proc/mounts
 
 /dev/mapper/docker-253:6-98310-e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
 
 /var/lib/docker/devicemapper/mnt/e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62
 ext4
 
 rw,context=system_u:object_r:svirt_sandbox_file_t:s0:c261,c1018,relatime,discard,stripe=16,data=ordered
 0 0
 I am not sure why docker makes these mounts visible in the host
 namespace at all. This smells like a bug.

 Watch Docker fail to destroy the container because it is unable to remove 
 the mountpoint directory:

 Jan 17 22:43:03 pk115wp-lkellogg docker-1.4.1-dev[18239]:
 time=2015-01-17T22:43:03-05:00 level=error msg=Handler for DELETE
 /containers/{name:.*} returned error: Cannot destroy container 
 e68df3f45d61:
 Driver devicemapper failed to remove root filesystem
 e68df3f45d6151259ce84a0e467a3117840084e99ef3bbc654b33f08d2d6dd62: Device 
 is
 Busy
 This smells as if Docker incorrectly sets the mount propagation bits
 on its own mounts.

 It would be good checking /proc/self/mountinfo inside and outside of
 docker's own namespace, and checking how the propagation bits are set
 for the individual mounts. It's a bit hard to read, but the
 interesting bits are in the 7th column of that file.

 In general: docker should do the equivalent of mount --make-rslave /
 as first thing after opening its mount namespace, so that from that
 point on mounts and especiall *un*mounts propagate from the host into
 the container, but not vice versa.

 If they do not invoke that, then the propagation will stay at
 shared, which means the mounts will appear in the host and vice
 versa, which is certainly undesired.

 Also, they should not use mount --make-rprivate /, as that means
 anything the host mounted will stay mounted in the container forever,
 which is a problem.

 Also, they really need to make this recursive, so that all mount
 points they have access too are detached from the host!

 Lennart


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Michael Biebl
2015-01-23 14:32 GMT+01:00 Lennart Poettering lenn...@poettering.net:
 On Fri, 23.01.15 04:24, Michael Biebl (mbi...@gmail.com) wrote:

 If distros still ship such a rc.local sysv init script, shouldn't they
 rather symlink that to
 the native rc-local.service? Sounds like the better alternative to me.
 Or alternatively, mask that service.

 E.g in Debian we have /etc/init.d/rc.local and ship a
 /lib/systemd/system/rc.local.service - rc-local.service
 symlink in the systemd package.

 I'd recommend not shipping the rc-local generator at all in Debian
 then. It was simply compat for some crappy logic where Fedora was
 executing two special scripts, that were not sysv during bootup and
 shutdown.

Hm, you're probably right.
I guess we could just statically enable rc-local.service in
multi-user.target.wants and drop rc-local-generator.

rc-local.service already has a
ConditionFileIsExecutable=/etc/rc.local, so it seems it would dtrt
already.

Martin, what do you think?

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] mount-setup: Do not bother with /proc/bus/usb

2015-01-23 Thread Cristian Rodríguez
Current systemd requires kernel = 3.7 per the README file
but CONFIG_USB_DEVICEFS disappeared from the kernel in
upstream commit fb28d58b72aa9215b26f1d5478462af394a4d253
(kernel 3.5-rc1)
---
 src/core/mount-setup.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 5919f77..521545e 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -120,8 +120,6 @@ static const MountPoint mount_table[] = {
 static const char ignore_paths[] =
 /* SELinux file systems */
 /sys/fs/selinux\0
-/* Legacy kernel file system */
-/proc/bus/usb\0
 /* Container bind mounts */
 /proc/sys\0
 /dev/console\0
-- 
2.2.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-01-23 Thread Ivan Shapovalov
On 2015-01-18 at 04:21 +0300, Ivan Shapovalov wrote:
 Hi folks,
 
 I'm trying to fix this bug:
 https://bugs.freedesktop.org/show_bug.cgi?id=88401
 
 The initial problem (as reported) looks following: performing a reload
 (maybe implicitly) re-starts alsa-restore.service if it is enabled.
 
 With a bit of debugging I've apparently found a root cause. Explanation
 following.
 
 Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
 started.
 
 We enter manager_reload(), units are serialized, reset, re-read,
 deserialized and then cold-plugged. (Note that e. g. unit_notify() has
 special protection to avoid spawning jobs when a reload is in
 progress.)
 
 So, if org.cups.cupsd.path is started, *it is almost first to be
 cold-plugged*. The call chain is:
 
 unit_coldplug()
 path_coldplug()
 path_enter_waiting() // recheck == true
 path_check_good() // returns true
 path_enter_running()
 manager_add_job() // at this point we're fucked up
 
 So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
 because a reload should never enqueue any jobs (IIUC). So, the job is
 enqueued... remember that almost all units are inactive by now. Thus we
 end up re-starting half a system (the whole basic.target) as
 dependencies.
 
 Questions:
 - is my analysis correct?
 - if yes, then how to fix this? Maybe add a similar
   if (UNIT(p)-manager-n_reloading = 0) check to
   path_enter_running() to avoid calling manager_add_job() during
   reloading?

Anyone?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container

2015-01-23 Thread Lennart Poettering
On Thu, 15.01.15 19:24, Stéphane Graber (stgra...@ubuntu.com) wrote:

 On Thu, Jan 15, 2015 at 07:20:55PM +0100, Lennart Poettering wrote:
 diff --git a/src/core/mount.c b/src/core/mount.c
 index 612d150..4de878e 100644
 --- a/src/core/mount.c
 +++ b/src/core/mount.c
 @@ -871,6 +871,14 @@ static void mount_enter_unmounting(Mount *m) {
  m-control_command_id = MOUNT_EXEC_UNMOUNT;
  m-control_command = m-exec_command + MOUNT_EXEC_UNMOUNT;
  
 +/* Ignore any mounts under /dev, /proc or /sys */
 +if (path_startswith(m-where, /dev/) ||
 +path_startswith(m-where, /proc/) ||
 +path_startswith(m-where, /sys/)) {
 +mount_set_state(m, MOUNT_DEAD);
 +return;
 +}
 +
  r = exec_command_set(m-control_command, /bin/umount, m-where, 
 NULL);
  if (r = 0  UNIT(m)-manager-running_as == SYSTEMD_SYSTEM)
  r = exec_command_append(m-control_command, -n, NULL);

Ah, nah, that patch wouldn't work, the state would be restored later
when we read from /proc/self/mountinfo again...

Anyway, I kinda missed that this is already an issue witht the
shutdown logic of the main unit engine. I assumed this was only about
the final unmount spree in systemd-shutdown.

I now made this change:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=874d3404cbf2363604106c8f86683db4082691ea

This does two things:

- Exempts all file systems below /dev, /proc, /sys from getting a
  Conflicts= dependency with umount.target. THis means during
  shutdown, where umount.target is pulled in these mount units will
  not be stopped.

- In the final umount loop in systemd-shutdown we simply won't bother
  anymore with these file systems too.

Hope this makes things work for you. Please test!

Thanks,

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] Swap gets activated twice (through fstab and gpt generators)

2015-01-23 Thread Peter Mattern
I saw this on an Arch Linux (systemd 218) i686 QEMU VM using BIOS and 
GPT, too. Couldn't see it on another x86_64 VM using UEFI (TianoCore / 
OVMF) and GPT but configured exactly the same apart from this.


Lenovo's Yoga 2 Pro used by the said bug report's OP is featuring a 
BIOS, too.



So perhaps the more robust fix would be to make the gpt generator not
generate swap units if fstab already configures any swap device? I. e.
auto-discovery and swaps in fstab are mutually exclusive then.
According to man 
(http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, 
see section Description) systemd-gpt-auto-generator is supposed to 
behave like this by now already.


So maybe a bug in systemd-gpt-auto-generator manifesting only in the 
context of BIOS + GPT?


Regards,

Peter Mattern

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Unwants

2015-01-23 Thread Dimitri John Ledkov
On 22 January 2015 at 16:32, Andrei Borzenkov arvidj...@gmail.com wrote:
 В Thu, 22 Jan 2015 15:46:26 +0100
 Michael Biebl mbi...@gmail.com пишет:

 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com:
  At the moment, I'm looking at packaging symlinks in .wants directories
  under /usr and then allow to uninstall such a package as a means to
  override the default config. Since I would like to update how the
  default config is setup, without doing in /etc where I'd have to
  answer is this my old config, or user modified it and I shouldn't
  touch it

 That's indeed a tough problem. The upstream recommendation is, to run
 systemctl preset during the initial installation.
 If there are changes to the default in the unit files, those changes
 are *not* applied on package upgrades.

 I don't think that's a particularly compelling solution.

 In Debian, we introduced a helper called i-s-h [1], which keeps some
 additional state and tries to apply such changes on updates.

 There was long discussion on this just recently.

 http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html


Thanks for this. The summary of that follows like so:

generic/typical systemd units ship, with a Install section WantedBy
multi-user.target an no other files.
It means it is inert / disabled by default.
Irrespective of the method (preset-all on empty/wiped /etc, preset at
first install only, enable (generated in packaging or run by an
admin),
the way to enable unit is by generating appropriate .wants/ symlinks in /etc.
It is viewed that distos should use presets whilst admins should use
enable, however the end result is the same on disk.
(E.g. distros can script things around enable/disable, and admins can
write /etc/systemd/system-preset and run preset from that file).
There are claims and assertions made as to what distro's should and
shouldn't do - which are distro's decisions.
It is not possible to encode distro's choices with the suggested or
possible semantics, neither with presets nor shipping symlinks in
/usr.
Then end-result is that current semantics have a bias towards disable
* default policy.
(Unit by itself is not enabled, default policy not enable, if user or
preset enables, it is stored in admin dir /etc, rather than state
dirs under /var)

The worst consequence of this, imho, is that .wants symlinks are
honoured from lower level directories even if the unit is out right
superseeded in a higher level directory.
E.g. cp /usr/lib/systemd/system/foo*.target /etc/systemd/system;
the /usr/lib/systemd/system/foo1.target.wants/foo2.target -
../foo1.target is honoured.

Nor is there a way to move a wants to a later target in the boot process.
(e.g. most systemd intuitive way to add symlink to /dev/null  have
systectl commands that mirror add-wants/add-requires)

Furthermore, it appears that /etc is used as a snapshot of the preset
state as it was at the last time preset-all was run essentially. On my
books software state should live under /var rather under /etc. And in
the current generation philosophy this breaks the assumption that
/etc is user modified overrides only. But I think we can do better
than /var.

Do we really need symlinks on disk from presets?

Here is a proposal:

extend .wants/*; .requires/* semantics to allow removal:
e.g. if the target of the symlink in .wants/ directory points at
/dev/null, instead of adding a dependency, such dependency is removed
if it no longer exists
e.g. Wants/Requires define dependencies to be added, or negating a
dependency if such already exists if prefixed with ! 
e.g. add commands rm-wants / rm-requires - which either create
symlink to /dev/null in /etc/***.wants/ for dependencies created in
lower-level configuration directories or removes existing symlink from
/etc/***.wants/

remove preset-* commands, or support mode of operation where preset
commands are no-op.
instead load and apply (on boot, daemon-reload, daemon-reexec) preset
directives in memory without storing a snapshot of preset results as
symlinks in /etc.
(this would make systemd stateless and be operational with less
symlinks on an even a read-only /etc without even a tmpfs rw mounted
/etc)

This makes the policies of enable * and disable * to be in full equilibrium:
- default policy applied from /usr
- user override is .wants/* symlinks based on Install section
-- to /dev/null to disable under enable * policy
-- to a valid unit to be enabled under disable * policy
-- no change in system under /usr (intentional or accidental) would
loose user choice

This would lead to one-time upgrade loss of state for disable *
distributions (i.e. the small number of distro enabled by default
units, which were disabled by the users, would get re-enabled. As a
one time upgrade, this can be detected and acted upon appropriately).
However this one time upgrade / miss-balance exaggerates the
complexity inflicted upon enable * distributions where this problem
is not for small number of 

Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Michael Biebl
2015-01-23 10:17 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
 Michael Biebl wrote on 23/01/15 03:24:
 and ship a
 /lib/systemd/system/rc.local.service - rc-local.service
 symlink in the systemd package.

 Hmm, doesn't that break the
 /usr/lib/systemd/system-generators/systemd-rc-local-generator logic? Or
 do you not ship that in Debian?

 The whole point of this generator is to look for /etc/init.d/rc.local
 and check that it's executable and then add it in with appropriate deps
 so it runs at the correct time (i.e. quite late)

 Maybe I'm missing something that the above trick would achieve?

This trick achieves two things:
- It avoids that a rc.local.service file is generated by the sysv-generator
- It avoids that the rc.local.service is started (as a LSB service),
since we want this to be done by the native service.

afaics, /lib/systemd/system/rc-local.service always exists, the
rc-local generator only does the symlink into the
multi-user.target.wants directory.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Michael Biebl
2015-01-23 8:29 GMT+01:00 Mantas Mikulėnas graw...@gmail.com:
 IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if
 that's still a problem, maybe there could be one tmpfs at /run/user, still
 preventing users from touching root-only /run?

FWIW, as long as logind didn't setup per-user tmpfs, we used such a
/run/user tmpfs in Debian to avoid users accidentally DoSing the
system by filling up /run.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness

2015-01-23 Thread Lennart Poettering
On Fri, 23.01.15 09:29, Mantas Mikulėnas (graw...@gmail.com) wrote:

 On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering lenn...@poettering.net
 wrote:
 
  On Thu, 22.01.15 15:53, Christian Seiler (christ...@iwakd.de) wrote:
 
   Nevertheless, I think it would be great if this could also be fixed,
   because you never know what other applications people might come up
   with.
  
   The solution would probably be to just add a code path to chown
   the directory instead of mounting a tmpfs on top of it. That doesn't
   separate users from root inside the container quite as much, but in
   containers without CAP_SYS_ADMIN, I think that's a trade-off that's
   worth making.
  
   What do you think?
 
  Yeah, I agree. If we cannot mount the tmpfs due to EPERM we should add
  a fallback to use a simple directory instead. Would be happy to take a
  patch for that.
 
 
 IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if
 that's still a problem, maybe there could be one tmpfs at /run/user, still
 preventing users from touching root-only /run?

Well, we logind cannot mount that either. If so, the container manager
would have to mount that, which it can, logind should be happy with
it.

In general though I think our code paths should be do it fully and
skip it if we lack the perms. I am not a fan of adding a multitude
of additional code paths along the lines of try something different
if we lack the perms...

Hence, let's keep this simple: either we mount per-user tmpfs, or we
don't, but let's not invent complex fallback strategies...

I mean, I am not sure I am convinced that CAP_SYS_ADMIN-less
contianers really make that much sense anyway, and I think people
should be OK with them not providing the same guarantees as the ones
that have it...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.

2015-01-23 Thread Robert Milasan
How to reproduce:

run: udevadm control --stop-exec-queue
add: new device, for example a usb stick/disk 
 (it will create /run/udev/queue)
run: udevadm settle --timeout=10

The last command will hang/stall, because it checks constantly
for /run/udev/queue, which exists and always will unless the user
doesn't start the event execution or deletes manually /run/udev/queue.

Signed-off-by: Robert Milasan rmila...@suse.com
---
 src/udev/udevadm-settle.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 6bcb3a9..80529ce 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -116,6 +116,11 @@ static int adm_settle(struct udev *udev, int argc,
char *argv[]) { udev_ctrl_unref(uctrl);
 return EXIT_SUCCESS;
 }
+if (udev_ctrl_get_stop_exec_queue(uctrl)  0) {
+log_debug(event execution disabled);
+udev_ctrl_unref(uctrl);
+return EXIT_SUCCESS;
+}
 udev_ctrl_unref(uctrl);
 }
 }
-- 
1.8.4.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel