Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd
On 6/30/20 4:18 AM, Lennart Poettering wrote: Maybe it double forks or forks a child off (callout script?) that double forks somewhere? I don't know your software, it's probably best to ping the authors of it about this, they should know what their software does. LOL! I am the author. So I think I've figured out why I was getting the SELinux message. The proximate cause was that I hadn't yet discovered the proper SELinux policy macro to use when creating the type for the helper application, so I was building the policy for the helper "from scratch" with low- level rules. Now that the policy uses the domain_type() macro, I no longer get the message. As to what was causing the helper to send SIGCHLD to systemd ... I'm not 100% sure that it ever tried to do so. I have a feeling, however, that it has something to do with systemd's GuessMainPID feature. I saw a couple seemingly random denials (possibly when I had dontaudit rules disabled) about systemd trying to access the helper application's /proc directory (which didn't work, because I hadn't used the proper macro). I don't presume to know the details of how the feature works, but it makes sense that it might occasionally incorrectly guess that the helper application is the daemon's main process (particularly when the daemon first starts, which is when I reliably saw multiple denials). If systemd somehow reparents the child process in that circumstance, it might explain why the SIGCHLD would be sent to systemd, rather than its parent daemon. Looks like fixing this program to work properly with Type=simple just moved up my to-do list. -- In Soviet Russia, Google searches you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
Am 30.06.20 um 14:55 schrieb Simon McVittie: > Adding After=network-pre.target to dhcpcd.service is probably also not > a bad idea. It isn't clear to me whether dhcpcd brings up interfaces of > its own accord just because you start it as a systemd unit it just fails when like in the example below the interface "br-guest" isn't already there, and hence it's not that simple to say when a dhcp service should be started i just made it all easier by throw away all the NetworkManager, systemd-networkd or whatever stuff and wrote a oneshot-unit with a ton of ExecStart configuring all my interfaces, bridges and hostapd-instances [root@srv-rhsoft:~]$ cat /etc/systemd/system/dhcpd-guest.service [Unit] Description=DHCPD Guest-WLAN After=network-up.service Requires=network-online.target network-up.service [Service] Type=notify ExecStart=/usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd-guest.conf -lf /var/lib/dhcpd/dhcpd-guest.leases -user dhcpd -group dhcpd --no-pid br-guest Restart=always ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 12:59:54 +0100, Mark Rogers wrote: > On Tue, 30 Jun 2020 at 12:13, Simon McVittie wrote: > > > > I would have expected this to be done in some "larger" network management > > component that is responsible for bringing up network interfaces according > > to your configuration, rather than necessarily dhcpcd.service itself. > > In which case one would expect dhcpcd to depend on that instead I meant the other way around, actually: a larger network management component like ifupdown (which has policy, not just mechanism) tells dhcpcd to start managing an interface, and that larger component conceptually depends on dhcpcd. (It might not be an explicit dependency because of automatic activation.) Adding After=network-pre.target to dhcpcd.service is probably also not a bad idea. It isn't clear to me whether dhcpcd brings up interfaces of its own accord just because you start it as a systemd unit, or whether it brings up interfaces only when specifically requested by something like ifupdown or NetworkManager, or some mixture. If it can be configured to bring up interfaces on its own, independent of things like ifupdown, then it is taking on at least part of the role of a network management component itself, in which case it does need After=network-pre.target. > > Typically server-class systems will use either ifupdown or > > systemd-networkd, which are ideal for relatively static network > > configurations that are set up by a sysadmin. > > It's definitely not systemd-networkd, to my untrained eye it looks > like ifupdown is there but how do I confirm? Your unit in https://lists.freedesktop.org/archives/systemd-devel/2020-June/044784.html (which I missed when replying earlier) refers to networking.service, which is part of ifupdown. Depending on precisely what configuration you're writing out from your database in your use-case-specific unit, you might be configuring ifupdown to do things (in which case ifupdown's After=network-pre.target should be enough), or you might be configuring dhcpcd to go behind ifupdown's back to do things (in which case your use-case-specific unit needs to happen before dhcpcd), or something else entirely. You'll need to look at and understand the overall system you have set up. You mentioned wanting to make your unit network-stack-agnostic, but adding an extra layer of abstraction cannot solve all problems, and in particular it cannot solve the problem "too many layers of abstraction". At some point someone or something has to make a decision and actually do something concrete :-) smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 12:13, Simon McVittie wrote: > > I would have expected this to be done in some "larger" network management > component that is responsible for bringing up network interfaces according > to your configuration, rather than necessarily dhcpcd.service itself. In which case one would expect dhcpcd to depend on that instead; I can't see any obvious dependencies that would apply but I'm somewhat out of my depth here. > You mentioned Raspbian, which is a Debian derivative? Yes, Raspbian is Debian a derivative. > Typically server-class systems will use either ifupdown or > systemd-networkd, which are ideal for relatively static network > configurations that are set up by a sysadmin. It's definitely not systemd-networkd, to my untrained eye it looks like ifupdown is there but how do I confirm? dhcpcd seems to start very early in the boot and doesn't seem to be After anything on my Raspbian box. networking.service certainly includes After=network-pre.target and Before=network.target, but dhcpcd also includes Before=network.target - I can't see any combination of dependencies that would put dhcpcd.service later than networking.service. It's quite plausible that the "bug" here isn't necessarily the need for After=network-pre.target but as far as I can tell it is missing something. > If Raspbian does its own thing rather than recycling Debian components > for this, then it might need a separate bug report. I don't have a Debian box to check dhcpcd dependencies but I would assume that they're lifted from Debian, albeit that they may or may not be default Debian components. I have raised a Raspbian bug, which references this thread, so I'll see where that takes me. -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 11:27:30 +0200, Lennart Poettering wrote: > On Sa, 27.06.20 15:54, Mark Rogers (m...@more-solutions.co.uk) wrote: > > Adding After=network-pre.target to dhcpcd.service seems to have > > resolved it, and taught me a lesson in the process. > > > > Is there an obvious reason I'm missing why these aren't distro > > defaults? (Is this a "bug" in the network management tools' unit > > files? Would "fixing" this at the distro level have any likely side > > effects?) > > Yes, this is a bug in the the distro packaging. Please file a bug > against your distro, so that they add After=network-pre.target. I would have expected this to be done in some "larger" network management component that is responsible for bringing up network interfaces according to your configuration, rather than necessarily dhcpcd.service itself. You mentioned Raspbian, which is a Debian derivative? On Debian systems, network device management is typically provided by either ifupdown (the traditional/historical network management component in Debian), systemd-networkd, NetworkManager or wicd. If those aren't After network-pre.target, then they should be. Typically server-class systems will use either ifupdown or systemd-networkd, which are ideal for relatively static network configurations that are set up by a sysadmin. Portable/roaming systems like laptops will typically use either NetworkManager or wicd, which are ideal for dynamic network configuration through a GUI (and in particular, some desktop environments like GNOME have built-in support for NetworkManager). Desktop and embedded systems could go either way. In ifupdown, the networking.service and ifup@.service units are ordered After=network-pre.target, which I think should be sufficient. NetworkManager.service and systemd-networkd.service also look correct. However, wicd does not currently appear to have implemented this (I've opened a Debian bug). If Raspbian does its own thing rather than recycling Debian components for this, then it might need a separate bug report. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 10:27, Lennart Poettering wrote: > Yes, this is a bug in the the distro packaging. Please file a bug > against your distro, so that they add After=network-pre.target. > Will do. > My educated guess is that, it's not trvial to get this right: we > document what network-pre.target is for in systemd.special(7) man > page, but I figure not everyone looks there. And i guess one most know > a certain level of systemd to understand what this actually means for > a specific implementation. > Fair enough. >From that, is it reasonable to conclude that this is just an omission that has no potential negative effects from being fixed? I can't see any reason why adding After=network-pre.target would have direct a negative impact (it's plausible that on some systems it could subtly alter startup ordering and expose a bug that was previously hidden by luck, but that's not a reason to avoid doing it) and so there is no good reason not to do this, but my knowledge of this isn't adequate to make an informed statement on that matter. Before I make the argument for it being fixed I want to be sure of my argument! -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GNOME boot-complete.target integration ?
Hi, On 6/30/20 11:36 AM, Lennart Poettering wrote: On Mo, 29.06.20 11:02, Hans de Goede (hdego...@redhat.com) wrote: Hi All, For Fedora 33 I would like to get rid of some ugly hacks we have wrt the grub-hidden-menu feature Fedora has been shipping for a while now. One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu support to the Fedora grub-packages (the hidden-boot-menu stuff is not in upstream grub yet) and make GNOME use the dbus protocol to request rebooting into the boot menu. Another, harder part is boot-success or in systemd terms boot-complete support. ATM the Fedora GNOME packages contain a downstream patch which directly invokes "grub2-set-bootflag boot success". The plan is to have a grub2-bless-boot.service which will be a copy of systemd-bless-boot.service which will do grub's equivalent of calling /usr/lib/systemd/systemd-bless-boot good (we do not want automatic-boot-assesment, we just want the menu to show or not show on the next boot). This bit is east too. The tricky part is having grub2-bless-boot.service not run until GNOME says that it is ok. The thinking behind this (and current behavior) is that even if everything looks ok from the all services are running pov, then things might still be wrong. E.g. the kbd and mouse could be non-functional leaving the user with a non-functional system. So we only want to mark the boot successful after: 1. The user has logged in successfully and the session lasts at least 2 minutes (could be a bit shorter, we want to catch the case where the session immediately exits / crashes after login); or 2. The user selects reboot/shutdown from the GNOME system-control menu. In both these cases we want to block the boot-complete.target from being considered finished/ready until GNOME says it is. I can easily achieve this by not adding the grub2-bless-boot.service to any targets, and then manually starting it (with a polkit rule to allow a regular user to do this) when either condition becomes true, but then I still have the GNOME code doing something grub (Fedora's grub even) specific. So what I really want to do is delay the the boot-complete.target from being considered finished/ready until GNOME says it is. So the question really is, is there a way to have a unit wait with starting until a certain event happens? I guess I could use a Oneshot type service and have a little helper app which waits until it is signalled that the boot is complete? Any other ideas? Why not have a tiny service that is started as part of boot. It hangs around for 2min or, and then exits with failure. If however it is contacted by D-Bus before that it exist immediately with success. Then, make GNOME just ping that service if all is good. The service would then become part of the usual boot process, ordered before the boot blessing. Wouldn#t that suffice? That will break in the following scenario: 1. User powers on the machine goes to grab coffee 2. User returns after 5 min. logs in and goes to work Notice that the contacting by DBUS you suggest would not happen until after 2, at which point the timeout has happened. Currently for "boot-success" marking we rely on confirmation of successful interaction with the user (so working gfx output + kbd + mouse) and we want to keep doing that. If we remove the timeout from your proposal then it should work fine though. So I think we agree on needing a tiny service for this, which gets contacted by the GNOME session when the GNOME session considers the boot successful. The main difference between our proposals seems to be that I want to add the service to the boot-complete.target and you suggest adding it to the usual boot process, which I assume would be multi-user.target. To me adding it to boot-complete.target feels like it makes more sense, since the whole purpose of the mini service is just to delay boot-blessing, and AFAIK that is exactly what boot-complete.target is for ? Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GNOME boot-complete.target integration ?
On Mo, 29.06.20 11:02, Hans de Goede (hdego...@redhat.com) wrote: > Hi All, > > For Fedora 33 I would like to get rid of some ugly hacks we have > wrt the grub-hidden-menu feature Fedora has been shipping for a > while now. > > One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY > in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu > support to the Fedora grub-packages (the hidden-boot-menu stuff is > not in upstream grub yet) and make GNOME use the dbus protocol to > request rebooting into the boot menu. > > Another, harder part is boot-success or in systemd terms boot-complete > support. ATM the Fedora GNOME packages contain a downstream patch > which directly invokes "grub2-set-bootflag boot success". The plan > is to have a grub2-bless-boot.service which will be a copy of > systemd-bless-boot.service which will do grub's equivalent of > calling /usr/lib/systemd/systemd-bless-boot good (we do not > want automatic-boot-assesment, we just want the menu to show or > not show on the next boot). This bit is east too. > > The tricky part is having grub2-bless-boot.service not run until > GNOME says that it is ok. The thinking behind this (and current > behavior) is that even if everything looks ok from the all services > are running pov, then things might still be wrong. E.g. the kbd > and mouse could be non-functional leaving the user with a > non-functional system. So we only want to mark the boot successful > after: > > 1. The user has logged in successfully and the session lasts > at least 2 minutes (could be a bit shorter, we want to catch the > case where the session immediately exits / crashes after login); or > > 2. The user selects reboot/shutdown from the GNOME system-control > menu. > > In both these cases we want to block the boot-complete.target > from being considered finished/ready until GNOME says it is. > > I can easily achieve this by not adding the grub2-bless-boot.service > to any targets, and then manually starting it (with a polkit rule to > allow a regular user to do this) when either condition becomes true, > but then I still have the GNOME code doing something grub (Fedora's > grub even) specific. So what I really want to do is delay the > the boot-complete.target from being considered finished/ready until > GNOME says it is. > > So the question really is, is there a way to have a unit wait with > starting until a certain event happens? > > I guess I could use a Oneshot type service and have a little helper app > which waits until it is signalled that the boot is complete? Any other > ideas? Why not have a tiny service that is started as part of boot. It hangs around for 2min or, and then exits with failure. If however it is contacted by D-Bus before that it exist immediately with success. Then, make GNOME just ping that service if all is good. The service would then become part of the usual boot process, ordered before the boot blessing. Wouldn#t that suffice? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sa, 27.06.20 15:54, Mark Rogers (m...@more-solutions.co.uk) wrote: > > It could very well be because of the dhcpcd.service you're using. > > > > I don't know what it's like on Raspbian, but on Debian this unit appears > > to have no ordering with respect to network.target or network-pre.target > > at all. > > Ah, therein lies my failing - I assumed OS supplied units wouldn't > need adapting... > > Adding After=network-pre.target to dhcpcd.service seems to have > resolved it, and taught me a lesson in the process. > > Is there an obvious reason I'm missing why these aren't distro > defaults? (Is this a "bug" in the network management tools' unit > files? Would "fixing" this at the distro level have any likely side > effects?) Yes, this is a bug in the the distro packaging. Please file a bug against your distro, so that they add After=network-pre.target. My educated guess is that, it's not trvial to get this right: we document what network-pre.target is for in systemd.special(7) man page, but I figure not everyone looks there. And i guess one most know a certain level of systemd to understand what this actually means for a specific implementation. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup.service: cannot open file de-latin1-nodeadkeys
On Sa, 27.06.20 20:55, Reindl Harald (h.rei...@thelounge.net) wrote: > is this a dracut or systemd bug in Fedora 32? > > the other failing services at bottom are a direct reuslt of this while > everything seems to work fine, but i can't stand "failed" stuff when > consider a dist-upgrade This looks like dracut didn#t package the file correctly into the initrd. Please file a bug against dracut. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Accpetance of Environment Variables in Attributes
On Mo, 29.06.20 08:20, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > There's a whole section in the man page about this, it's called > > "Command Lines". It's referred to in the first line of the explanation > > of ExecStart=. > > It would be better to refer to the target section directly, instead of > referring to a section that refers to another section using a different > keyword, too. Send a patch as PR on github! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Error timeout while starting Arch
On Mo, 29.06.20 12:03, Marcos Alonso (marcos3...@gmail.com) wrote: > Hi, I installed Arch and it all works good except that I have to wait for a > timeout on startup. > That´s what I find in the journal: > > -- Logs begin at Wed 2020-06-10 22:59:26 CEST, end at Mon 2020-06-29 > 11:58:14 CEST. -- > Jun 29 11:56:44 masarch kernel: platform MSFT0101:00: failed to claim > resource 1: [mem 0xfed4-0xfed40fff] > Jun 29 11:56:44 masarch kernel: acpi MSFT0101:00: platform device creation > failed: -16 > Jun 29 11:58:14 masarch systemd[1]: Timed out waiting for device > /sys/subsystem/net/devices/service. Some unit is pulling the unit 'sys-subsystem-net-devices-service.device' into the initial transaction, which then waits for it to appear. Figure out which unit is responsible for that. Use "systemctl show sys-subsystem-net-devices-service.device" and have a look for the WantedBy= and RequiredBy= fields. The unit name looks fishy, this almost certainly indicates some incorrect unit file or other bug in the unit responsible. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd
On Mo, 29.06.20 12:19, Ian Pilcher (arequip...@gmail.com) wrote:
> I originally posted a variation of the question on the SELinux mailing
> list, but the more I look at this the more I realize that it really
> isn't a SELinux questions. I'm not really sure that it's a systemd
> question either, but it definitely falls into the area of Linux process
> management, so I'm hopeful that someone here at least has an idea what
> is going on ...
>
> I'm in the (hopefully) final stages of creating the policy module for a
> daemon that I've written to monitor my home NAS.
>
> The daemon is started by systemd (init_t) and runs as its own type
> (freecusd_t). In order to read the SMART attributes of the NAS drives,
> the daemon runs a helper application, which has its own type
> (freecusd_smart_t). So:
>
> systemd (init_t) --> freecusd (freecusd_t)
>--> freecusd_smart_helper (freecusd_smart_t)
>
> I've got my policy basically working, but I'm getting this SELinux
> denial, which I just don't understand:
>
> type=AVC msg=audit(1593392372.230:9215): avc: denied { sigchld } for pid=1
> comm="systemd" scontext=system_u:system_r:freecusd_smart_t:s0
> tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0
>
> This seems to be saying that the helper is trying to send SIGCHLD to
> systemd. I'm seeing this message repeated 4 times when the freecusd
> daemon starts and then sporadically afterwards. (freecusd repeatedly
> spawns the helper to read the drive states.)
>
> Is there a circumstance in which the grandchild (freecusd_smart_helper)
> would send SIGCHLD to systemd while its parent is still running?
Maybe it double forks or forks a child off (callout script?) that
double forks somewhere?
I don't know your software, it's probably best to ping the authors of
it about this, they should know what their software does.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Child of daemon sending SIGCHLD to systemd
>>> Ian Pilcher schrieb am 29.06.2020 um 19:19 in
Nachricht
<4792_1593451210_5EFA22CA_4792_148_1_rdd7rq$3aje$1...@ciao.gmane.io>:
> I originally posted a variation of the question on the SELinux mailing
> list, but the more I look at this the more I realize that it really
> isn't a SELinux questions. I'm not really sure that it's a systemd
> question either, but it definitely falls into the area of Linux process
> management, so I'm hopeful that someone here at least has an idea what
> is going on ...
>
> I'm in the (hopefully) final stages of creating the policy module for a
> daemon that I've written to monitor my home NAS.
>
> The daemon is started by systemd (init_t) and runs as its own type
> (freecusd_t). In order to read the SMART attributes of the NAS drives,
> the daemon runs a helper application, which has its own type
> (freecusd_smart_t). So:
>
>systemd (init_t) ‑‑> freecusd (freecusd_t)
> ‑‑> freecusd_smart_helper (freecusd_smart_t)
>
> I've got my policy basically working, but I'm getting this SELinux
> denial, which I just don't understand:
>
> type=AVC msg=audit(1593392372.230:9215): avc: denied { sigchld } for
> pid=1 comm="systemd" scontext=system_u:system_r:freecusd_smart_t:s0
> tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0
>
> This seems to be saying that the helper is trying to send SIGCHLD to
> systemd. I'm seeing this message repeated 4 times when the freecusd
> daemon starts and then sporadically afterwards. (freecusd repeatedly
> spawns the helper to read the drive states.)
>
> Is there a circumstance in which the grandchild (freecusd_smart_helper)
> would send SIGCHLD to systemd while its parent is still running?
Have you tried running your command unter "strace -f ..." to record what's
going on? You can restrict the syscalls to record if it's too many.
>
> ‑‑
>
> In Soviet Russia, Google searches you!
>
>
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
