Re: Shutdown behavior

Jay Burger <jay.burger@xxxxxxxxxxxxxx> · Mon, 13 Jan 2020 10:36:54 -0600

On 1/13/20 7:12 AM, systemd-devel-request@xxxxxxxxxxxxxxxxxxxxx wrote:
Send systemd-devel mailing list submissions to
	systemd-devel@xxxxxxxxxxxxxxxxxxxxx

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

You can reach the person managing the list at
	systemd-devel-owner@xxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxx>
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  Shutdown behavior
Message-ID: <20200113121800.338bc3c8@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

On Mon, 13 Jan 2020 11:32:37 +0100
Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Fr, 10.01.20 10:56, Jay Burger (jay.burger@xxxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx>
To: Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re:  reformat partition when device is in
	emergency mode
Message-ID:
	<CAAfyv37tq_YRCu6hR_3RLukcQFMR=wW9vKNRzMFc=efr4-n3Lg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 13, 2020 at 12:59 PM Ulrich Windl
<Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
Belisko Marek <marek.belisko@xxxxxxxxx> schrieb am 13.01.2020 um 10:19 in
Nachricht
<CAAfyv37bDCLvbAryW8Wqe5JT5n5Nbwyjik_YsE=eh2sGmLd9qA@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx>
To: <anoop.karollil@xxxxxxxxx>, "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject:  Antw: systemd.mount creating mount resource
	(What) for bind mounts
Message-ID: <5E1C4E8B020000A1000363E9@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

Anoop Karollil <anoop.karollil@xxxxxxxxx> schrieb am 07.01.2020 um 23:50
in
Nachricht
<CAGayzYuficuy5vzOpP2BfoxiUjMXAyrKn_HafVHO4GFLucvmuQ@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx>
To: "Lennart Poettering" <lennart@xxxxxxxxxxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject:  Antw: Re: Q: "Start request repeated too
	quickly." for dependency
Message-ID: <5E1C5B0E020000A1000363FE@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 13.01.2020 um 09:35
in
Nachricht <20200113083500.GA4921@gardel-login>:
On Mo, 13.01.20 09:20, Ulrich Windl (Ulrich.Windl@xxxxxx?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@xxxxxxxxxxxxxxxxxxxx>
To: <marek.belisko@xxxxxxxxx>, "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject:  Antw: reformat partition when device is in
	emergency mode
Message-ID: <5E1C5B8F020000A100036403@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

Belisko Marek <marek.belisko@xxxxxxxxx> schrieb am 13.01.2020 um 10:19 in
Nachricht
<CAAfyv37bDCLvbAryW8Wqe5JT5n5Nbwyjik_YsE=eh2sGmLd9qA@xxxxxxxxxxxxxx>:
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@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx>
To: "Lennart Poettering" <lennart@xxxxxxxxxxxxxx>
Cc: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject:  Antw: Re:  Shutdown behavior
Message-ID: <5E1C5E07020000A100036408@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 13.01.2020 um 11:32 in
Nachricht <20200113103237.GD5149@gardel-login>:
On Fr, 10.01.20 10:56, Jay Burger (jay.burger@xxxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxx>
To: "systemd-devel@xxxxxxxxxxxxxxxxxxxxx"
	<systemd-devel@xxxxxxxxxxxxxxxxxxxxx>,  "Reindl Harald"
	<h.reindl@xxxxxxxxxxxxx>
Subject:  Antw: Re: Antw: Re: Service fails to start
	with no log messages
Message-ID: <5E1C6075020000A100036411@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

Reindl Harald <h.reindl@xxxxxxxxxxxxx> schrieb am 13.01.2020 um 11:50 in
Nachricht <efdc18c8-7396-02fc-1780-9e089e203601@xxxxxxxxxxxxx>:

Am 13.01.20 um 11:45 schrieb Ulrich Windl:
Lennart Poettering <lennart@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
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
**********************************************

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