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

2017-09-15 Thread Jérémy Rosen 



On 15/09/2017 07:27, Luiz Angelo Daros de Luca wrote:

Thanks Jérémy,

That was what I needed. I was afraid to be headed to the wrong way. 
Now that I know what to do, I need to know where and when.


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 would use a template like xendomains@.service in order to specify 
common stuff. However, the config of which vm are enabled (autostart) 
is only available at boot time. Is a systemd generator the way to go? 
Is is there another way to define it?




Also, should I use a service patch (like append.conf you mentioned) or 
simply directly create /run/.../xendomains@vm1.service?


both method work... the first one allow to add stuff to the common 
template, the second to override more easily in the case of a VM that is 
totally different from the others...
It would be trivial to define a template xendomains@.service and start 
services like "systemctl start xendomains@vm1.service", that would 
read /etc/xen/vm/vm1 and launch it. I just don't know how I could 
define dynamic dependency for that instance depending on the content 
of /etc/xen/vm/vm1. Execstartpre can check requirements and prevent a 
service to run but not wait for a resource to be available. It would 
be something like ExecRequires=.
A generator is probably the way to go... generators can create ANY 
systemd configuration files, including templates, drop-ins and .wants 
directory


You probably already found that, but in case you didn't, you should read 
the DESCRIPTION section of man:systemd.unit It describes all the ways 
you can add files to configure units


In particular, if you want a service started at boot time, you need to 
create a default.target.wants/ directory and add a symbolic link to the 
unit to start in there. Populating such a directory at boot time with a 
generator might be the best approch for you...


Instances seems to be created only when asked directly (systemctl 
start xendomains@vm1.service), which might be triggered by something 
like udev event. Is there anything like 
ExecListStartInstances=, ExecListRunningInstances=?
see my answer above. There is no such thing, but generators can do the 
equivalent by creating a .wants link


(as a side note, I don't know if you could do a "systemctl enable 
--runtime" from a generator. maybe someone else here would know)
Generators can create something like that but they are triggered only 
at boot and daemon-reload. It would be interesting to somehow run 
"something like generators" when start/stop/status is called.

what would be your use-case ?
status is not "an event" nothing real happens on status
start/stop can propagate stuff based on their parameters, but the 
services themselves are not meant to be dynamic...


That being said, it might be possible to dinamically add dependencies to 
a unit via dbus and/or systemctl set-property, but I have never tried 
it, so you'll need to try and see




From what I know about systemd, I'm thinking of something like a 
generator that will create services for all autostart and saved vm. 
The current script-based xendomains.service will run after 
all xendomains@.service instances. This way, a new enabled-after-boot 
vm would be started with "systemctl restart xendomains". I could use 
the existence of /etc/xen/auto/vm or /var/lib/xen/save/vm as 
requirement for xendomains@vm.service, in order to avoid to start a 
disabled-after-boot vm. However, this does not look like an elegant 
solution.
Your requirements seems very complex (and, I have to admit, a bit hard 
to understand through e-mail) but I think that with a good understanding 
of templates and generators it can be solved elegantly


* use templates to define how to start vms (common parts in the 
template, particularities in the instances)
* add all boot-time depedencies via .wants directory via a generator 
(maybe usint systemctl enable if it can be run at generator-time, but 
i'm not sure it's possible)



Hope this helps

Jérémy



Regards,

--

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



--
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

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

2017-09-14 Thread Luiz Angelo Daros de Luca 
Thanks Jérémy,

That was what I needed. I was afraid to be headed to the wrong way. Now
that I know what to do, I need to know where and when.

> 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 would use a template like xendomains@.service in order to specify common
stuff. However, the config of which vm are enabled (autostart) is only
available at boot time. Is a systemd generator the way to go? Is is there
another way to define it?

Also, should I use a service patch (like append.conf you mentioned) or
simply directly create /run/.../xendomains@vm1.service?

It would be trivial to define a template xendomains@.service and start
services like "systemctl start xendomains@vm1.service", that would read
/etc/xen/vm/vm1 and launch it. I just don't know how I could define dynamic
dependency for that instance depending on the content of /etc/xen/vm/vm1.
Execstartpre can check requirements and prevent a service to run but not
wait for a resource to be available. It would be something like
ExecRequires=.

Instances seems to be created only when asked directly (systemctl start
xendomains@vm1.service), which might be triggered by something like udev
event. Is there anything like
ExecListStartInstances=, ExecListRunningInstances=?
Generators can create something like that but they are triggered only at
boot and daemon-reload. It would be interesting to somehow run "something
like generators" when start/stop/status is called.

>From what I know about systemd, I'm thinking of something like a generator
that will create services for all autostart and saved vm. The current
script-based xendomains.service will run after all xendomains@.service
instances. This way, a new enabled-after-boot vm would be started with
"systemctl restart xendomains". I could use the existence of
/etc/xen/auto/vm or /var/lib/xen/save/vm as requirement
for xendomains@vm.service, in order to avoid to start a disabled-after-boot
vm. However, this does not look like an elegant solution.

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

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

2017-09-13 Thread 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

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

2017-09-12 Thread Luiz Angelo Daros de Luca 
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.

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.

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