Re: [systemd-devel] Help required for configuring a blocking service during shutdown

[Henning Moll]

Hi Mantas,

 

thank you for your helpful input. My main error was probably that I was accidentially using "TimeoutStartSec" instead of "TimeoutStopSec". My current implementation now looks like this:

 


[Unit]
Description=Wait for backups
After=ssh.service remote-fs.target rsyslog.service
Requires=ssh.service remote-fs.target rsyslog.service

 

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_wait start
ExecStop=/usr/local/bin/backup_wait stop
TimeoutStopSec=1d
RemainAfterExit=true

 

[Install]
WantedBy=multi-user.target

 



I am not really sure about the "Requires" and the "WantedBy". I also added a dependency to rsyslog.service, because without that, logger attempts in "backup_wait" are not written to the syslog. Is there a better way to achieve this?

 

Now I try to integrate plymouth. I had a look to /lib/systemd/system/casper.service, which is used in a "live cd" setup to show to "Please remove the installation medium" message.

 

For me it looks like this service is using a different strategy? I understand the current approach of my service: "shutdown in the opposit order than startup". But in casper there is a "After=shutdown.target ...". Is this target part of the boot procedure?

 

Maybe you can help me in transfering the plymouth bits of the casper service into my service? (Just adding casper.services' After dependencies did not work...)

 

Best regards

Henning

 

Gesendet: Montag, 29. August 2022 um 14:01 Uhr
Von: "Mantas Mikulėnas" 
An: "Henning Moll" 
Cc: "Systemd" 
Betreff: Re: [systemd-devel] Help required for configuring a blocking service during shutdown




On Mon, Aug 29, 2022 at 1:31 PM Henning Moll  wrote:




Hi,

 

back in the rcX days I configured a backup system which blocks a system shutdown in a certain state (network and mounts still active) if a backup is still running. The init script looks like this:

 

...


case "$1" in

...


  stop)  
    plymouth --ping
    if [ $? -ne 0 ]; then
  log_daemon_msg "waiting for running backup" "backup"
    else
  plymouth message --text="waiting for running backup"
    fi
    sleep 10
    logger -t backup "rcS: trying to get lock..."
    exec {FD}<>"$LOCKFILE"
    {
  logger -t backup "locked rsync_wrapper: waiting for lock"
  flock ${FD}
    }
    logger -t backup "rcS: continue shutdown..."
    plymouth message --text=""

 

...
esac

...


 

The strategy is to wait for a successful lock on a shared LOCKFILE.

 

Now, I want to solve this with systemd. I've read tons of documentation but I don't get it, all my experiments failed. I am using Linux Mint 21 "Vanessa", which is based on Ubunut 22.04.

 

I am looking for a solution which

 

* "pauses" a shutdown or reboot attempt as long as the LOCK cannot be obtained (which means the backup is still running)

* while the network connection (ethernet) is still active

* and all mounts (local, usb and cifs) are still active

* openssh-server still running

* The logging functionality (plymouth / log_daemon) would be nice. so the system should be allowed to shutdown to a stage where plymouth is already visible

 

Can you please help me?

 

Best regards

Henning






 

Probably similar to what you already have – create a service that starts on boot (doing nothing) and delays the *stop* action. (You'll probably need to start with [Service] Type=oneshot, RemainAfterExit=yes, TimeoutStopSec=1d.) If you list After=ssh.service as a dependency, then your service will be started after OpenSSH and *stopped before OpenSSH*, same with NetworkManager. (I'm not sure if there's a dependency that can be used to target manually done SMB mounts, although remote-fs.target might work for the ones in fstab?)

 

Not sure how it works with Plymouth, but in its default console output, systemd itself will already show which services are waiting to be stopped. Syslog (journald) should be available the entire time.

 

The backup system should also run under `systemd-inhibit --what=shutdown` as an additional layer of precaution – that way the user will know that something is still running *before* they initiate the actual shutdown.

--

Mantas Mikulėnas

Re: [systemd-devel] Help required for configuring a blocking service during shutdown

[Michael Biebl]

Would the systemd inhibit interface be an option?

https://www.freedesktop.org/wiki/Software/systemd/inhibit/

It was designed for that use case after all.

Am Mo., 29. Aug. 2022 um 14:01 Uhr schrieb Mantas Mikulėnas :
>
> On Mon, Aug 29, 2022 at 1:31 PM Henning Moll  wrote:
>>
>> Hi,
>>
>> back in the rcX days I configured a backup system which blocks a system 
>> shutdown in a certain state (network and mounts still active) if a backup is 
>> still running. The init script looks like this:
>>
>> ...
>> case "$1" in
>> ...
>>   stop)
>> plymouth --ping
>> if [ $? -ne 0 ]; then
>>   log_daemon_msg "waiting for running backup" "backup"
>> else
>>   plymouth message --text="waiting for running backup"
>> fi
>> sleep 10
>> logger -t backup "rcS: trying to get lock..."
>> exec {FD}<>"$LOCKFILE"
>> {
>>   logger -t backup "locked rsync_wrapper: waiting for lock"
>>   flock ${FD}
>> }
>> logger -t backup "rcS: continue shutdown..."
>> plymouth message --text=""
>>
>> ...
>> esac
>> ...
>>
>> The strategy is to wait for a successful lock on a shared LOCKFILE.
>>
>> Now, I want to solve this with systemd. I've read tons of documentation but 
>> I don't get it, all my experiments failed. I am using Linux Mint 21 
>> "Vanessa", which is based on Ubunut 22.04.
>>
>> I am looking for a solution which
>>
>> * "pauses" a shutdown or reboot attempt as long as the LOCK cannot be 
>> obtained (which means the backup is still running)
>> * while the network connection (ethernet) is still active
>> * and all mounts (local, usb and cifs) are still active
>> * openssh-server still running
>> * The logging functionality (plymouth / log_daemon) would be nice. so the 
>> system should be allowed to shutdown to a stage where plymouth is already 
>> visible
>>
>> Can you please help me?
>>
>> Best regards
>> Henning
>
>
> Probably similar to what you already have – create a service that starts on 
> boot (doing nothing) and delays the *stop* action. (You'll probably need to 
> start with [Service] Type=oneshot, RemainAfterExit=yes, TimeoutStopSec=1d.) 
> If you list After=ssh.service as a dependency, then your service will be 
> started after OpenSSH and *stopped before OpenSSH*, same with NetworkManager. 
> (I'm not sure if there's a dependency that can be used to target manually 
> done SMB mounts, although remote-fs.target might work for the ones in fstab?)
>
> Not sure how it works with Plymouth, but in its default console output, 
> systemd itself will already show which services are waiting to be stopped. 
> Syslog (journald) should be available the entire time.
>
> The backup system should also run under `systemd-inhibit --what=shutdown` as 
> an additional layer of precaution – that way the user will know that 
> something is still running *before* they initiate the actual shutdown.
>
> --
> Mantas Mikulėnas

[systemd-devel] Antw: [EXT] Re: [systemd‑devel] logind: discontinuous TTYs?

[Ulrich Windl]

>>> Toomas Rosin  schrieb am 26.08.2022 um 19:22 in Nachricht
<6751.1661534553@toomas>:
> Hi,
> 
> Arseny Maslennikov  wrote:
> 
>> $ TTYID=tty2 # for example
>> $ ln ‑s /dev/null /etc/systemd/system/autovt@$TTYID.service
> 
> This works, thank you!

Would the command above be the same as "systemctl mask
autovt@$TTYID.service"?
If so, the command would probably preferable to messing with systemd links, I
guess.

Regards,
Ulrich

Re: [systemd-devel] Help required for configuring a blocking service during shutdown

[Henning Moll]

Hi,

 

This is an interesting mechanism, but unfortunately it is to weak for my use case: It does only delay reboots which are initiated via "systemctl ...". A "sudo reboot" is not delayed

 

Best regards

Henning

 
 

Gesendet: Dienstag, 30. August 2022 um 10:14 Uhr
Von: "Michael Biebl" 
An: "Mantas Mikulėnas" 
Cc: "Henning Moll" , "Systemd" 
Betreff: Re: [systemd-devel] Help required for configuring a blocking service during shutdown

Would the systemd inhibit interface be an option?

https://www.freedesktop.org/wiki/Software/systemd/inhibit/

It was designed for that use case after all.

[systemd-devel] systemd-tmpfiles: behavior of --clean

[SCOTT FIELDS]

I'm currently running systemd 219-78.

I realize there's significant behavior differences in the current release, but 
per the documentation, I take it the behavior of '-clean' hasn't changed in 
regards to directly specifications only applying to the directory entry and the 
top level files. AKA, it still won't do recursive evaluation.

I also assume that the '-clean' behavior also still doesn't provide any 'glob' 
behavior specifications.

Primary issue for my side is managing tomcat tmp files.

These create a file in its temp location with a directory named of the form 
'tomcat.<>' with other associated files (or directories below this).

As such, we can't use 'systemd-tmpfiles' to purge these, though it's desirable 
to do so.

Is the current status for "system-tmpfiles" still such that the above can't be 
achieved with this subsystem?

[systemd-devel] Antw: [EXT] Re: Help required for configuring a blocking service during shutdown

[Ulrich Windl]

>>> Henning Moll  schrieb am 30.08.2022 um 16:24 in
Nachricht
:
> Hi,
> 
> This is an interesting mechanism, but unfortunately it is to weak for my use

> case: It does only delay reboots which are initiated via "systemctl ...". A

> "sudo reboot" is not delayed

At least in the past there was a difference between "reboot" and "shutdown -r
now":
The former wouldn't care much about how the reboot is done, while the latter
would try an orderly shutdown before reboot.

> 
> Best regards
> Henning
> Gesendet: Dienstag, 30. August 2022 um 10:14 UhrVon: "Michael Biebl" 
> An: "Mantas Mikulėnas" Cc: "Henning
Moll" 
> , "Systemd" Betreff:
Re: 
> [systemd-devel] Help required for configuring a blocking service during 
> shutdown
> Would the systemd inhibit interface be an 
> option?https://www.freedesktop.org/wiki/Software/systemd/inhibit/It was 
> designed for that use case after all.

[systemd-devel] Antw: [EXT] [systemd‑devel] systemd‑tmpfiles: behavior of ‑‑clean

[Ulrich Windl]

>>> SCOTT FIELDS  schrieb am 30.08.2022 um 21:15 in
Nachricht


> I'm currently running systemd 219‑78.
> 
> I realize there's significant behavior differences in the current release, 
> but per the documentation, I take it the behavior of '‑clean' hasn't changed

> in regards to directly specifications only applying to the directory entry 
> and the top level files. AKA, it still won't do recursive evaluation.
> 
> I also assume that the '‑clean' behavior also still doesn't provide any 
> 'glob' behavior specifications.
> 
> Primary issue for my side is managing tomcat tmp files.
> 
> These create a file in its temp location with a directory named of the form

> 'tomcat.<>' with other associated files (or directories below this).

I think with the guideline "clean up your own dirt" there wouldn't be so much
need for external cleanup if the applications would do a better job. The
application always knows best what, how, and when to clean up. (MHO)

> 
> As such, we can't use 'systemd‑tmpfiles' to purge these, though it's 
> desirable to do so.
> 
> Is the current status for "system‑tmpfiles" still such that the above can't

> be achieved with this subsystem?

Re: [systemd-devel] Antw: [EXT] Re: Help required for configuring a blocking service during shutdown

[Henning Moll]

Just tried "shutdown -r now" and unfortunately it also doesn't care about systemd-inhibit.

 
 

Gesendet: Mittwoch, 31. August 2022 um 08:07 Uhr
Von: "Ulrich Windl" 
An: "Michael Biebl" , newssc...@gmx.de
Cc: "systemd-devel@lists.freedesktop.org" 
Betreff: Antw: [EXT] Re: [systemd-devel] Help required for configuring a blocking service during shutdown

>>> Henning Moll  schrieb am 30.08.2022 um 16:24 in
Nachricht
:
> Hi,
>
> This is an interesting mechanism, but unfortunately it is to weak for my use

> case: It does only delay reboots which are initiated via "systemctl ...". A

> "sudo reboot" is not delayed

At least in the past there was a difference between "reboot" and "shutdown -r
now":
The former wouldn't care much about how the reboot is done, while the latter
would try an orderly shutdown before reboot.

>
> Best regards
> Henning
> Gesendet: Dienstag, 30. August 2022 um 10:14 UhrVon: "Michael Biebl"
> An: "Mantas Mikulėnas" Cc: "Henning
Moll"
> , "Systemd" Betreff:
Re:
> [systemd-devel] Help required for configuring a blocking service during
> shutdown
> Would the systemd inhibit interface be an
> option?https://www.freedesktop.org/wiki/Software/systemd/inhibit/It was
> designed for that use case after all.

 

Re: [systemd-devel] Antw: [EXT] Re: Help required for configuring a blocking service during shutdown

[Ulrich Windl]

>>> Henning Moll  schrieb am 31.08.2022 um 08:13 in
Nachricht
:
> Just tried "shutdown -r now" and unfortunately it also doesn't care about 
> systemd-inhibit.

Is the systemd shutdown target triggered anyway? I guess it is. If so, the
problem must be deeper "under the hood".

> Gesendet: Mittwoch, 31. August 2022 um 08:07 UhrVon: "Ulrich Windl" 
> An: "Michael Biebl" , 
> newssc...@gmx.decc: "systemd-devel@lists.freedesktop.org" 
> Betreff: Antw: [EXT] Re:
[systemd-devel] 
> Help required for configuring a blocking service during shutdown
 Henning Moll  schrieb am 30.08.2022 um 16:24 
>
inNachricht -gmx-bs58>:> Hi,>> This is an interesting mechanism, but unfortunately it is
to 
> weak for my use> case: It does only delay reboots which are initiated via 
> "systemctl ...". A> "sudo reboot" is not delayedAt least in the past there
was 
> a difference between "reboot" and "shutdown -rnow":The former wouldn't care

> much about how the reboot is done, while the latterwould try an orderly 
> shutdown before reboot.>> Best regards> Henning> Gesendet: Dienstag, 30.
August 
> 2022 um 10:14 UhrVon: "Michael Biebl"> An: "Mantas
Mikulėnas" 
> Cc: "HenningMoll"> , "Systemd" 
> Betreff:Re:> [systemd-devel] Help
required 
> for configuring a blocking service during> shutdown> Would the systemd
inhibit 
> interface be an> 
> option?https://www.freedesktop.org/wiki/Software/systemd/inhibit/It was> 
> designed for that use case after all.