Re: [systemd-devel] Child of daemon sending SIGCHLD to systemd
On Mon, Jun 29, 2020 at 02:11:06PM -0500, Ian Pilcher wrote: > On 6/29/20 2:00 PM, Vito Caputo wrote: > > I don't know about freecusd, but if it uses a fire-and-forget approach > > to launching helpers, as in it double-forks, so it doesn't need to > > bother with asynchronously reaping zombies, then the second fork > > becomes a child of init. That results in the second forked child > > becoming a child of init, sending SIGCHLD to init on exit. > > Nope, it reaps its own children (usually in response to catching a > SIGCHLD). > > (freecusd itself does double-fork at startup, as it was written back in > the pre-systemd CentOS 6 days, but I'm pretty sure that's not what > you're talking about.) > If I were in your shoes I'd try reproduce this with a minimal test case. Freecusd mixes threads and processes, and is a substantial program with plenty opportunities for bugs. Have you tried using a minimal test daemon which just forks, with the parent reaping via waitpid, to see if it triggers the same sigchld for init? No threads, no anything, just a little dozen line thing. Regards, Vito Caputo ___ 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 6/29/20 2:00 PM, Vito Caputo wrote: I don't know about freecusd, but if it uses a fire-and-forget approach to launching helpers, as in it double-forks, so it doesn't need to bother with asynchronously reaping zombies, then the second fork becomes a child of init. That results in the second forked child becoming a child of init, sending SIGCHLD to init on exit. Nope, it reaps its own children (usually in response to catching a SIGCHLD). (freecusd itself does double-fork at startup, as it was written back in the pre-systemd CentOS 6 days, but I'm pretty sure that's not what you're talking about.) -- 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] Child of daemon sending SIGCHLD to systemd
On Mon, Jun 29, 2020 at 12:19:54PM -0500, Ian Pilcher wrote: > > > Is there a circumstance in which the grandchild (freecusd_smart_helper) > would send SIGCHLD to systemd while its parent is still running? > I don't know about freecusd, but if it uses a fire-and-forget approach to launching helpers, as in it double-forks, so it doesn't need to bother with asynchronously reaping zombies, then the second fork becomes a child of init. That results in the second forked child becoming a child of init, sending SIGCHLD to init on exit. This is a normal thing, that's part of the init processes job, to be a process orphanage of sorts and reap orphaned processes. Regards, Vito Caputo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Child of daemon sending SIGCHLD to systemd
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?
--
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] Error timeout while starting Arch
Am 29.06.20 um 12:03 schrieb Marcos Alonso: > 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. > -- Subject: A start job for unit > sys-subsystem-net-devices-service.device has failed > -- Defined-By: systemd > -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- A start job for unit sys-subsystem-net-devices-service.device has > finished with a failure. > -- > -- The job identifier is 91 and the job result is timeout. sounds like an arch specific issue given that a network card called "service" is unlikely to be generic your error: sys-subsystem-net-devices-service.device the last part is normally the name of the interface: sys-subsystem-net-devices-vpn.device sys-subsystem-net-devices-wan.device additionally normally --- just look at the output of [root@srv-rhsoft:~]$ systemctl list-units | grep sys-subsystem-net-devices sys-subsystem-net-devices-br\x2dguest.device loaded active plugged /sys/subsystem/net/devices/br-guest sys-subsystem-net-devices-br\x2dlan.device loaded active plugged /sys/subsystem/net/devices/br-lan sys-subsystem-net-devices-br\x2dwan.device loaded active plugged /sys/subsystem/net/devices/br-wan sys-subsystem-net-devices-lan\x2dguest.device loaded active plugged 82580 Gigabit Network Connection (NC365T 4-port Ethernet Server Adapter) sys-subsystem-net-devices-lan\x2dspare1.device loaded active plugged 82580 Gigabit Network Connection (NC365T 4-port Ethernet Server Adapter) sys-subsystem-net-devices-lan\x2dspare2.device loaded active plugged 82580 Gigabit Network Connection (NC365T 4-port Ethernet Server Adapter) sys-subsystem-net-devices-lan\x2dtv.device loaded active plugged 82580 Gigabit Network Connection (NC365T 4-port Ethernet Server Adapter) sys-subsystem-net-devices-poe\x2dphone.device loaded active plugged RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller sys-subsystem-net-devices-poe\x2dspare.device loaded active plugged RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller sys-subsystem-net-devices-vmnet1.device loaded active plugged /sys/subsystem/net/devices/vmnet1 sys-subsystem-net-devices-vmnet8.device loaded active plugged /sys/subsystem/net/devices/vmnet8 sys-subsystem-net-devices-vpn.device loaded active plugged /sys/subsystem/net/devices/vpn sys-subsystem-net-devices-wan.device loaded active plugged 82579LM Gigabit Network Connection (Lewisville) sys-subsystem-net-devices-wlan0.device loaded active plugged AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (DWA-556 Xtreme N PCI Express Desktop Adapter) sys-subsystem-net-devices-wlan1.device loaded active plugged AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (DWA-556 Xtreme N PCI Express Desktop Adapter) [root@srv-rhsoft:~]$ --- [root@srv-rhsoft:~]$ ip a | grep mtu 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 2: poe-spare: mtu 1500 qdisc fq_codel master br-lan state DOWN group default qlen 1000 3: poe-phone: mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000 4: lan-guest: mtu 1500 qdisc mq master br-guest state DOWN group default qlen 1000 5: lan-spare2: mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000 6: wan: mtu 1500 qdisc hfsc master br-wan state UP group default qlen 1000 7: lan-spare1: mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000 8: lan-tv: mtu 1500 qdisc mq master br-lan state UP group default qlen 1000 9: wlan0: mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000 10: vmnet1: mtu 1500 qdisc fq_codel master br-wan state UNKNOWN group default qlen 1000 11: vmnet8: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 12: br-wan: mtu 1500 qdisc noqueue state UP group default qlen 1000 13: vpn: mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000 14: br-lan: mtu 1500
[systemd-devel] Error timeout while starting Arch
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. -- Subject: A start job for unit sys-subsystem-net-devices-service.device has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit sys-subsystem-net-devices-service.device has finished with a failure. -- -- The job identifier is 91 and the job result is timeout. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] GNOME boot-complete.target integration ?
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? Regards, Hans ___ 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
>>> Lennart Poettering schrieb am 26.06.2020 um 15:32 in Nachricht <20200626133248.GC163121@gardel-login>: > On Fr, 26.06.20 11:40, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > [...] >> In the version of the man pages I have the decription of ExecReload= in >> systemd.service(5) says "Specifier and environment variable substitution is >> supported here following the same scheme as for ExecStart=.", but the word >> "environment" doe not occur in the description of ExecStart. ;‑) > > 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. [...] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
