[systemd-devel] [PATCH] sd_daemon: use secure_getenv() instead of getenv()
According to the glibc manual, secure_getenv() is more trustful than
getenv() since it returns a null pointer if the environment is untrusted
such as setting SUID or SGID bits. Moreover, libraries should use
secure_getenv().
(http://www.gnu.org/software/libc/manual/html_node/Environment-Access.html)
Signed-off-by: Sangjung Woo
---
src/libsystemd/sd-daemon/sd-daemon.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-daemon/sd-daemon.c
b/src/libsystemd/sd-daemon/sd-daemon.c
index 028c2a7..86e6aed 100644
--- a/src/libsystemd/sd-daemon/sd-daemon.c
+++ b/src/libsystemd/sd-daemon/sd-daemon.c
@@ -46,7 +46,7 @@ _public_ int sd_listen_fds(int unset_environment) {
int r, fd;
pid_t pid;
-e = getenv("LISTEN_PID");
+e = secure_getenv("LISTEN_PID");
if (!e) {
r = 0;
goto finish;
@@ -62,7 +62,7 @@ _public_ int sd_listen_fds(int unset_environment) {
goto finish;
}
-e = getenv("LISTEN_FDS");
+e = secure_getenv("LISTEN_FDS");
if (!e) {
r = 0;
goto finish;
@@ -374,7 +374,7 @@ _public_ int sd_pid_notify_with_fds(pid_t pid, int
unset_environment, const char
goto finish;
}
-e = getenv("NOTIFY_SOCKET");
+e = secure_getenv("NOTIFY_SOCKET");
if (!e)
return 0;
@@ -525,7 +525,7 @@ _public_ int sd_watchdog_enabled(int unset_environment,
uint64_t *usec) {
uint64_t u;
int r = 0;
-s = getenv("WATCHDOG_USEC");
+s = secure_getenv("WATCHDOG_USEC");
if (!s)
goto finish;
@@ -537,7 +537,7 @@ _public_ int sd_watchdog_enabled(int unset_environment,
uint64_t *usec) {
goto finish;
}
-p = getenv("WATCHDOG_PID");
+p = secure_getenv("WATCHDOG_PID");
if (p) {
pid_t pid;
--
1.7.9.5
___
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
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
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 18:51 GMT+01:00 Lennart Poettering : > 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] Docker vs PrivateTmp
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
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
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] logind vs CAP_SYS_ADMIN-lessness
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
Re: [systemd-devel] [PATCH] build-sys: lookup for sulogin, it might not be in /sbin
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 2>&1], [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] [PATCH] mount-setup: Do not bother with /proc/bus/usb
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
[systemd-devel] [PATCH] po: update Russian translation
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] libudev: fix check for too long packet
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] logind vs CAP_SYS_ADMIN-lessness
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] [PATCH] Added UFD (Uplink failure detection) support to networkd
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
Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator
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] sysv-generator: Do not generate units for files handled by rc-local generator
On Fri, 23.01.15 15:57, Michael Biebl (mbi...@gmail.com) wrote: > 2015-01-23 14:32 GMT+01:00 Lennart Poettering : > > 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
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] [PATCH] libudev: fix check for too long packet
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
[systemd-devel] [PATCH] build-sys: lookup for sulogin, it might not be in /sbin
--- 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 2>&1], [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
[systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
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
[systemd-devel] [PATCH] 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 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 @@ ipip, gre, gretap, sit, vti, veth, -tun, tap and -dummy +tun, tap, +ufd and dummy are supported. This option is compulsory. @@ -553,6 +553,52 @@ +[UFDGroup] Section Options + +The [UFDGroup] section is used to define uplink failure detection group parameters. +The section only applies for netdevs of kind ufd, and accepts the following key: + + + + +Id= + +Uplink failure detection group Id. This option is compulsory. + + + + + + +[UFDLink] Section Options + +The [UFDLink] section is used to define one or more uplink failure detection links. +The section only applies for netdevs of kind ufd, and accepts the following key: + + + + +Name= + +An interface name or an enumeration of interface names separated by comma. +This option is compulsory. + + + + +Type= + +A string defining the link(s) type. +It can only take the following string values: uplink +or downlink. This option is compulsory. + + + + + + + + Example /etc/systemd/network/bridge.netdev @@ -645,6 +691,28 @@ Name=veth-peer +/etc/systemd/network/ufd.netdev +
Re: [systemd-devel] [PATCH] libudev: fix check for too long packet
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] Docker vs PrivateTmp
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
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
Re: [systemd-devel] Docker vs PrivateTmp
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
[systemd-devel] [PATCH] mount-setup: Do not bother with /proc/bus/usb
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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator
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] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware
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] sysv-generator: Do not generate units for files handled by rc-local generator
2015-01-23 15:15 GMT+01:00 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. Oh right, completely forgot about that. Thanks for clarifying, Martin. +1 for upstreaming that patch. 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] sysv-generator: Do not generate units for files handled by rc-local generator
2015-01-23 14:32 GMT+01:00 Lennart Poettering : > 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
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
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] [logind] retroactive lid close handle upon vt switch
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] [PATCH] systemctl: bugfix for systemctl reboot command with argument
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] service.d/.conf files and multi-valued options
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] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.
On Fri, 23 Jan 2015 14:31:28 +0100 "Kay Sievers" 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
[systemd-devel] [PATCH 2/2] logind: chown+chmod /run/user/$UID if mount(tmpfs) fails with EPERM
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
[systemd-devel] [PATCH 1/2] logind: remove per-user runtime dir again if setup fails
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
Re: [systemd-devel] service.d/.conf files and multi-valued options
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] sysv-generator: Do not generate units for files handled by rc-local generator
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
Re: [systemd-devel] service.d/.conf files and multi-valued options
On 23 January 2015 at 11:21, Matthias Urlichs 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
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] service.d/.conf files and multi-valued options
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
Re: [systemd-devel] [logind] retroactive lid close handle upon vt switch
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] persisting sriov_numvfs
- Original Message -
> From: "Lennart Poettering"
> To: "Dan Kenigsberg"
> 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] Unwants
On 23 January 2015 at 13:11, Dimitri John Ledkov wrote: > On 22 January 2015 at 16:32, Andrei Borzenkov wrote: >> В Thu, 22 Jan 2015 15:46:26 +0100 >> Michael Biebl пишет: >> >> 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: of november threads . ...reading december archive now as well which has concrete descriptions of behaviour which are considered "sound enough to implement" -- 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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator
On Fri, 23.01.15 04:24, Michael Biebl (mbi...@gmail.com) wrote:
> 2015-01-23 3:52 GMT+01:00 Cristian Rodríguez :
> > ---
> > 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] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.
On Fri, Jan 23, 2015 at 2:13 PM, Robert Milasan 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
> ---
> 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
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] service.d/.conf files and multi-valued options
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] systemd-sysv-generator *.service: File exists
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=f21&id=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
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
[systemd-devel] [PATCH] udevadm-settle: exit if event execution is disable, even if queue is not empty.
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
---
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
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
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 > 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
Re: [systemd-devel] Unwants
On 22 January 2015 at 16:32, Andrei Borzenkov wrote: > В Thu, 22 Jan 2015 15:46:26 +0100 > Michael Biebl пишет: > >> 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov : >> > 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
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
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] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container
On Fri, 16.01.15 19:32, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> В Thu, 15 Jan 2015 19:24:25 -0500
> Stéphane Graber пишет:
>
> > @@ -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] [PATCH] Fix systemd crash (on assert) during shutdown/reboot in unprivileged container
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] logind vs CAP_SYS_ADMIN-lessness
2015-01-23 8:29 GMT+01:00 Mantas Mikulėnas : > 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] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator
2015-01-23 10:17 GMT+01:00 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? 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
[systemd-devel] [PATCH] systemctl: bugfix for systemctl reboot command with argument
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.
Signed-off-by: Sangjung Woo
---
src/systemctl/systemctl.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index cdc1a50..0764907 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2955,6 +2955,12 @@ static int start_special(sd_bus *bus, char **args) {
return -EPERM;
}
+if (a == ACTION_REBOOT) {
+r = update_reboot_param_file(args[1]);
+if (r < 0)
+return r;
+}
+
if (arg_force >= 2 &&
(a == ACTION_HALT ||
a == ACTION_POWEROFF ||
@@ -7071,7 +7077,7 @@ static int systemctl_main(sd_bus *bus, int argc, char
*argv[], int bus_error) {
{ "import-environment",MORE, 1, import_environment},
{ "halt", EQUAL, 1, start_special,FORCE },
{ "poweroff", EQUAL, 1, start_special,FORCE },
-{ "reboot",EQUAL, 1, start_special,FORCE },
+{ "reboot",MORE, 1, start_special,FORCE },
{ "kexec", EQUAL, 1, start_special },
{ "suspend", EQUAL, 1, start_special },
{ "hibernate", EQUAL, 1, start_special },
--
1.7.9.5
___
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
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? -- -- Matthias Urlichs ___ 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
Hi On Thu, Jan 22, 2015 at 3:53 PM, Christian Seiler 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
Re: [systemd-devel] systemd-sysv-generator *.service: File exists
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=f21&id=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] systemd-sysv-generator *.service: File exists
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
[systemd-devel] service.d/.conf files and multi-valued options
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
[systemd-devel] Swap gets activated twice (through fstab and gpt generators)
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
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
