[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 at .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 at 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 at .service) and use drop-ins to do 
per-instance overrides 
(/etc/systemd/system/xendomains at 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
> luizluca at gmail.com <mailto:luizluca at gmail.com>
>
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
Logo <http://www.smile.fr/>

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr <http://www.smile.fr/> 	
*Jérémy ROSEN*
Architecte technique
Email : jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
Tel : +33141402967

Facebook <https://www.facebook.com/smileopensource> Google%2B 
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn 
<https://www.linkedin.com/company/smile> Twitter 
<https://twitter.com/GroupeSmile>


bandeaux_mail 
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170913/d189db2e/attachment-0001.html>