Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

[Francis Moreau]

Hello Michael,

On Wed, May 25, 2016 at 11:08 PM, Michael Biebl  wrote:
> Hm, I've already given you the answer on IRC, so I'm not sure why you
> ask them again.
>

Indee and thank you for that.

But you also told me that /etc/init.d/rc0.d isn't supported by Debian,
and my question is about this runlevel in particular.

> The K symlinks determine whether a service needs an explicit stop
> request on shutdown (i.e. Conflicts/Before: shutdown.target).
>
> That's exactly how sysvinit also worked. If there was a K symlink in
> rc0 and rc6, the service is stopped via /etc/init.d/foo stop.
>
> Not sure what's unclear about that.
>

So let's take an example. Please note that I'm really not sure what's
the expected behavior of sysvinit itself, and finding some
documentation/specifications about that is pretty hard.

I want my "foo" sysv service to be executed at shutdown. So I install
the following symlink:

  /etc/init.d/rc0.d/S50foo

The sysv-generator will add a "WantedBy/Before=poweroff.target" to the foo stub.

The chunk of code in my initial post adds support of the following symlink:

 /etc/init.d/rc0.d/K50foo

It adds "Conflicts/Before=shutdown.target" to foo stub.

So if both symlinks are installed (I don't see why this is useful and
hence why the generator has some code to handle that), foo stub has
the following constraints:

WantedBy/Before=poweroff.target
Conflicts/Before=shutdown.target

and to me that's not useful since in my understand it's equivalent to a nop.

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Andrei Borzenkov]

25.05.2016 18:21, Lennart Poettering пишет:
> 
> What I don't understand in your case though is why you use an explicit
> mount for /opt anyway... The nice thing about btrfs is that subvolumes
> behave pretty much like normal directories that just have a bit more
> features. And because of that there's no need to mount them
> explicitly. Just create a subvolume normally and everything should be
> good, it will then be available at the right place the instant the
> parent subvolume is mounted too.
> 


As soon as you revert to different snapshot (by pointing root to it) you
lose all subvolumes that are referenced from your initial snapshot. And
ability to quickly revert to recover from serious failure is one of
btrfs selling points. Or in other direction - you clone your root, apply
updates to it and reboot into newly created clone.

So in practice your suggestion does not work (except in very trivial
configuration) and every volume must be separate mount point to make
sure it is universally available.


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

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Michael Hirmke]

Hi Mantas,

>In other words, mixing up OS file descriptors and Perl file handles?

exactly 8-<

>D-Bus can only send and receive raw FDs; Net::DBus doesn't know what kind
>of handle it's supposed to be, so you need to either create one manually,
>or just work with the FD directly (I think the relevant function is
>sysclose()?...)

For the moment I create a handle manually and also open it manually.

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

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

[Michael Biebl]

And if a service does not have an explicit stop on shutdown/reboot,
the processes are killed in a final killing spree where there are not
ordering guarantees.


2016-05-25 23:08 GMT+02:00 Michael Biebl :
> Hm, I've already given you the answer on IRC, so I'm not sure why you
> ask them again.
>
> The K symlinks determine whether a service needs an explicit stop
> request on shutdown (i.e. Conflicts/Before: shutdown.target).
>
> That's exactly how sysvinit also worked. If there was a K symlink in
> rc0 and rc6, the service is stopped via /etc/init.d/foo stop.
>
> Not sure what's unclear about that.
>
> 2016-05-25 22:12 GMT+02:00 Francis Moreau :
>> Hello,
>>
>> I'm starring at a chunk of code of the sysv-generator (shown below)
>> for some while now and I still can't see its purpose.
>>
>> Here's the code taken from src/sysv-generator/sysv-generator.c:
>>
>> static int set_dependencies_from_rcnd(const LookupPaths *lp, Hashmap
>> *all_services) {
>>
>> [...]
>>
>> } else if (de->d_name[0] == 'K' &&
>>(rcnd_table[i].type ==
>> RUNLEVEL_DOWN)) {
>>
>>
>> set_ensure_allocated(_services, NULL);
>> set_put(shutdown_services, service);
>> }
>> [...]
>>
>> For simplicity sake, I removed the sanity checkings.
>>
>> If I parsed it correctly, it handles symlinks in rc[06].d/ such as:
>> /etc/init.d/rc0.d/K50foo.
>>
>> In this case this adds a "Conflicts=shutdown.target" and
>> "Before=shutdown.target" to the foo stub service.
>>
>> What exactly the point to do that specially ? which sysvinit behavior
>> systemd is try to mimic ?
>>
>> Thanks.
>> --
>> Francis
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?



-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

[Michael Biebl]

Hm, I've already given you the answer on IRC, so I'm not sure why you
ask them again.

The K symlinks determine whether a service needs an explicit stop
request on shutdown (i.e. Conflicts/Before: shutdown.target).

That's exactly how sysvinit also worked. If there was a K symlink in
rc0 and rc6, the service is stopped via /etc/init.d/foo stop.

Not sure what's unclear about that.

2016-05-25 22:12 GMT+02:00 Francis Moreau :
> Hello,
>
> I'm starring at a chunk of code of the sysv-generator (shown below)
> for some while now and I still can't see its purpose.
>
> Here's the code taken from src/sysv-generator/sysv-generator.c:
>
> static int set_dependencies_from_rcnd(const LookupPaths *lp, Hashmap
> *all_services) {
>
> [...]
>
> } else if (de->d_name[0] == 'K' &&
>(rcnd_table[i].type ==
> RUNLEVEL_DOWN)) {
>
>
> set_ensure_allocated(_services, NULL);
> set_put(shutdown_services, service);
> }
> [...]
>
> For simplicity sake, I removed the sanity checkings.
>
> If I parsed it correctly, it handles symlinks in rc[06].d/ such as:
> /etc/init.d/rc0.d/K50foo.
>
> In this case this adds a "Conflicts=shutdown.target" and
> "Before=shutdown.target" to the foo stub service.
>
> What exactly the point to do that specially ? which sysvinit behavior
> systemd is try to mimic ?
>
> Thanks.
> --
> Francis
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Mantas Mikulėnas]

In other words, mixing up OS file descriptors and Perl file handles?

D-Bus can only send and receive raw FDs; Net::DBus doesn't know what kind
of handle it's supposed to be, so you need to either create one manually,
or just work with the FD directly (I think the relevant function is
sysclose()?...)

On Wed, May 25, 2016, 22:57 Michael Hirmke  wrote:

> Hi again,
>
> [...]
> >>> - I am not able to close the file descriptor in the pre block of the
> >>>   signal handler. Whenever I try, I get an error, that the descriptor
> >>>   is closed.
>
> >>This suggests something else closed the fd for you?
>
> >Yes, but who or what might that be?
> >As I wrote above - at the moment I'm the only one using the system and I
> >have no idea, what component might fiddle with my file descriptors.
> >Do you have any hint, how I could find that out / debug it?
>
> >And there is the fact, that the lock is still in the list of inhibitors.
> >As far as I understand the docs, the entry should be gone when the fd is
> >closed.
>
> forget about that question - I have never asked it 8-((
>
> It was a really stupid error in my perl code - the file descriptor was
> never open. I got a file handle, but didn't realize that I have to open
> it myself. Now it works as expected.
>
> >>Lennart
>
>
> Bye.
> Michael.
> --
> Michael Hirmke
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sysv-generator weirdness for shutdown runlevels

[Francis Moreau]

Hello,

I'm starring at a chunk of code of the sysv-generator (shown below)
for some while now and I still can't see its purpose.

Here's the code taken from src/sysv-generator/sysv-generator.c:

static int set_dependencies_from_rcnd(const LookupPaths *lp, Hashmap
*all_services) {

[...]

} else if (de->d_name[0] == 'K' &&
   (rcnd_table[i].type ==
RUNLEVEL_DOWN)) {


set_ensure_allocated(_services, NULL);
set_put(shutdown_services, service);
}
[...]

For simplicity sake, I removed the sanity checkings.

If I parsed it correctly, it handles symlinks in rc[06].d/ such as:
/etc/init.d/rc0.d/K50foo.

In this case this adds a "Conflicts=shutdown.target" and
"Before=shutdown.target" to the foo stub service.

What exactly the point to do that specially ? which sysvinit behavior
systemd is try to mimic ?

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

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Michael Hirmke]

Hi again,

[...]
>>> - I am not able to close the file descriptor in the pre block of the
>>>   signal handler. Whenever I try, I get an error, that the descriptor
>>>   is closed.

>>This suggests something else closed the fd for you?

>Yes, but who or what might that be?
>As I wrote above - at the moment I'm the only one using the system and I
>have no idea, what component might fiddle with my file descriptors.
>Do you have any hint, how I could find that out / debug it?

>And there is the fact, that the lock is still in the list of inhibitors.
>As far as I understand the docs, the entry should be gone when the fd is
>closed.

forget about that question - I have never asked it 8-((

It was a really stupid error in my perl code - the file descriptor was
never open. I got a file handle, but didn't realize that I have to open
it myself. Now it works as expected.

>>Lennart


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

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Michael Hirmke]

Hi Lennart,

thx for your answer!

[...]
>Being just advisory means that a user can shut down the system even if
>a lock is taken, however, the lock is tracked and the expectation is
>that the DE of your choice will still show them first, and ask for
>confirmation to ignore them before you actually use your powers to
>override them. GNOME does this, but I am not sure if your DE does it.

Sorry, I forgot to add information regarding my environment.
I use openSuSE Leap 42.1 with a Plasma 5 desktop.
And at the moment my tests are restricted to run my script and then send
the system to sleep myself - so no other user is involved for the
moment.

>"systemctl poweroff" will show these locks in a similar way too, but
>not for the root user.

>> - I am not able to close the file descriptor in the pre block of the
>>   signal handler. Whenever I try, I get an error, that the descriptor
>>   is closed.

>This suggests something else closed the fd for you?

Yes, but who or what might that be?
As I wrote above - at the moment I'm the only one using the system and I
have no idea, what component might fiddle with my file descriptors.
Do you have any hint, how I could find that out / debug it?

And there is the fact, that the lock is still in the list of inhibitors.
As far as I understand the docs, the entry should be gone when the fd is
closed.

>Lennart


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

On 05/25/2016 03:22 PM, Lennart Poettering wrote:


On Wed, 25.05.16 10:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:




You will always risk ending up with a race condition if you place your type
units outside the official directories.

/etc/systemd/system/*  ( Administrators )
/run/systemd/system/* ( Temporary )
/usr/lib/systemd/system/* ( Vendors )

Arguably the support running/loading type unit files outside the above
directories should be altogether removed or at least a warning issues since
this is bound to create administrative mess ( as was apparent when vendor
did something like that with legacy sys v init ).

I don#t really agree I must say.


It's classic ( sys v ) init brokenness in which vendors placed their 
stuff in opt ( or elsewhere ) which more often than not was a) on 
separated partition b) on separated sub-volume c) on a network drive ( 
nfs and the likes ) then symbolic linked ( through install script ( 
which usually do more harm than good since such scripts assumptions are 
way off with the environment and infrastructure policy's ) to one of the 
classic init.d directories which led to the exactly same racy condition 
( if legacy sysv initscript and or type units depend on something else ) 
and brokenness as he's experiencing here.


What's the use case for placing type unit files outside those 
directories and supporting following symlinks to them?


Why dont you always want to require type unit files to be placed in 
those directories to prevent things like he's experiencing and I 
mentioned above from happening?


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

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

[Lennart Poettering]

On Wed, 25.05.16 12:17, Michael Hirmke (m...@mike.franken.de) wrote:

> Hi *,
> 
> I'd like to write a script, which can listen to the PepareForSleep
> signal from systemd-logind. When it catches the signal, it should do a
> few things in the context of the user. While doing this, it should
> inhibit the sleep process. It gets started as autostart script in KDE.
> For this purpose I use perl and the module Net::DBus.
> Actually I am able to connect to the bus, attach to the appropriate
> signal and run something, when getting the signal.
> 
> But:
> 
> - I only can take delay locks. Whenever I try to take a *blocking* lock,
>   nothing happens, as if it is completely ignored. I don't get any
>   error message, though.
>   When using *delay* locks and the maximum inhibition time has been
>   exceeded, I get
> 
>   "systemd-logind: Delay lock is active (UID /, PID
>   /dbus_logind) but inhibitor timeout is reached."
> 
>   So it seems to work in this case, but why not with blocking locks?

Note that for the root user and for normal users with access to the
local console blocking locks are advisory only. Also, locks taken by
programs running as the same user as the one attempting to shut down
are advisory only too. This policy may be configured differently via
PolicyKit however. Since most people probably don#t do this this boils
down to inhibitors being advisory-only for almost everybody, except if
you are on a true multi-user system, where locks taken by a user A are
non-advisory (i.e. "mandatory") for all users B with A != B if B does
not have access to the local console.

Being just advisory means that a user can shut down the system even if
a lock is taken, however, the lock is tracked and the expectation is
that the DE of your choice will still show them first, and ask for
confirmation to ignore them before you actually use your powers to
override them. GNOME does this, but I am not sure if your DE does it.

"systemctl poweroff" will show these locks in a similar way too, but
not for the root user.

> - I am not able to close the file descriptor in the pre block of the
>   signal handler. Whenever I try, I get an error, that the descriptor
>   is closed.

This suggests something else closed the fd for you?

Lennart

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Lennart Poettering]

On Wed, 25.05.16 10:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> 
> 
> You will always risk ending up with a race condition if you place your type
> units outside the official directories.
> 
> /etc/systemd/system/*  ( Administrators )
> /run/systemd/system/* ( Temporary )
> /usr/lib/systemd/system/* ( Vendors )
> 
> Arguably the support running/loading type unit files outside the above
> directories should be altogether removed or at least a warning issues since
> this is bound to create administrative mess ( as was apparent when vendor
> did something like that with legacy sys v init ).

I don#t really agree I must say.

And it is not racy at all, as long as the paths you use are available
from early boot on, and hence not on a mount point that is not
available right-away.

Lennart

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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Lennart Poettering]

On Tue, 24.05.16 22:21, Rashmi Ranjan Mohanty 
(rashmiranjan.moha...@microfocus.com) wrote:

> Hi,
> 
> Our whole software is installed into /opt. So the systemd unit files
> are also there in /opt and the units are enabled to start on boot
> using the command "systemctl enable  file>". But if the /opt is a subvolume on a btrfs file system, when
> the system boots, sometimes (or on some systems) systemd tries to
> load the units even before /opt subvolume is mounted. As a result it
> does not find the unit file and fails to load the unit. Once
> everything is mounted, if we try to start the units manually,
> everything works fine. Here is the snippet of the error

This is simply not supported. Services to be started at boot must be
accessible when systemd transitions from the initrd into the host
system. Thus, if you place them in /opt, and make /opt an independent
mount, then systemd won't cover this. Unit files are really like
/etc/fstab itself, they cannot be split out into a different FS
mounted later. (this is because we want to determine the initial
transaction only once, at very early boot, and we can do so only if we
actually know everything to start)

(a hackish way around this could be to issue "systemctl daemon-reload"
half-way during the boot process when the new mount point showed up,
but that's really just a gross hack and comes with other problems)

What I don't understand in your case though is why you use an explicit
mount for /opt anyway... The nice thing about btrfs is that subvolumes
behave pretty much like normal directories that just have a bit more
features. And because of that there's no need to mount them
explicitly. Just create a subvolume normally and everything should be
good, it will then be available at the right place the instant the
parent subvolume is mounted too.

Lennart

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

Re: [systemd-devel] Shutdown a specific service in systemd shutdown

[Michael Chapman]

On Thu, 19 May 2016, Bao Nguyen wrote:

Hi everyone,

When the system is shutdown, systemd will terminate all services in
parallel manner, could you let me know if there is any ways to tell systemd
to shutdown a specific service first, then shutdown all remaining services?


Hello,

I haven't tested it, but as far as I know all you need to do is ensure 
your special service is After=multi-user.target, i.e.:


  [Unit]
  Description=Some service that must be started late / stopped early
  After=multi-user.target

  [Service]
  # ...

  [Install]
  WantedBy=multi-user.target

A target unit is automatically After= all the units that it Wants=, 
Requires=, etc., but this automatic dependency is *not* added if that 
would create a dependency loop.


So at shutdown systemd knows it needs to stop all services and targets. 
Because your special service is After=multi-user.target, and 
multi-user.target is After= all *other* normal services, everything gets 
ordered correctly: your service is stopped first, then multi-user.target 
is stopped, then all the other services are stopped.


Now, this isn't the *cleanest* solution -- you really want to be specific 
in your service dependencies rather than depending upon a whole target's 
worth of services, and there's always the chance that multi-user.target 
might be stopped some other way before shutdown -- but it does seem as if 
it goes some way to solving your problem.


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

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Jóhann B . Guðmundsson]

You will always risk ending up with a race condition if you place your 
type units outside the official directories.


/etc/systemd/system/*  ( Administrators )
/run/systemd/system/* ( Temporary )
/usr/lib/systemd/system/* ( Vendors )

Arguably the support running/loading type unit files outside the above 
directories should be altogether removed or at least a warning issues 
since this is bound to create administrative mess ( as was apparent when 
vendor did something like that with legacy sys v init ).


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

Re: [systemd-devel] Shutdown a specific service in systemd shutdown

[Andrei Borzenkov]

On Wed, May 25, 2016 at 9:59 AM, Bao Nguyen  wrote:
> Hi,
>
> Thanks for all your comments.
>
> How do you think if we create a custom target to include all remaining
> services, then add this target to the dependency After= of the specific
> services. This way can make the specific stop before the services in the
> target when the system shutdowns?
>

Keyword here is "all remaining services". If you have fixed number of
services that are known in advance then yes, you can of course
configure arbitrary dependencies between them and order them exactly
as you need.

What is asked at regular interval is doing the same for arbitrary
number of services unknown in advance. This is not possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shutdown a specific service in systemd shutdown

[Bao Nguyen]

Hi,

Thanks for all your comments.

How do you think if we create a custom target to include all remaining
services, then add this target to the dependency After= of the specific
services. This way can make the specific stop before the services in the
target when the system shutdowns?

Thanks,
BRs,
Natsu

On Mon, May 23, 2016 at 3:54 PM, Lennart Poettering 
wrote:

> On Sun, 22.05.16 15:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > 19.05.2016 11:57, Martin Pitt пишет:
> > > Hello Bao,
> > >
> > > Bao Nguyen [2016-05-19 15:52 +0700]:
> > >> When the system is shutdown, systemd will terminate all services in
> > >> parallel manner, could you let me know if there is any ways to tell
> systemd
> > >> to shutdown a specific service first, then shutdown all remaining
> services?
> > >
> > > The concept of "first"/"last" has no well-defined meaning in any
> > > non-serial init systems (not even SysV init with insserv, only with
> > > classic SysV init with manually set priorities). I've heard requests
> > > like "but this needs to be started as the last thing" a lot in the
> > > recent years, and there's no way all the services can simultaneously
> > > be "last" :-)
> >
> > Well, the very good example of service that has to be started/stopped
> > before/after anything else is splash screen (plymouth or anything). It
> > really must appear as soon as user hit ENTER in "systemctl reboot". As
> > it stands now, there is no way to ensure it.
>
> Well, shutting down is asynchronous anyway. Hence, yes, it should be shown
> pretty quickly, but strict, enforced ordering here is not necessary.
>
> This is a different story if you want a smooth transition between some
> graphical login thingy (such as gdm) and the ply shutdown screen, but
> in that case there should really be a direct hand-over so that gdm
> only releases the DRM when it knows that py has taken over. Such logic
> needs to happen directly between ply and gdm however, and in fact does
> already.
>
> > > You should put sufficient After= properties into your service, so that
> > > it gets started after and stopped before the ones you specify.
> >
> > Do you suggest adding dependency on plymouth to *every* service?
>
> No, I'd suggest that you are using the wrong tool here and should use
> something else...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel