Re: [systemd-devel] systemd-notify
On Thu, 18 Apr 2019 14:21:09 +0200, Josef Moellers wrote: > Hi, > > We're currently working on a bug which afaict is due to a race > condition: > > 1) systemd starts xenstored.service > 2) /etc/xen/scripts/launch-xenstore does its work (starts /usr/lib/xen/ > bin/init-xenstore-domain) > 3) /etc/xen/scripts/launch-xenstore runs "systemd-notify --ready" > 4) "systemd-notify --ready" sends a UDP-message to systemd 5) > /etc/xen/scripts/launch-xenstore exits 6) systemd gets SIGCHLD and > removes the PID from watch_pids[12] > 7) systemd receives the UDP message, but >a) the process is gone b) the PID is not in watch_pids[12] any more. > 8) "Cannot find unit for notify message of PID..." > 9) No start of depending units. > > I see no proper way to get out of this but to make the systemd-notify > synchronous rather than fire-and-forget and expect it to wait for a > response from systemd. If the launch-xenstore script starts a daemon and then exists: why not make the unit Type=forking and thus forget about systemd-notify --ready ? -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/default.target.wants/no longer checked for unit files
On Fri, 14 Jul 2017 12:28:20 +0200, Michael Biebl wrote: > 2017-07-14 12:24 GMT+02:00 Mantas Mikulėnas <graw...@gmail.com>: >> On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones >> <rjo...@redhat.com> wrote: >>> >>> >>> https://github.com/systemd/systemd/issues/6334 >>> >>> Since this commit >>> >>> https://github.com/systemd/systemd/ commit/2d058a87ffb2d31a50422a8aebd119bbb4427244 >>> (in v233 and v234), you can no longer create >>> /etc/systemd/system/default.target.wants/ and drop in service files >>> (or symlinks). The directory is skipped. I have reverted the commit >>> on top of systemd from git and that makes defaults.target.wants work >>> again. >>> >>> Is this supposed to work? It worked fine since at least Fedora 18-25, >>> but it is now broken in Fedora 26. >>> >>> If it was never supposed to work, how are you supposed to enable a >>> service for the default target, even allowing for the user to change >>> the default target and still have the service enabled? >> >> >> The current convention is to install all regular services into >> multi-user.target, and I would expect all custom "daily use" targets to >> be superset of multi-user.target as well, like the provided >> graphical.target already is. > > Seems like default.target is used by quite a few services though: > https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target > > If default.target is not supposed to be used, then this should be > mentioned somewhere. The user manager has a real default.target. Many (most?) of the units listed above are user services. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
On Tue, 04 Jul 2017 18:39:15 +, Zbigniew Jędrzejewski-Szmek wrote: > Essentially, User=0day is the same as Usre=0day and the same as User="my > name is pretty!". I think this is the root of the disagreement. Systemd tries to allow units written for version X to run on versions earlier than X. I think that is a good idea, and I don't think anyone is claiming it isn't. Which is why invalid lvalues should be warned about but ignored, and I don't think anyone is disputing this. OTOH, invalid rvalues are a different thing: systemd recognizes the setting it is trying to apply, but it can't. I think the argument that systemd should fail the unit here is strong. Or at least for a certain subset of the settings. > > I do agree that we might want to completely reject unit files when some > crucial lines fail to parse, for example ExecStart or WorkingDirectory > or User, but it's not as obvious as one would think at first. Indeed. Marking invalid rvalues as failing the unit does bring backwards- compatibility issues. Suppose systemd X+1 adds a new @ shortcut for SystemCallFilter: should systemd X fail a unit that uses it? The problem would be the same as with User=0day, as the service would run with higher privileges than expected. A possibility would be to make systemd have its preemptive validations[1] be fatal. Setting `User=idontexist` would then be equal to `User=whoa!`, because neither of the usernames (should) exist. [1] That is, validations for things it does not control itself. systemd does not control the username format, the uid range, allowed directories, etc, but rather validates against an external standard. That is, assume that things that don't validate would fail at application time with a non- ignorable EINVAL. This is different from things it defines itself, such as @ settings for SystemCallFilter. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should automount units for network filesystems be Before=local-fs.target?
On Thu, Apr 27, 2017 at 9:50 PM, Michael Chapman <m...@very.puzzling.org> wrote: > On Fri, 28 Apr 2017, Felipe Sateler wrote: > >> On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote: >> >> Hello all, >>> >>> At present, when systemd-fstab-generator creates an automount unit for >>> an fstab entry, it applies the dependencies that would have been put >>> into the mount unit into the automount unit instead. >>> >>> For a local filesystem, this automount unit would be >>> Before=local-fs.target. For a network filesystem, it gets >>> Before=remote-fs.target. If the mount is not noauto, it also gets a >>> corresponding WantedBy= or RequiredBy= dependency. >>> >>> Would it make more sense for the automount unit to be ordered before >>> (and, >>> if not noauto, be pulled in by) local-fs.target, even for network >>> filesystems? >>> >>> In a sense, the automount is a local filesystem, even though the thing >>> that will eventually be mounted over the top of it isn't. Furthermore, >>> this change would allow services that use automounted network filesystem >>> to simply block until the filesystem has been mounted. Currently, for >>> this to work correctly during boot, services need to be given explicit >>> dependencies (e.g. After=remote-fs.target or RequiresMountsFor=...), >>> since otherwise they may get started before the automount unit has >>> started and thus be able to "see" the underlying filesystem. >>> >>> I'm trying to work out what might break with such a change. I suppose it >>> is possible somebody has two automounted network filesystems nested >>> within one another... the second automount would be dependent upon the >>> first being mounted, but that mount won't happen until the network is >>> brought up, which is after local-fs.target. This doesn't seem like a >>> particularly likely configuration though. >>> >>> Is there any other reason this change wouldn't work? >>> >> >> >> I think the most likely failure point would be at shutdown: >> >> 1. foo.mount is unmounted, but foo.automount is still alive. >> 2. some.service is not Requires/After foo.mount >> 3. some.service tries to access /foo >> 4. systemd tries to activate foo.mount >> 5. boom >> > > Well, the shutdown target is started irrevocably, so I suspect instead of > "boom" the service will just block until it's stopped by systemd. Well, I didn't test it, so "boom" was meant as "bad things happening" :) > > But yeah, you do raise a good issue. > > This is all a bit annoying. I've got a bunch of services (across multiple > servers), but I don't necessarily know up front which services will be > requiring access to network filesystems. I would prefer not to have to > configure them all with After=remote-fs.target "just in case". I was hoping > that by using automounts this wouldn't be necessary, but the services can > end up being started _before_ those automounts. > In a sense, this is a bit of a regression from sysv initscripts, because a > lot of initscripts were shipped with "Required-Start: $remotefs" just as a > precautionary measure, but most vendor-provided systemd units do _not_ have > After=remote-fs.target. > So is there any other way I could achieve what I want, or am I forced to > drop in After=remote-fs.target wherever it might possibly be necessary? > It is my impression that the best course is to have your services have RequiresMountsFor= the places they use. This way you ensure: 1. If mounts fail your service does not attempt to start. 2. Your service is stopped if the mount goes down. 3. Your service is started and stopped at the right time on boot/shutdown. It's a bit more annoying, yes, but more precise. Failing that, you can add After=remote-fs.target to all your services. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should automount units for network filesystems be Before=local-fs.target?
On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote: > Hello all, > > At present, when systemd-fstab-generator creates an automount unit for > an fstab entry, it applies the dependencies that would have been put > into the mount unit into the automount unit instead. > > For a local filesystem, this automount unit would be > Before=local-fs.target. For a network filesystem, it gets > Before=remote-fs.target. If the mount is not noauto, it also gets a > corresponding WantedBy= or RequiredBy= dependency. > > Would it make more sense for the automount unit to be ordered before > (and, > if not noauto, be pulled in by) local-fs.target, even for network > filesystems? > > In a sense, the automount is a local filesystem, even though the thing > that will eventually be mounted over the top of it isn't. Furthermore, > this change would allow services that use automounted network filesystem > to simply block until the filesystem has been mounted. Currently, for > this to work correctly during boot, services need to be given explicit > dependencies (e.g. After=remote-fs.target or RequiresMountsFor=...), > since otherwise they may get started before the automount unit has > started and thus be able to "see" the underlying filesystem. > > I'm trying to work out what might break with such a change. I suppose it > is possible somebody has two automounted network filesystems nested > within one another... the second automount would be dependent upon the > first being mounted, but that mount won't happen until the network is > brought up, which is after local-fs.target. This doesn't seem like a > particularly likely configuration though. > > Is there any other reason this change wouldn't work? I think the most likely failure point would be at shutdown: 1. foo.mount is unmounted, but foo.automount is still alive. 2. some.service is not Requires/After foo.mount 3. some.service tries to access /foo 4. systemd tries to activate foo.mount 5. boom Since the whole point of the exercise was to have some.service start earlier, and this implies that some.service will be stopped later, I deem this scenario likely if what you propose were implemented. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
On 27 April 2016 at 10:41, Daniel Mack <dan...@zonque.org> wrote: > On 04/27/2016 12:29 AM, Felipe Sateler wrote: >> On Tue, 26 Apr 2016 17:28:34 +0200, Daniel Mack wrote: >> >>> Hi Michael, >>> >>> On 04/15/2016 11:00 PM, Daniel Mack wrote: >>>> On 04/15/2016 10:47 PM, Michael Biebl wrote: >>> >>>> Including the built results of systemd-initctl into your .deb packet is >>>> not a solution? Making that an extra package causes too much trouble, I >>>> totally agree. >>> >>> Did you further think about this idea, would that be a solution? >> >> I'm not sure I understood your proposal correctly, but each .deb package >> is built from one source package. This implies that systemd-initctl >> source would have to be somehow imported into the debian systemd source, > > Well, yes. At the same time when downstream patches are applied. Ah, yes, I was confused by your mention of built-results. > >> and then used to build the shipped binary (ie, not importing the binary >> artifacts alone). > > I'm not sure if it's feasible, hence I'm asking. It should be doable via either a patch reverting the removal, or a plain import of the new systemd-initctl sources into the debian.tar.xz and built in a separate ./configure && make run. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
On Tue, 26 Apr 2016 17:28:34 +0200, Daniel Mack wrote: > Hi Michael, > > On 04/15/2016 11:00 PM, Daniel Mack wrote: >> On 04/15/2016 10:47 PM, Michael Biebl wrote: > >> Including the built results of systemd-initctl into your .deb packet is >> not a solution? Making that an extra package causes too much trouble, I >> totally agree. > > Did you further think about this idea, would that be a solution? I'm not sure I understood your proposal correctly, but each .deb package is built from one source package. This implies that systemd-initctl source would have to be somehow imported into the debian systemd source, and then used to build the shipped binary (ie, not importing the binary artifacts alone). -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Pulseaudio & systemd-nspawn
On Mon, 02 Nov 2015 11:29:56 +0800, Kai Hendry wrote: > Hi there, > > I'm trying to have a super simple way of launching a browser in a VPN. > > I am on Archlinux with systemd 227-1 with pulseaudio 7.1-1 & I have > another Arch container configured like so: Do you have the pulseaudio server installed in the container? I think you shouldn't, so that the client inside the container connects to the server in the host. Otherwise, what you need it to make the pulseaudio server in the container talk to the server in the host, and for that you should not bind /dev/snd nor /run/user/1000/pulse > > X1C3:~$ cat > /etc/systemd/system/systemd-nspawn@firefox.service.d/override.conf > [Service] > ExecStart= > ExecStart=/usr/bin/systemd-nspawn > --bind-ro=/home/hendry/.Xauthority:/root/.Xauthority \ > --bind=/tmp/.X11-unix \ > --bind=/dev/snd \ I don't think this is appropriate. There should be no sound card on the container. > --bind=/run/user/1000/pulse:/run/user/1000/pulse Won't this get hidden by the tmpfs in /run/user ? Maybe the better option is to load the tcp pulseaudio module, allow connections from the container ip, and inject PULSE_SERVER envvar into the container. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] nspawn/networkd: moving from iptables to nftables
On Fri, 29 May 2015 17:49:12 +0200, Lennart Poettering wrote: > Yes, we are aware this is unfortunate, and that many people are still > using iptables. For this reason we would like to make the switch quickly > to ensure not too many users start using the iptables hook-up before it > goes away. Is there any update on the switch to nftables? v227 still uses iptables... -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. 2) nfs-common makes itself pulled in by network-online.target, and orders itself before that. This way, the service is started when the network is upped. Why isn't WantedBy=remote-fs.target an option? This would make any auto remote mount pull nfs-common, but if none is then it won't be started (unless that part of local-fs doesn't apply to remote-fs). Remote mount units do not pull that in. you can use it to mount all remote mounts, but the remote mounts will not pull it in, the dependency is only one way. Oh I misread the manpage. Thanks for clarifying. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab generator and nfs-client.target
On 27 July 2015 at 15:58, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote: On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote: On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote: On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote: Coming back to your original question, there are two options: 1) nfs-common becomes a normal multi-user.target service, but adds Before=remote-fs-pre.target. This way, the service is started at boot, and not only on first use. This would have the side effect of nfs-common not being started in single user mode, which is not likely to be the wanted outcome. Well, then set DEfaultDEpendencies=no and pull it in by sysinit.target. But that's only OK if the service is capable of running in early-boot mode (i.e does not try to access /var and stuff). Or basic.target? The description of basic.target says: Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic initialization necessary for general purpose daemons. Something that provides services for mountpoints could be hooked up here, no? The description of sysinit.target doesn't really tell me what this target is all about, or how to choose between it and basic.target. Yeah, it's not obvious. Basically, sysinit.target is where all the small early-boot mini-services are pulled in. basic.target otoh pulls in the various other targets then, without pulling in any .mount, .service, .socket, ... units on its own. Except for RequiresMountsFor=/var /tmp /var/tmp specified in basic.target. Or in other words: we group all early-boot services in sysinit.target, we group all mounts in local-fs.target, all swaps in swaps.target, all sockets in sockets.target, and so on, and then group all the aforementioned targets as basic.target. Makes sense? Yes, makes sense. I will try to come up with a patch to the documentation to clarify this. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd 215 cannot start journald 219 inside systemd-nspawn
On 15 May 2015 at 07:31, Lennart Poettering lenn...@poettering.net wrote: On Sun, 10.05.15 11:20, Felipe Sateler (fsate...@debian.org) wrote: Hi, I'm having a problem with a systemd-nspawn'ed container. The guest journal will not start and thus I have no logs. The host is a 215 Debian Jessie system. The guest is a 219 Debian Sid system. The nspawn unit is at http://paste.debian.net/173849/ The host journal log for the systemd process is at http://paste.debian.net/173848/ Trying to run systemd-journald manually yields the following error: Failed to join audit multicast group: Operation not permitted Hmm, what kernel version is this? % uname -a Linux mercury 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux Note that auditing is generally broken with containers. Due to that, we ask users to either disable it completely on the kernel command line via audit=0. (see README for details) Optionally, on x86-64 (but nox i386) we try to work around this by making audit netlink sockets unavailable in containers via seccomp. Indeed, on the host: % systemd --version systemd 215 +PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR The debian 219 version still has it disabled: % systemd --version systemd 219 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN It looks like this should be enabled where supported (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760299) You appear to be using a systemd version without seccomp compiled in, hence you won't get the container behaviour described, and you need to disable audit in the kernel instead. So, to make sure I understood correctly: does this have anything to do with 215/219 interop or is just that 219 wants to use audit and it is broken? I gather it is the latter but confirmation would be nice. In other words, would running 219 in the host fix anything, or should we expect all Debian 219 containers to fail? -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd 215 cannot start journald 219 inside systemd-nspawn
On 15 May 2015 at 10:15, Lennart Poettering lenn...@poettering.net wrote: On Fri, 15.05.15 10:10, Felipe Sateler (fsate...@debian.org) wrote: You appear to be using a systemd version without seccomp compiled in, hence you won't get the container behaviour described, and you need to disable audit in the kernel instead. So, to make sure I understood correctly: does this have anything to do with 215/219 interop or is just that 219 wants to use audit and it is broken? I gather it is the latter but confirmation would be nice. In other words, would running 219 in the host fix anything, or should we expect all Debian 219 containers to fail? Yeah, 219 uses the audit mcast stuff, which it previously didn't use. But generally audit is borked in containers, you have to turn it off anyway to use containers properly. Or you run x86-64 and compile with libseccomp... Thanks for confirming. -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd 215 cannot start journald 219 inside systemd-nspawn
Hi, I'm having a problem with a systemd-nspawn'ed container. The guest journal will not start and thus I have no logs. The host is a 215 Debian Jessie system. The guest is a 219 Debian Sid system. The nspawn unit is at http://paste.debian.net/173849/ The host journal log for the systemd process is at http://paste.debian.net/173848/ Trying to run systemd-journald manually yields the following error: Failed to join audit multicast group: Operation not permitted Downgrading the guest systemd to 215 enables journald to start normally. Is this expected? Or more importantly, can this problem be worked around without upgrading the host or downgrading the guest? -- Saludos, Felipe Sateler ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
