[systemd-devel] Shutdown behavior

Jay Burger jay.burger at us.fujitsu.com
Mon Jan 13 16:36:54 UTC 2020 

On 1/13/20 7:12 AM, systemd-devel-request at lists.freedesktop.org wrote:
> Send systemd-devel mailing list submissions to
> 	systemd-devel at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-2Ddevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=3kb3utxeE3bLsnPTvylgDdhJw1Lu_ypUHKgeOojrvA4&e=
> or, via email, send a message with subject or body 'help' to
> 	systemd-devel-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> 	systemd-devel-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of systemd-devel digest..."
>
>
> Today's Topics:
>
>     1. Re:  Shutdown behavior (Dave Howorth)
>     2. Re:  reformat partition when device is in emergency mode
>        (Belisko Marek)
>     3.  Antw: systemd.mount creating mount resource (What) for bind
>        mounts (Ulrich Windl)
>     4.  Antw: Re: Q: "Start request repeated too quickly." for
>        dependency (Ulrich Windl)
>     5.  Antw: reformat partition when device is in emergency mode
>        (Ulrich Windl)
>     6.  Antw: Re:  Shutdown behavior (Ulrich Windl)
>     7.  Antw: Re: Antw: Re: Service fails to start with no log
>        messages (Ulrich Windl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 13 Jan 2020 12:18:00 +0000
> From: Dave Howorth <systemd at howorth.org.uk>
> To: systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] Shutdown behavior
> Message-ID: <20200113121800.338bc3c8 at acer-suse.lan>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 13 Jan 2020 11:32:37 +0100
> Lennart Poettering <lennart at poettering.net> wrote:
>> On Fr, 10.01.20 10:56, Jay Burger (jay.burger at us.fujitsu.com) wrote:
>>
>>> I made the same type of change in the emergency_action() function
>>> in v232.
>>>
>>> Question 1: Would this be considered a problem with the design,
>>> needing an upstream fix? Or would this be considered a particular
>>> user issue, to be fixed with an isolated patch, like we have done?
>>> If the latter is the answer to this then would
>>> this be considered a legit fix for our purposes? Or is there a
>>> better way to handle this use case? I know fixing my user services
>>> to not fail on the shutdown would be preferable, but pulling teeth
>>> is not in my skillset.
>> Hmm, so what is the expected behaviour here? If one service requires a
>> reboot and another a poweroff, and one is triggered first and the
>> other second, then I can at least think of four policies that make
>> sense:
>>
>> 1. first requested always wins
>>
>> 2. last requested always wins
>>
>> 3. reboot is the positive outlook, and thus always wins
>>
>> 4. poweorff is the positive outlook, and thus always wins.
>>
>> Unless I am mistaken we currently implement policy 2. Which one would
>> you prefer? Can you make a good case why it would be better in the
>> general case?
>>
>> I have the suspicion we should just adopt the best possible policy
>> here and stick to it and not make things needlessly configurable. But
>> it's a matter of discussion which one that is...
Personally, I would think the initial shutdown should always be honored.
Unrealistic dramatized example: I have another emergency at Chernobyl
and need to power down my reactor. Oops some service failed
while in the shutdown state and the system just rebooted - china syndrome.

Maybe consider looking at it as an elevation type of thing.
Lowest level - reboot
higher level - halt
highest level - poweroff

I could see a useful option to allow an elevation of shutdown but not
a reduction and if a poweroff is the first trigger, period end of story.

> Surely this is application-dependent? I can conceive of applications
> that require reboot (or at least best efforts at it), and others that
> require shutdown.
>
> For the first, consider a system controlling something dangerous. If
> the system is forced down by some watchdog, it most likely should
> reboot and try again.
>
> For the second, consider a system whose power is supplied via a UPS and
> has just been informed the UPS is about to run out of power. Whatever
> it does, it's going down and its best policy is likely to
> shutdown/hibernate such that it can restart when power returns.
>
> Is there not a case to at least provide a hook so that some
> application-specific code can make the decision?
>
> But certainly, I think that a service failing during shutdown should
> not affect the outcome of that shutdown. Having some broken service
> decide whether or not I can shut my machine down is ridiculous.
>
>>> Question 2: I recently found a case where a poweroff shutdown was
>>> triggered while the system was in the "starting" state and a
>>> service failure occurred during the shutdown. In this case my logic
>>> change did not prevent the shutdown from changing to a reboot. This
>>> check of the manager_state found the state was still "starting" and
>>> the poweroff was again changed to a reboot. Is there a different
>>> logic path taken when in the starting state as opposed to the
>>> running state?
>> Not really, no.
I understand the during a shutdown a new "shutdown" pid 1 context
is created. If I am correct with that understanding shouldn't the manager
state always be "stopping" in that context? If that held true then my
patches would solve my issues and this conversation would be null and void.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-2Ddevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=3kb3utxeE3bLsnPTvylgDdhJw1Lu_ypUHKgeOojrvA4&e=
>
> ------------------------------
>
> Message: 2
> Date: Mon, 13 Jan 2020 13:20:03 +0100
> From: Belisko Marek <marek.belisko at gmail.com>
> To: Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de>
> Cc: "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>
> Subject: Re: [systemd-devel] reformat partition when device is in
> 	emergency mode
> Message-ID:
> 	<CAAfyv37tq_YRCu6hR_3RLukcQFMR=wW9vKNRzMFc=efr4-n3Lg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, Jan 13, 2020 at 12:59 PM Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
>>>>> Belisko Marek <marek.belisko at gmail.com> schrieb am 13.01.2020 um 10:19 in
>> Nachricht
>> <CAAfyv37bDCLvbAryW8Wqe5JT5n5Nbwyjik_YsE=eh2sGmLd9qA at mail.gmail.com>:
>>> Hi,
>>>
>>> I have embedded system which contains fat32 partition at the end of
>>> partition table. In case partition cannot be mounted (I'm using
>> Is that "immediately after the MBR" or "immidiately after the last
>> partition"?
> Partition can be after the last partition.
>>> fstab?generator to automatically mount partition) device will enter
>>> emergency mode. My idea is to check somehow in this mode that
>>> partition is corrupted and reformat it. Is there some simple way to
>>> detect that condition? Thanks for any pointers.
>> Is it related to the position of the partition in any way?
> Well not. I just wan to have device with kind of "self healing
> process" to avoid remote maintenance or so.
>>
>>> BR,
>>>
>>> marek
>>>
>>> ??
>>> as simple and primitive as possible
>>> ?????????????????????????????????????????????????
>>> Marek Belisko ? OPEN?NANDRA
>>> Freelance Developer
>>>
>>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>>> Tel: +421 915 052 184
>>> skype: marekwhite
>>> twitter: #opennandra
>>> web: https://urldefense.proofpoint.com/v2/url?u=http-3A__open-3Fnandra.com&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=1PhSceLTbp6zyy6bR3HW_-MRESHxev_fa_1MHLK6GVA&e=
>>> _______________________________________________
>>> systemd?devel mailing list
>>> systemd?devel at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-3Fdevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=ywrg51fnRwXSaNtGrOebtpqmDpuT8UufuD7ZXyywohE&e=
>>
>>
> Thanks,
>
> marek
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 13 Jan 2020 12:03:39 +0100
> From: "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
> To: <anoop.karollil at gmail.com>, "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>
> Subject: [systemd-devel] Antw: systemd.mount creating mount resource
> 	(What) for bind mounts
> Message-ID: <5E1C4E8B020000A1000363E9 at gwsmtp.uni-regensburg.de>
> Content-Type: text/plain; charset=UTF-8
>
>>>> Anoop Karollil <anoop.karollil at gmail.com> schrieb am 07.01.2020 um 23:50
> in
> Nachricht
> <CAGayzYuficuy5vzOpP2BfoxiUjMXAyrKn_HafVHO4GFLucvmuQ at mail.gmail.com>:
>> Hello,
>>
>> I see that a mount unit with `Options=bind` set creates the resource
>> to be mounted, specified by `What`, in addition to the mount point,
>> specified by `Where`, when they don't exist.
> Personally I think a mount operation should not create any missing directory,
> because a missing directory indicates some type of configuration problem that
> should be solved by hand.
>
>> Manual page at
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.freedesktop.org_software_systemd_man_systemd.mount.html&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=p_qXT1phhAOyBavlr6lpcZyWSKPhGLKvNeT2VJ-8fio&e=
>> mentions that the mount point will be created if it doesn't exist for
>> `Where`. But doesn't mention that this applies to `What` too in the
>> case of bind mounts. I think this is the change that added this
>> behaviour:
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_systemd_systemd_commit_2b583ce6576d4a074ce6f1570b3e60b65c6&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=DUDdWtmMGCES9snB_FWNLZe-1OlHgAxPjC95jx_AgNQ&e=
>
>> 4ae7d#diff?df9fd757e73e7f659350e8a76994d42f.
>> I found it a little surprising, especially since the behaviour is
>> described for `Where` but not for `What`. So maybe its good to mention
>> that in the systemd.mount man page under `What`?
>>
>> Thanks,
>> Anoop
>> _______________________________________________
>> systemd?devel mailing list
>> systemd?devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-3Fdevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=ywrg51fnRwXSaNtGrOebtpqmDpuT8UufuD7ZXyywohE&e=
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 13 Jan 2020 12:57:02 +0100
> From: "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
> To: "Lennart Poettering" <lennart at poettering.net>
> Cc: "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>
> Subject: [systemd-devel] Antw: Re: Q: "Start request repeated too
> 	quickly." for dependency
> Message-ID: <5E1C5B0E020000A1000363FE at gwsmtp.uni-regensburg.de>
> Content-Type: text/plain; charset=UTF-8
>
>>>> Lennart Poettering <lennart at poettering.net> schrieb am 13.01.2020 um 09:35
> in
> Nachricht <20200113083500.GA4921 at gardel-login>:
>> On Mo, 13.01.20 09:20, Ulrich Windl (Ulrich.Windl at rz.uni?regensburg.de)
> wrote:
>>> Hi!
>>>
>>> I have a oneshot service (say "G") that creates some files if missing, and
>> some other sevices (say A B C) that have a dependency on G.
>>> Now if services A B C start quickly in succession, I get a failure because
> G
>> fails to start (as it seems).
>>> The log says "G: Start request repeated too quickly.". (Actual start
>> requests aren't logged, however, or I could not find those)
>>> Is there any setting to tell systemd that it's OK to start the oneshot
>> service quickly?
>>
>> StartLimitIntervalSec= + StartLimitBurst= in the [Unit] section
>> configure how often a service can be started within a specific
>> time?frame. See systemd.unit(5) for more info.
> OK, thanks!
>
>> If you want G to start only once for all three, then just set
>> RemainAfterExit=yes in G, which has the effect that the oneshot
>> service stays active after it completed so that it is only started
>> once for all three instead of three times, once for each.
> No, I want it to be started each time (the service handles concurrency
> correctly), because there could be weeks between start of A, B and C, also (and
> lot of things could have changed since G was started the last time).
>
> Regards,
> Ulrich
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 13 Jan 2020 12:59:11 +0100
> From: "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
> To: <marek.belisko at gmail.com>, "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>
> Subject: [systemd-devel] Antw: reformat partition when device is in
> 	emergency mode
> Message-ID: <5E1C5B8F020000A100036403 at gwsmtp.uni-regensburg.de>
> Content-Type: text/plain; charset=UTF-8
>
>>>> Belisko Marek <marek.belisko at gmail.com> schrieb am 13.01.2020 um 10:19 in
> Nachricht
> <CAAfyv37bDCLvbAryW8Wqe5JT5n5Nbwyjik_YsE=eh2sGmLd9qA at mail.gmail.com>:
>> Hi,
>>
>> I have embedded system which contains fat32 partition at the end of
>> partition table. In case partition cannot be mounted (I'm using
> Is that "immediately after the MBR" or "immidiately after the last
> partition"?
>
>> fstab?generator to automatically mount partition) device will enter
>> emergency mode. My idea is to check somehow in this mode that
>> partition is corrupted and reformat it. Is there some simple way to
>> detect that condition? Thanks for any pointers.
> Is it related to the position of the partition in any way?
>
>
>> BR,
>>
>> marek
>>
>> ??
>> as simple and primitive as possible
>> ?????????????????????????????????????????????????
>> Marek Belisko ? OPEN?NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: https://urldefense.proofpoint.com/v2/url?u=http-3A__open-3Fnandra.com&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=1PhSceLTbp6zyy6bR3HW_-MRESHxev_fa_1MHLK6GVA&e=
>> _______________________________________________
>> systemd?devel mailing list
>> systemd?devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-3Fdevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=ywrg51fnRwXSaNtGrOebtpqmDpuT8UufuD7ZXyywohE&e=
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 13 Jan 2020 13:09:43 +0100
> From: "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
> To: "Lennart Poettering" <lennart at poettering.net>
> Cc: "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>
> Subject: [systemd-devel] Antw: Re:  Shutdown behavior
> Message-ID: <5E1C5E07020000A100036408 at gwsmtp.uni-regensburg.de>
> Content-Type: text/plain; charset=US-ASCII
>
>>>> Lennart Poettering <lennart at poettering.net> schrieb am 13.01.2020 um 11:32 in
> Nachricht <20200113103237.GD5149 at gardel-login>:
>> On Fr, 10.01.20 10:56, Jay Burger (jay.burger at us.fujitsu.com) wrote:
>>
>>> I made the same type of change in the emergency_action() function in v232.
>>>
>>> Question 1: Would this be considered a problem with the design, needing an
>>> upstream fix? Or would this be considered a particular user issue, to be
>> fixed with
>>> an isolated patch, like we have done? If the latter is the answer to this
>>> then would
>>> this be considered a legit fix for our purposes? Or is there a better way to
>> handle
>>> this use case? I know fixing my user services to not fail on the shutdown
>> would be
>>> preferable, but pulling teeth is not in my skillset.
>> Hmm, so what is the expected behaviour here? If one service requires a
>> reboot and another a poweroff, and one is triggered first and the
>> other second, then I can at least think of four policies that make
>> sense:
>>
>> 1. first requested always wins
>>
>> 2. last requested always wins
>>
>> 3. reboot is the positive outlook, and thus always wins
>>
>> 4. poweorff is the positive outlook, and thus always wins.
> 5. The one that completes first, wins ;-)
>
>> Unless I am mistaken we currently implement policy 2. Which one would
>> you prefer? Can you make a good case why it would be better in the
>> general case?
> Essentially that i 5) if it ever succeds ;-)
>
>> I have the suspicion we should just adopt the best possible policy
>> here and stick to it and not make things needlessly configurable. But
>> it's a matter of discussion which one that is...
>>
>>> Question 2: I recently found a case where a poweroff shutdown was triggered
>>> while the system was in the "starting" state and a service failure occurred
>> during
>>> the shutdown. In this case my logic change did not prevent the shutdown from
>>> changing to a reboot. This check of the manager_state found the state was
>> still
>>> "starting" and the poweroff was again changed to a reboot. Is there a
>>> different logic
>>> path taken when in the starting state as opposed to the running state?
> In older SUSE Linux (pre-systemd), the first Ctrl+Alr+Del sometimes hung, but a second one succeeded then.
> I can't tell whether the second trigger just unblocked the first restart request, or whether the second restart request just "overtook" the first one, however...
> But still, the first one to complete, wins...
>
> Regards,
> Ulrich
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 13 Jan 2020 13:20:05 +0100
> From: "Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
> To: "systemd-devel at lists.freedesktop.org"
> 	<systemd-devel at lists.freedesktop.org>,  "Reindl Harald"
> 	<h.reindl at thelounge.net>
> Subject: [systemd-devel] Antw: Re: Antw: Re: Service fails to start
> 	with no log messages
> Message-ID: <5E1C6075020000A100036411 at gwsmtp.uni-regensburg.de>
> Content-Type: text/plain; charset=UTF-8
>
>>>> Reindl Harald <h.reindl at thelounge.net> schrieb am 13.01.2020 um 11:50 in
> Nachricht <efdc18c8-7396-02fc-1780-9e089e203601 at thelounge.net>:
>
>> Am 13.01.20 um 11:45 schrieb Ulrich Windl:
>>>>>> Lennart Poettering <lennart at poettering.net> schrieb am 07.01.2020 um
> 14:27
>>>> Such a concept does not exist. I mean your service is a system
>>>> service itself, so what is that even supposed to mean that the service
>>>> shall start 5s after it already started? But even if you mean to say
>>>> "5s after all other services", then think how that falls apart if you
>>>> have multiple services declaring that.
>>> Maybe explain when systemd considers a service as started, pointing out
>> wrong
>>> implementations.
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.freedesktop.org_software_systemd_man_systemd.service.html&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=aDK60sIwUCTffL0PY_HbavRvEzv7TxDbCUBrQsYFV1Y&e=
>>
>> CTRL+F Type=
>>
>> for network it strongly depends on *how* your network is setup
>> (NetworkManager, systemd?networkd, legacy /etc/nint.d/network or even a
>> own implementation)
>>
>> with the implementation below you can relieable oder anything after
>> "network?up.service" or "network?online.target"
> But isn't it simply because none of the ExecStarts is executing in background?
> The interesting part is DHCP which can complete quickly or not at all (e.g.
> configuration error)...
>
> ...
>> ExecStart=/usr/sbin/iptables?legacy?restore ?w 5 /etc/sysconfig/iptables
> ...
>> ExecStart=?/usr/sbin/sysctl ?q ??load=/etc/sysctl?conntrack.conf
> ...
>> ExecStart=?/usr/sbin/ethtool ?G eth0 rx?mini 0
> ...
>> ExecStart=/usr/sbin/ip addr add 10.0.0.102/255.255.255.0 broadcast
> 10.0.0.255 dev eth0
> ...
>> ExecStart=/usr/sbin/ip link set dev eth0 multicast off up
> ...
>> ExecStart=/usr/sbin/ip route add default via 10.0.0.1
> ...
>> ExecStart=?/usr/sbin/sysctl ?e ?p ?q
> ...
>
>
> Regards,
> Ulrich
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_systemd-2Ddevel&d=DwICAg&c=09aR81AqZjK9FqV5BSCPBw&r=eZr6O-2nRMo2rKM8r3uAkikeHaPdKjgl8fabX-Hs-ts&m=mta6UzqBrGnnB9FL0KCZXhSAre6pMLiXHGqBvJTxXoc&s=3kb3utxeE3bLsnPTvylgDdhJw1Lu_ypUHKgeOojrvA4&e=
>
>
> ------------------------------
>
> End of systemd-devel Digest, Vol 117, Issue 21
> **********************************************

More information about the systemd-devel mailing list