Re: [systemd-devel] How to check watchdog status?
On Fri, Jan 7, 2022 at 4:56 PM Adam Nielsen wrote: > Hi all, > > If I have asked systemd to make use of a hardware watchdog by setting > RuntimeWatchdogSec in systemd.conf, how can I work out whether systemd > is actually using the hardware watchdog or not? > > There is a non-systemd command "wdctl" which queries /dev/watchdog0 and > tells you things like what the current timeout is set to, however > on some of my machines this works, but on others it gives an error > saying /dev/watchdog0 is unavailable. > > Some reading suggests only one program can access /dev/watchdog0 at a > time, so I am not sure whether this means systemd is already using the > watchdog and that's why wdctl can't access it, or does it mean the > watchdog hardware isn't working properly? On the machines where wdctl > does print details about /dev/watchdog0, does this mean systemd has not > taken ownership of it, or does that device allow multiple instances of > the watchdog? > Recent versions of util-linux will obtain the information through /sys if they're unable to open the watchdog device for whatever reason. Older versions just give up. Generally, if systemd or something else is actively using the watchdog, then wdctl will report a "Timeleft" value lower than the total "Timeout" as it is actively counting down. (If it does report identical values, that *could* mean systemd just pinged the watchdog, so wait 1-2 seconds and check again.) -- Mantas Mikulėnas
Re: [systemd-devel] Automatically moving forked processes in a different cgroup based on children's UID
Hello Wadih. On Sat, Jan 01, 2022 at 04:41:12PM -0500, Wadih wrote: > Is there a way to automatically classify child processes of a process > in a different cgroup than the spawning process with systemd based on > the children's new UID? I know apache2-mpm-itk calls setuid() on its > children, so we would have to somehow hook on that. You can summon the whole PAM machinery and include pam_systemd in the stack which would create a new session scope for the user. (Or do it yourself from the process via DBus call org.freedesktop.systemd1.Manager.StartTransientUnit() that gives you more freedom for that). (Note that to keep the service lifecycle tracking under the name of apache2.service, the forked children should not reparent under PID 1 so that service parent can properly track them.) > I'd like to have the child processes that apache2-mpm-itk spawns go > under their respective user, e.g. > [...] > system.slice/apache2.service/vhosts/%UID% That's an alternative of maintaining the (relative) (sub)hierachy yourself (and it doesn't require special treating wrt apache2.service lifecycle). Note that for this cgroup tree you'd need to specify apache2.service Delegate= directive though. > I've been able to do this with cgrulesengd and cgconfigparser for 3 > years, it's been rock solid. I'm glad it work(s|ed) for you. The asynchronous classification via cgrulesengd is racy and may not be always reliable (wrt resource control). It's much better to do fork-classify-exec or fork(CLONE_INTO_CGROUP)-exec synchronously in the migrated task. > Would the only solution for me to create a daemon which monitors for > setuid() calls of the parent apache process, and classify the children > as per the new setuid user? I'd discourage you of going the path of cgrulesengd again. (And cgroupify too :-p) > Or perhaps, I think root parent processes spawning specific UID > children is a common security practise, perhaps there should be > something in systemd out of the box for classifying the children under > their respective cgroups? Yes, on the low level it's the StartTransientUnit() DBus call or its specialized extensions for logind or machinectl. > If my only solution is to create a daemon which monitors for setuid() > I'll do it, although I've never done it before, not sure where I'd have > to start. Any guidance would be great! More viable way seems to me to modify the apache2-mpm-itk to put children into respective cgroups. HTH, Michal
