[systemd-devel] Antw: Re: Antw: [EXT] emergency shutdown, don't wait for timeouts

[Reindl Harald]

Am 07.01.21 um 09:15 schrieb Ulrich Windl:
>>>> Chris Murphy <lists at colorremedies.com> schrieb am 06.01.2021 um 03:02 in
> Nachricht
> <CAJCQCtTu23a3W56tfDDy061mZvBiXRUaAhuue=W0A6CSwM44Yw at mail.gmail.com>:
>> On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi <phill at thesusis.net> wrote:
>> This is too long for a desktop or laptop use case. It should be around
>> 15‑20 seconds. It's completely reasonable for users to reach for the
>> power button and force it off by 30 seconds.
> 
> Have you ever tried shutting down multiple virtual machines having disks on a
> slow medium?

where is the problem?

my machines shutdown within a few seconds as lonmg there is no 
systemd-unit hanging around for minutes without a good reason

everytime in the past 10 years when shutown took more than 5 seconds it 
was some systemd-unit doing meditation

happens regulary when i reboot our HP microserver on CentOS7 with RAID10 
and LUKS on top of it - manually unlocked and mounted with a login 
script to enter the password

and no that never finishes, it always runs in a timeout, no matter how 
long the timeout is while my shutdown alias is closing LUKS and 
unmounting the filesystem *before* issue "reboot" or "poweroff"

[root at nfs:~]$ which reboot
alias reboot='/usr/bin/bash /usr/local/bin/storage-services.sh stop; 
/usr/bin/systemctl reboot'

>> Fedora Workstation Working Group is tracking an issue expressly to get
>> to around 20 seconds (or better).
>> https://pagure.io/fedora‑workstation/issue/163
>>
>> It is a given there will be some kind of state or data loss by just
>> forcing a shutdown. I think what we need is the console, revealed by
>> ESC, needs to contain sufficient information on what and why the
>> reboot/shutdown is being held back. So that we can figure out why
>> those processes aren't terminating fast enough and get them fixed.
> 
> There may be bugs, and there may be processes that simply take time.

yes, and in case the stuff with the bugs is delaying important services 
which takes longer at it's own to even begin to stop you havbe a problem

for a unit which takes time for good reasons you can configure that in 
the unit itself, no reason that everything waits for minutes

>> A journaled file system should just do log replay at the next mount
>> and the file system itself will be fine. Fine means consistent. But
> 
> That's nonsense: I'd prefer to wait and NOT lose data.

if the battery goes empty you will lose data for sure

often the calculation how long the UPS can hold power isn't true when 
batteries get older and at the point a emergency shutdown is needed you 
have less time than expected