[systemd-devel] Why does nspawn check if in a user session?

[Luke Shumaker]

Hi all,

I have another question about `systemd-nspawn` internals.

When sanity-checking argv, it does:

if (arg_keep_unit && arg_register && cg_pid_get_owner_uid(0, NULL) >= 
0) {
log_error("--keep-unit --register=yes may not be used when 
invoked from a user session.");
return -EINVAL;
}

  (the `&& arg_register` bit was added in 234)

Why does nspawn care if it is in a user session?

My best guess is that it doesn't want to share its cgroup with any
other processes, and it is using user session membership as a sloppy
proxy for that.  If that's the case, wouldn't it be more correct and
robust to check for other processes in
"/sys/fs/cgroup/.../cgroup.procs"?

-- 
Happy hacking,
~ Luke Shumaker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to specify dynamic services/requirements

[Jérémy Rosen]

On 13/09/2017 06:08, Luiz Angelo Daros de Luca wrote:

Hello,

I'm facing a problem with Xen machines that depends on MD devices.
As I'm new to systemd world, I might not be seeing the clean solution.
That's why I'm asking for an advice.

MD devices are automatically detect by udev. If device state is safe, 
/dev/md/myraid is started. However, if the state is not safe (like a 
raid with a missing disk), udev starts mdadm-last-resort@.timer that 
tries to start the device anyway after 30s. As mdadm-last-resort 
conflicts with the device presence, it will not run if the required 
disk appears before 30s. Even with mdadm-last-resort running, MD 
device might still be usable, although degraded.


Xen VM are started by xendomains.service, that simply calls a shell 
script like in SysV times. It start a bunch of VM in sequence. 
xendomains.service has only generic dependencies that let it run at a 
very early stage.
I would cut that script in multiple services... but you mention doing 
that below, so I'm just saying I think it's the right way to go :)


Now the problem: If for any reason, a MD device takes some seconds to 
appear (or even 30s as the last resort), xendomains will fail to start 
any machine that depends on that MD device.


I'm extending manually xendomains.service to depend on a series of MD 
devices, that fixed the start order problem. However, I created new 
problems. First I had to frequently regenerate those "Requires" as 
machines are frequently started/migrated between hosts (I also 
consider using systemd generators). But worse, whenever a single MD 
device permanently fails, xendomains is never started and all those VM 
that does not use the failed MD never start.


I though that maybe I could use instances (xendomains@vm1.service) to 
launch VM individually, each of them depending on those devices it 
uses. However, these instances would have to be dynamically generated 
based on its configuration (systemd generators from 
/etc/xen/vm/xxx.cfg?), either on boot, shutdown or simply 
periodically. The stop procedure will still be the same, calling the 
SysV script as systemd will not know about VM (re)started after boot.
you could create a template (xendomains@.service) and use drop-ins to do 
per-instance overrides 
(/etc/systemd/system/xendomains@vm1.service.d/append.conf) that would 
allow you to individualize each domain while keeping the common parts


I would find a way to prevent a domain with no corresponding to start 
(maybe by not defining a mandatory key in the template) to make sure no 
rogue domains are created...


I even though about simply create an alternative xendomains.service 
that does not depend on any MD device and launch it using a systemd 
timer if the xendomains that depends on MD devices isn't started after 
30s. It looks ugly but it might work.


Regards,
--

Luiz Angelo Daros de Luca
luizl...@gmail.com 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
Logo 

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr    
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr 
Tel : +33141402967

Facebook  Google%2B 
 LinkedIn 
 Twitter 




bandeaux_mail 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel