[systemd-devel] how-to run instantiated units from templates one after the other

[Dmitry Karpov]

I have a template for creating the backup:

backup@.service

[Unit]

Description=Instance %i

[Service]

ExecStart=/bin/sh -c "echo do backup job for %i"

[Install]

WantedBy=maintenance.target

and some target:

maintenance.target

[Unit]

Description=target for maintenance

StopWhenUnneeded=yes 

As can be seen, instances from backup@ start with maintenance.target. But they 
run in parallel.

There is some way to run them one after the other?

I thought that specifying Conflicts=backup@*.service in the template should 
lead to this, but it is not.




smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[Reindl Harald]

Am 18.09.2015 um 11:51 schrieb lucien xin:

On Fri, Sep 18, 2015 at 5:11 PM, Reindl Harald  wrote:



Am 18.09.2015 um 11:03 schrieb lucien xin:


is there a options that can define some common shutdown/boot order
priority? not through dependence( After= and Before= you mentioned).



no, and it makes no sense at all

wether servcies are dpending on each other then you need to define
dependencies and if they are not they don't need to be ordered and can start
in parallel


for example, A.service maybe 5, network.target and teamd are 1, the
service whose order priority is 4 will be shudown earlier than that
priority is 1.



that would be unmanageable because it interfers with Before/After/Requires
and at the end of the day you have conflicts or no idea what is schedlued
how and why



okay,

as to the case I mentioned, if A.service want to be shutdown before
teamd, the only way is to configure After=/Before= options
in A.serivce, right?


yes

while it make sno difference if you define Before= in one unit or After= 
in the other, if a service at shutdown should be stopped before another 
one it needs just to be startet afterward at boot


and it makes sense

* something needs networking
* so it is started after networking at boot
* well, it is hence implicit stopped before network at shutdown
* otherwise it may hang because it does some network operation
  at stop while network is no longer there
* that's why it are dependencies which also means one needs the other






signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[Andrei Borzenkov]

On Fri, Sep 18, 2015 at 10:44 AM, lucien xin  wrote:
> I have some services which need to start after "network.target", and
> shutdown before "network.target". but systemd didn't know "teamd" also
> belongs to "network.target", so it won't shutdown the service before
> "teamd".
>
> to workaround it, I need to define "After=teamd@team0.service
> teamd@team1.service"  to the affected service. but that seems
> really stupid. are there better ways so if the service require
> "network.target", systemd will shutdown it before teamd?
>
> is there a way to make "teamd" belongs to "network.target",  or
> another way to meet that requirement?
>

Just order teamd before network.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[lucien xin]

On Fri, Sep 18, 2015 at 3:55 PM, Andrei Borzenkov  wrote:
> On Fri, Sep 18, 2015 at 10:44 AM, lucien xin  wrote:
>> I have some services which need to start after "network.target", and
>> shutdown before "network.target". but systemd didn't know "teamd" also
>> belongs to "network.target", so it won't shutdown the service before
>> "teamd".
>>
>> to workaround it, I need to define "After=teamd@team0.service
>> teamd@team1.service"  to the affected service. but that seems
>> really stupid. are there better ways so if the service require
>> "network.target", systemd will shutdown it before teamd?
>>
>> is there a way to make "teamd" belongs to "network.target",  or
>> another way to meet that requirement?
>>
>
> Just order teamd before network.target

sorry, I cannot follow you.

I mean, now my A.service is shutdown before network.target.
but I also wnat A.service to be shutdown before teamd,
define "After=teamd@team0.service teamd@team1.service"
in A.service can work, but I hope there is another way,

like there may be another option can make A.service's shutdown
'level' earlier than both teamd and network.target's shutdown 'level'

i do not know, just ask.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[Reindl Harald]

Am 18.09.2015 um 10:34 schrieb lucien xin:

Just order teamd before network.target


sorry, I cannot follow you.


After=network.target


I mean, now my A.service is shutdown before network.target.
but I also wnat A.service to be shutdown before teamd,
define "After=teamd@team0.service teamd@team1.service"
in A.service can work, but I hope there is another way,

like there may be another option can make A.service's shutdown
'level' earlier than both teamd and network.target's shutdown 'level'

i do not know, just ask


services are stopped in the reverse order they are started and so with 
After= and Before= you just need to adjust the order you want




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[Andrei Borzenkov]

On Fri, Sep 18, 2015 at 12:03 PM, lucien xin  wrote:
>
> is there a options that can define some common shutdown/boot order
> priority? not through dependence( After= and Before= you mentioned).
>
> for example, A.service maybe 5, network.target and teamd are 1, the
> service whose order priority is 4 will be shudown earlier than that
> priority is 1.

No. It is assumed that if service does not declare dependency on
another service both can be started concurrently.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[lucien xin]

>
> yes
>
> while it make sno difference if you define Before= in one unit or After= in
> the other, if a service at shutdown should be stopped before another one it
> needs just to be startet afterward at boot
>
> and it makes sense
>
> * something needs networking
> * so it is started after networking at boot
> * well, it is hence implicit stopped before network at shutdown
> * otherwise it may hang because it does some network operation
>   at stop while network is no longer there
> * that's why it are dependencies which also means one needs the other
>
>

then, about this bug, https://bugzilla.redhat.com/show_bug.cgi?id=1264175
it's a special case
do you have any idea what we can do in teamd.service to avoid this issue?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd 226: Neither machinectl login nor machinectl shell works

[Michael Biebl]

2015-09-18 22:34 GMT+02:00 Tobias Hunger :
>
> Any progress yet on the "very soon now" release?

This fix is supposed to be part of the v226 release, which was
released on 2015-09-08.
You raised this issue on 2015-09-05, so you didn't have v226 back then.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd 226: Neither machinectl login nor machinectl shell works

[Tobias Hunger]

On Sun, Sep 6, 2015 at 12:13 PM, Lennart Poettering
 wrote:

> This should be fixed with git now. And we'll do a new release very
> soon now.

Any progress yet on the "very soon now" release?

Building systemd manually and then integrating that into a newly
installed copy of a distribution sucks:-)

Best Regards,
Tobias
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] PATCH: src/udev/ata_id/ata_id.c: WWN recognition fails on big-endian systems

[Tom Lyon]

--- a/src/udev/ata_id/ata_id.c
+++ b/src/udev/ata_id/ata_id.c
@@ -485,6 +485,10 @@ int main(int argc, char *argv[])
 disk_identify_fixup_uint16(identify.byte,  90); /*
time required for enhanced SECURITY ERASE UNIT */
 disk_identify_fixup_uint16(identify.byte,  91); /*
current APM values */
 disk_identify_fixup_uint16(identify.byte,  94); /*
current AAM value */
+disk_identify_fixup_uint16(identify.byte, 108); /* wwn
*/
+disk_identify_fixup_uint16(identify.byte, 109); /* wwn
*/
+disk_identify_fixup_uint16(identify.byte, 110); /* wwn
*/
+disk_identify_fixup_uint16(identify.byte, 111); /* wwn
*/
 disk_identify_fixup_uint16(identify.byte, 128); /*
device lock function */
 disk_identify_fixup_uint16(identify.byte, 217); /*
nominal media rotation rate */
 memcpy(, identify.byte, sizeof id);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question related to cgroup and systemd

[Francis Moreau]

Hello Lennart,

On Fri, Sep 18, 2015 at 2:24 PM, Lennart Poettering
 wrote:
> B1;4002;0cOn Fri, 18.09.15 14:11, Francis Moreau (francis.m...@gmail.com) 
> wrote:
>
>> Hi,
>>
>> I'm trying to understand how cgroup is used by systemd and having the
>> following behaviour that I don't understand.
>>
>> I've created a slice "myslice.slice" with this resource constraint
>> "MemoryLimit=1024" and started it.
>>
>> I was expecting to find a trace of myslice in /sys/fs/cgroup/memory
>> folder but I can't find anything.
>
> systemd realizes croups only when we add processes to it.
>
>> I  put a process inside the slice (with the help of systemd-run
>> --slice=myslice), but nothing was created under /sys/fs/cgroup/memory
>> either.
>
> So, this works fine for me:
>
> # systemd-run --slice=my-deep-slice.slice -p MemoryLimit=3G /bin/sleep 9
>
> It creates the specified slice, and places the new service in it, then
> adds the process in it and sets the memory.limit_in_bytes= attribute
> on the services' cgroup.
>
> Does this not work for you?

I dont think so:

$ cat ~/.config/systemd/user/myslice.slice
[Slice]
MemoryLimit=1024
$ systemctl --user start myslice.slice
$ systemctl --user status myslice.slice
● myslice.slice
   Loaded: loaded (/home/fmoreau/.config/systemd/user/myslice.slice;
static; vendor preset: enabled)
  Active: active since Fri 2015-09-18 14:35:59 CEST; 4s ago

Sep 18 14:35:59 cyclone systemd[752]: Created slice myslice.slice.

$ systemd-run --user --slice=myslice.slice /bin/sleep 9
Running as unit run-793.service.
$ systemctl --user status myslice.slice
● myslice.slice
   Loaded: loaded (/home/fmoreau/.config/systemd/user/myslice.slice;
static; vendor preset: enabled)
  Active: active since Fri 2015-09-18 14:35:59 CEST; 1min 29s ago
 CGroup: /user.slice/user-1000.slice/user@1000.service/myslice.slice
└─run-793.service
 └─794 /bin/sleep 9

Sep 18 14:35:59 cyclone systemd[752]: Created slice myslice.slice.

$ find /sys/fs/cgroup/memory/ -name myslice\*
$
$ find /sys/fs/cgroup/systemd/ -name myslice\*
/sys/fs/cgroup/systemd/user.slice/user-1000.slice/user@1000.service/myslice.slice

> Which systemd version are you using?

systemd 225-1 (Archlinux).

>> I was expecting that "myslice.slice" would have its own directory
>> inside /sys/fs/cgroup/memory directory (ie inside the memory
>> controller) and the memory constraint applied to that directory and
>> hence all its children.
>
> Correct. But again, we only realize groups when we really need to.
>

Ok understood.

>> But it seems I'm missing something.
>>
>> Could anybody enlight me please ?
>>
>> Also I'm a bit lost regarding kernel cgroup and its reworked API. Does
>> systemd already use this new API or is it still using the old/broken
>> one ?
>
> Yes, the concept of scopes, services and slices and how they are
> mapped to cgroupfs is fully implemented. We currently don't expose all
> controllers and all settings, but that's mostly because the
> controllers are awful and in progress of being fixed, and we only want
> to expose them as soon as they are cleaned up and here to stay with
> their new settings.
>
> In the most recent systemd release we even support the new kernel
> unified hierarchy now, but you have to select at boot time which one
> you want: the legacy one as before, or the unified one.
>

Which kernel version starts to support the new unified hierarchy ? Is
there a doc which explain it ?

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Reason for logind using DRM_IOCTL_DROP_MASTER?

[Andrei Borzenkov]

I have weird case where attempt to start program on discrete card fails with

[ 1064.755339] [DEBUG][XORG] (--) using VT number 7
[ 1064.755345] [DEBUG][XORG] (II) systemd-logind: logind integration
requires -keeptty and -keeptty was not provided, disabling logind
integration
[ 1064.755351] [DEBUG][XORG] (II) xfree86: Adding drm device
(/dev/dri/card0)
[ 1064.755359] [ERROR][XORG] (EE) /dev/dri/card0: failed to set DRM
interface version 1.4: Permission denied

As far as I could trace it, it is related to logind calling
DRM_IOCTL_DROP_MASTER, as this is the only reason for ioctl to fail
with EACCESS.

This basically renders bumblebee unusable. Any reason logind needs to
call it? I have quite limited understanding of how DRM in Linux works,
so anyone could suggest what should be done here?

Thank you!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Question related to cgroup and systemd

[Francis Moreau]

Hi,

I'm trying to understand how cgroup is used by systemd and having the
following behaviour that I don't understand.

I've created a slice "myslice.slice" with this resource constraint
"MemoryLimit=1024" and started it.

I was expecting to find a trace of myslice in /sys/fs/cgroup/memory
folder but I can't find anything.

I  put a process inside the slice (with the help of systemd-run
--slice=myslice), but nothing was created under /sys/fs/cgroup/memory
either.

I was expecting that "myslice.slice" would have its own directory
inside /sys/fs/cgroup/memory directory (ie inside the memory
controller) and the memory constraint applied to that directory and
hence all its children.

But it seems I'm missing something.

Could anybody enlight me please ?

Also I'm a bit lost regarding kernel cgroup and its reworked API. Does
systemd already use this new API or is it still using the old/broken
one ?

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question related to cgroup and systemd

[Lennart Poettering]

B1;4002;0cOn Fri, 18.09.15 14:11, Francis Moreau (francis.m...@gmail.com) wrote:

> Hi,
> 
> I'm trying to understand how cgroup is used by systemd and having the
> following behaviour that I don't understand.
> 
> I've created a slice "myslice.slice" with this resource constraint
> "MemoryLimit=1024" and started it.
> 
> I was expecting to find a trace of myslice in /sys/fs/cgroup/memory
> folder but I can't find anything.

systemd realizes croups only when we add processes to it.

> I  put a process inside the slice (with the help of systemd-run
> --slice=myslice), but nothing was created under /sys/fs/cgroup/memory
> either.

So, this works fine for me:

# systemd-run --slice=my-deep-slice.slice -p MemoryLimit=3G /bin/sleep 9

It creates the specified slice, and places the new service in it, then
adds the process in it and sets the memory.limit_in_bytes= attribute
on the services' cgroup.

Does this not work for you? Which systemd version are you using?

> I was expecting that "myslice.slice" would have its own directory
> inside /sys/fs/cgroup/memory directory (ie inside the memory
> controller) and the memory constraint applied to that directory and
> hence all its children.

Correct. But again, we only realize groups when we really need to.

> But it seems I'm missing something.
> 
> Could anybody enlight me please ?
> 
> Also I'm a bit lost regarding kernel cgroup and its reworked API. Does
> systemd already use this new API or is it still using the old/broken
> one ?

Yes, the concept of scopes, services and slices and how they are
mapped to cgroupfs is fully implemented. We currently don't expose all
controllers and all settings, but that's mostly because the
controllers are awful and in progress of being fixed, and we only want
to expose them as soon as they are cleaned up and here to stay with
their new settings.

In the most recent systemd release we even support the new kernel
unified hierarchy now, but you have to select at boot time which one
you want: the legacy one as before, or the unified one.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[lucien xin]

On Fri, Sep 18, 2015 at 5:11 PM, Reindl Harald  wrote:
>
>
> Am 18.09.2015 um 11:03 schrieb lucien xin:
>>
>> is there a options that can define some common shutdown/boot order
>> priority? not through dependence( After= and Before= you mentioned).
>
>
> no, and it makes no sense at all
>
> wether servcies are dpending on each other then you need to define
> dependencies and if they are not they don't need to be ordered and can start
> in parallel
>
>> for example, A.service maybe 5, network.target and teamd are 1, the
>> service whose order priority is 4 will be shudown earlier than that
>> priority is 1.
>
>
> that would be unmanageable because it interfers with Before/After/Requires
> and at the end of the day you have conflicts or no idea what is schedlued
> how and why
>
>
okay,

as to the case I mentioned, if A.service want to be shutdown before
teamd,
the only way is to configure After=/Before= options in A.serivce, right ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] a problem about the order of service shudown in systeamd

[lucien xin]

I have some services which need to start after "network.target", and
shutdown before "network.target". but systemd didn't know "teamd" also
belongs to "network.target", so it won't shutdown the service before
"teamd".

to workaround it, I need to define "After=teamd@team0.service
teamd@team1.service"  to the affected service. but that seems
really stupid. are there better ways so if the service require
"network.target", systemd will shutdown it before teamd?

is there a way to make "teamd" belongs to "network.target",  or
another way to meet that requirement?

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

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[Andrei Borzenkov]

On Fri, Sep 18, 2015 at 11:44 AM, Reindl Harald  wrote:
>
>
> Am 18.09.2015 um 10:34 schrieb lucien xin:
>>>
>>> Just order teamd before network.target
>>
>>
>> sorry, I cannot follow you.
>
>
> After=network.target
>

Actually I meant that teamd should have

Before=network.target

Then anything ordered after network.target will be stopped early enough.

>> I mean, now my A.service is shutdown before network.target.
>> but I also wnat A.service to be shutdown before teamd,
>> define "After=teamd@team0.service teamd@team1.service"
>> in A.service can work, but I hope there is another way,
>>
>> like there may be another option can make A.service's shutdown
>> 'level' earlier than both teamd and network.target's shutdown 'level'
>>
>> i do not know, just ask
>
>
> services are stopped in the reverse order they are started and so with
> After= and Before= you just need to adjust the order you want
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] a problem about the order of service shudown in systeamd

[lucien xin]

On Fri, Sep 18, 2015 at 4:44 PM, Reindl Harald  wrote:
>
>
> Am 18.09.2015 um 10:34 schrieb lucien xin:
>>>
>>> Just order teamd before network.target
>>
>>
>> sorry, I cannot follow you.
>
>
> After=network.target
>
>> I mean, now my A.service is shutdown before network.target.
>> but I also wnat A.service to be shutdown before teamd,
>> define "After=teamd@team0.service teamd@team1.service"
>> in A.service can work, but I hope there is another way,
>>
>> like there may be another option can make A.service's shutdown
>> 'level' earlier than both teamd and network.target's shutdown 'level'
>>
>> i do not know, just ask
>
>
> services are stopped in the reverse order they are started and so with
> After= and Before= you just need to adjust the order you want
>
>
okay, I got you, thanks.

is there a options that can define some common shutdown/boot order
priority? not through dependence( After= and Before= you mentioned).

for example, A.service maybe 5, network.target and teamd are 1, the
service whose order priority is 4 will be shudown earlier than that
priority is 1.
something like that. I do not know if the dependence is the only way
to define the shudown/boot order.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Modifying systemd dependency tree during boot

[Andrei Borzenkov]

18.09.2015 17:58, Vivenzio Pagliari пишет:


However, these additionally added services are not started, when trying to
reach multi-user.target. After boot, I can see that the dependencies where
added correctly (e.g. doing "systemctl list-dependencies multi-user.target"
lists the newly created services as dependencies, but they remain inactive).



Transaction is computed when job is initially submitted. If you add new 
unit definition they won't automatically become part of transaction. It 
may be possible to cancel and resubmit it, it should then pick up units 
that are not yet started, but I am not sure how safe it is.



I suspect that something is wrong with this approach, but I do not
understand, what. My assumption is that during boot it is not supported to
fiddle with the "dependency graph" dynamically (i.e. before the boot reaches
its final unit). Is this correct?  If so, is there a rationale for that?

If this approach is wrong, what would be a better systemd-based approach of
solving such a problem of "starting SW that is available only later during
bootup"?



One possibility is to add newly detected units as dependency of common 
target and simply run "systemctl start this.target" as ExecPost after 
scan is complete.



-Vivenzio

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



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

[systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

Hi,

I find odd that systemd-firstboot skips root password init if
/etc/shadow exists because AFAICS this file is always part of a
minimal rootfs after being setup by an installer. Indeed it's
populated during package installation.

So I can't see a case where systemd-firstboot would prompt for a root password.

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Modifying systemd dependency tree during boot

[Vivenzio Pagliari]

Hi,

we face a problem with systemd when we attempt to dynamically add
dependencies to units during bootup. In other words, we want to add services
during boot (by means of some service that is run during boot) and via
"systemctl daemon-reload" we want to notify systemd about this new units and
start them (due to WantedBy dependencies of that newly created units to a
later to be reached target).

In principle, what we have is a system where part of the SW is not (yet)
available at the beginning of boot, when systemd builds up its dependency
tree. During boot, a unit will eventually mount a filesystem where
additional SW is located that shall be started on bootup. It would be
desirable to boot them each as separate systemd units (so we could use e.g.
process supervision etc.).

We tried to have a "scanner service" that comes up after the filesystem is
available. This service will scan a well-known directory in that filesystem
for SW to be started. The scanning procedure would result in the creation of
new service files executing that SW. These services should "hook in" via
[Install] section. When finished with service creation, this "scanner
service" would issue a "systemctl daemon-reload" to make the new
dependencies to the newly created units effective to systemd.


Here an (hopefully not too abstract) example:

1. The target used to "pull in" the dynamically created service units. I
   would use multi-user.target here.
2. The "scanner service", let's call it scanner.service that searches
   programs on the newly available filesystem.
3. The "scanned services"; in my test I made a template and the
   scanner.service will enable instantiations of that, depending on which SW
   is found on the filesystem.


scanner.service:
=
[Unit]
WantedBy = multi-user.target
Before = multi-user.target
RequiresMountsFor = /path/to/fs

[Service]
Type = oneshot
ExecStart = /usr/bin/scan-for-programs /path/to/fs

scanned@.service:
==
[Unit]
Description = Program %i from (late) filesystem
WantedBy = multi-user.target
Before= multi-user.target

[Service]
ExecStart = /path/to/fs/%i

*

The scan-for-programs utility would:
  a. for all found programs in /path/to/fs:
   enable scanned@program.service
  b. call systemctl daemon-reload to make the changes of step a. effective.

[Note: Actually, part a. can also be implemented as a generator which would
be called implicitly by the subsequent daemon-reload, but the end result
remains the same.]

However, these additionally added services are not started, when trying to
reach multi-user.target. After boot, I can see that the dependencies where
added correctly (e.g. doing "systemctl list-dependencies multi-user.target"
lists the newly created services as dependencies, but they remain inactive).

I suspect that something is wrong with this approach, but I do not
understand, what. My assumption is that during boot it is not supported to
fiddle with the "dependency graph" dynamically (i.e. before the boot reaches
its final unit). Is this correct?  If so, is there a rationale for that?

If this approach is wrong, what would be a better systemd-based approach of
solving such a problem of "starting SW that is available only later during
bootup"?

-Vivenzio

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

Re: [systemd-devel] Question related to cgroup and systemd

[Lennart Poettering]

On Fri, 18.09.15 14:45, Francis Moreau (francis.m...@gmail.com) wrote:

> > # systemd-run --slice=my-deep-slice.slice -p MemoryLimit=3G /bin/sleep 9
> >
> > It creates the specified slice, and places the new service in it, then
> > adds the process in it and sets the memory.limit_in_bytes= attribute
> > on the services' cgroup.
> >
> > Does this not work for you?
> 
> I dont think so:
> 
> $ cat ~/.config/systemd/user/myslice.slice

Controller access is not permitted for --user instances of systemd if
the legacy hierarchy is used, as that's not deemed safe by the kernel
guys.

If you use the unified hierarchy this is opened up, as it is safe
then.

systemd --system instances get access to controllers in any case.

> Which kernel version starts to support the new unified hierarchy ? Is
> there a doc which explain it ?

See NEWS.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel