Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

How systemd sent stop

If none of the specific sub-forums seem right for your thread, ask here.
Post Reply
Message
Author
peter_irich
Posts: 1403
Joined: 2009-09-10 20:15
Location: Saint-Petersburg, Russian Federation
Been thanked: 11 times

How systemd sent stop

#1 Post by peter_irich »

Hello,

I would like to know in which order systemd turns off units, if it really makes this.
I use Debian based system with kernel 4.15.
I wrote simple Unit, it starts after the file system mounted.

Code: Select all

[Unit]
Description=increases_workingTime
#DefaultDependencies=no
Requires=lm-sensors.service
Before=lm-sensors.service

[Install]
WantedBy=multi-user.target
#WantedBy=lm-sensors.service

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
ExecStart=/usr/local/bin/simple_daemon.elf
ExecStop=/usr/local/bin/incr_workTime
simple_daemon.elf is a daemon on C, it writes ti /var/log/syslog only.
unit is still in memory after starting according "systemctl status", incr_workTime is my script and I need
so as to it starts when computer is turned off before the file system will be unmonted.
How make that systemd sent command "stop" (systemctl stop) to this Unit itself?
How I must force Unit "wait"?
There is quoting from "man systemd.service":
ExecStop= Commands to execute to stop the service started via ExecStart=.
This argument takes multiple command lines, following the same scheme as
described for ExecStart= above. Use of this setting is optional. After the
commands configured in this option are run, all processes remaining for a
service are terminated according to the KillMode= setting (see
systemd.kill(5)). If this option is not specified, the process is terminated
by sending the signal specified in KillSignal= when service stop is requested.
Specifier and environment variable substitution is supported (including
$MAINPID, see above).

Note that it is usually not sufficient to specify a command for this setting
that only asks the service to terminate (for example, by queuing some form of
termination signal for it), but does not wait for it to do so. Since the
remaining processes of the services are killed using SIGKILL immediately
after the command exited, this would not result in a clean stop. The specified
command should hence be a synchronous operation, not an asynchronous one.

Note that the commands specified in ExecStop= are only executed when the
service started successfully first. They are not invoked if the service was
never started at all, or in case its start-up failed,for example because any
of the commands specified in ExecStart=, ExecStartPre= or ExecStartPost=
failed (and weren't prefixed with "-", see above) or timed out. Use
ExecStopPost= to invoke commands when a service failed to start up correctly
and is shut down again.

It is recommended to use this setting for commands that communicate with the
service requesting clean termination. When the commands specified with this
option are executed it should be assumed that the service is still fully up
and is able to react correctly to all commands. For post-mortem clean-up
steps use ExecStopPost= instead.
Or where I can find the detailed systemd's description ?

Please help who knows.

peter_irich
Posts: 1403
Joined: 2009-09-10 20:15
Location: Saint-Petersburg, Russian Federation
Been thanked: 11 times

Re: How systemd sent stop

#2 Post by peter_irich »

It seems I wrote Before= instead of After=.
local-fs.target I tried too, but because of my mistake my Unit simply was not running. I check it in Monday.

peter_irich
Posts: 1403
Joined: 2009-09-10 20:15
Location: Saint-Petersburg, Russian Federation
Been thanked: 11 times

Re: How systemd sent stop

#3 Post by peter_irich »

I found the first working variant like setserial.service.
First, there is unit in /etc/systemd/system:

Code: Select all

[Unit]
Description=increases_workingTime
#DefaultDependencies=no

BindsTo=avahi-daemon.service
After=avahi-daemon.service

[Install]
WantedBy=multi-user.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/incr_workTime start
ExecStop=/usr/local/bin/incr_workTime stop
Second, this is /usr/local/bin/incr_workTime:

Code: Select all

#!/bin/bash

arg=$1
if [ "$arg" = "start" ] ; then
/bin/echo "start"
else
if [ "$arg" = "stop" ] ; then
while read flnm ; do
uptp="$flnm"
done < /proc/uptime
uptc=`/bin/echo $uptp | /usr/bin/cut -d " " -f 1`
upts=`/bin/echo $uptc | /usr/bin/cut -d "." -f 1`
nupts="10#"$upts
let nuptsr=nupts
/bin/echo "uptp=""$uptp" "uptc="$uptc "npts="$nuptsr > /home/peter/workingTime
/usr/bin/chown peter:users /home/peter/workingTime.out
fi
fi
After rebooting I saw file workingTime with right time.
Instead of avahi-daemon.service I intend to try local-fs.target.

Post Reply