Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

[D.S. Ljungmark]

On 27/10/17 12:25, Lennart Poettering wrote:
> On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:
> 
>> So, I've got a piece of hardware I want to do a final handover to just
>> around reboot.target / shutdown.target
>>
>> This will then cause the entire CPU and hardware allocated to it to
>> actually drop power (and schedule re-power), so I don't want to do this
>> earlier.
>>
>>
>>
>> Is it simply to do:
>>
>> [Unit]
>> DefaultDependencies=no
>>
>> [Service]
>> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
>> Type=oneshot
>>
>> [Install]
>> WantedBy=reboot.target
>>
>> or am I missing something here? ( Perhaps the fact that systemd has
>> already pivoted root to somewhere else?)
> 
> Well, the above is not the right way really.
> 
> 1. If you want to go for the unit option, it is definitely a better
>idea to define one that is started at boot (but has ExecStart=
>empty and only ExecStop= defined, and uses RemainAfterExit= to
>ensure that it stays active even without a process around). Only
>that way you can properly order your unit against other shutdown
>units.
> 
> 2. Doing this via a unit means your code is invoked during the first
>phase of shutdown, inside the usual dependency tree logic. I figure
>you actually want to do this later even, i.e. after all services
>are down, after systemd did its killing spree and umount spree and
>all that stuff. For that simply drop the binary/script of your
>choice in /usr/lib/systemd/system-shutdown/. All files in that dir
>that are marked executable are executed right before we'd return to
>the initrd/invoke the reboot() syscall. Also see:
>systemd-shutdown(8)
> 
> 3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
>invoked at a time where the root file system itself is still
>mounted. This means various weird storage daemons might still be
>pinned (think: root on mdraid/LVM/…). Hence, turning off power at
>that point is not fully safe nor correct either, except if you know
>your setup and know you don't have weird storage. If you want to
>cover this generic case too, then you have to use an initrd, make
>use of systemd's logic to transition back into the initrd at
>shutdown, and invoke what you want to invoke from there.
> 
> Lennart



Since this is an embedded case, we have fairly good control over what's
running and where.  For example, rootfs is not a problem as it's
squashfs, and shouldn't be degraded by rebooting.  As long as our
configuration/data partitions aren't mounted, we ought to be good.

And thank you for the pointer about /usr/lib/systemd/system-shutdown/
that indeed sounds a lot better for us.

ExecStop does indeed sound like the wrong solution as well, as mentioned
due to the ordering.


Thanks for the thorough explanation, much appreciated!

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

[Lennart Poettering]

On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:

> So, I've got a piece of hardware I want to do a final handover to just
> around reboot.target / shutdown.target
> 
> This will then cause the entire CPU and hardware allocated to it to
> actually drop power (and schedule re-power), so I don't want to do this
> earlier.
> 
> 
> 
> Is it simply to do:
> 
> [Unit]
> DefaultDependencies=no
> 
> [Service]
> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
> Type=oneshot
> 
> [Install]
> WantedBy=reboot.target
>
> or am I missing something here? ( Perhaps the fact that systemd has
> already pivoted root to somewhere else?)

Well, the above is not the right way really.

1. If you want to go for the unit option, it is definitely a better
   idea to define one that is started at boot (but has ExecStart=
   empty and only ExecStop= defined, and uses RemainAfterExit= to
   ensure that it stays active even without a process around). Only
   that way you can properly order your unit against other shutdown
   units.

2. Doing this via a unit means your code is invoked during the first
   phase of shutdown, inside the usual dependency tree logic. I figure
   you actually want to do this later even, i.e. after all services
   are down, after systemd did its killing spree and umount spree and
   all that stuff. For that simply drop the binary/script of your
   choice in /usr/lib/systemd/system-shutdown/. All files in that dir
   that are marked executable are executed right before we'd return to
   the initrd/invoke the reboot() syscall. Also see:
   systemd-shutdown(8)

3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
   invoked at a time where the root file system itself is still
   mounted. This means various weird storage daemons might still be
   pinned (think: root on mdraid/LVM/…). Hence, turning off power at
   that point is not fully safe nor correct either, except if you know
   your setup and know you don't have weird storage. If you want to
   cover this generic case too, then you have to use an initrd, make
   use of systemd's logic to transition back into the initrd at
   shutdown, and invoke what you want to invoke from there.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

[Jérémy Rosen]

see man:bootup for the general architecture of shutdown and 
man:systemd-shutdown for how to add a script as the "ultimate phase" of 
the shutdown


doing it with services is tricky, your approch will make it be called at 
shutdown but you did not specify "when" during shutdown, so systemd 
might schedule it at any point


you could try to plug it in at the right place using some Before= and 
After= but if that command is the "real shutdown" command, i'd use the 
process described in systemd-shutdown



regards
Jérémy

On 27/10/2017 11:43, D.S. Ljungmark wrote:

So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target

This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.



Is it simply to do:

[Unit]
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
Type=oneshot

[Install]
WantedBy=reboot.target



or am I missing something here? ( Perhaps the fact that systemd has
already pivoted root to somewhere else?)

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Scheduling unit at reboot.target and shutdown.target

[D.S. Ljungmark]

So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target

This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.



Is it simply to do:

[Unit]
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
Type=oneshot

[Install]
WantedBy=reboot.target



or am I missing something here? ( Perhaps the fact that systemd has
already pivoted root to somewhere else?)

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel