Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
> On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com) wrote:
> > Hi all,
> > 
> > I have a small device MicroUPS which helps me to shutdown my system on
> > embedded devices, it is controlled by script /etc/init.d/microups and in
> > this script I need to know whether system is going down for reboot or for
> > halt, because in case of halt I need to send small data over RS232 to
> > MicroUPS device to cut the power off.
> Note that this is necessarily racy: you can't really know how long the
> system will actually take to shut down, hence if you trigger your
> hardware for shutdown at an early phase of the shutdown process you
> now start racing the remaining shutdown phase against the hardware turning
> off power...
> If you want to fix this properly, and remove this race entirely the
> only fully correct way out I see is to use an initrd for booting, and
> doing the RS232 thing from that. Note that if you use a properly
> prepared initrd, systemd will actually transition back to it at
> shutdown, and while doing so it will permit unmounting the root file
> system properly at shutdown. And only if you start the RS232 thing
> after the point where the root fs is unmounted you can fully remove
> the race in the generic case, since only at that point everything is
> fully synced to disk, all complex storage is disassembled and so on.
> Now, adding this to the initrd is not the easiest thing in the world,
> and in particular in embedded devices avoiding an initrd might be a
> good thing. As long as you have no complex storage (i.e. no DM, no
> LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
> corner and just drop in a shutdown script to
> /usr/lib/systemd/system-shutdown/. All executable files in that
> directory are run at very late boot, at a point where all file systems
> that can be unmounted have been unmounted and the rest have been
> remounted read-only (i.e. the root fs will be r/o and everything else
> is gone). All services are gone at that point too, hence you live in a
> very minimal, very reduced environment. If you issue your RS232
> commands from that environment you should be mostly good. (but again,
> if you do complex storage all of this falls apart, and you have to do
> the initrd thing instead).
> Note that /usr/lib/systemd/system-shutdown/ is outside of usual
> service management. It's run at a point where service management is
> already turned off. As such, you really just drop executable scripts
> or binaries there, and nothing long-running, no daemons or such, just
> simple programs that run and exit.
> For details about this facility see the systemd-halt.service(8) man
> page. The scripts executed that way will get one parameter, which
> tells it what operation is being executed. And if its "poweroff", then
> you know that the system is going down for powering off rather than
> reboot.


This looks like a good way for me.
I cannot really use initrd, because my MicroUPS is intended to work not only 
for me but also for an average people, with some .deb package to install.
This is an early version of my device, now it looks different, has higher 
power output and so on

I'm aware of race condition but some microcomputers like Raspberry if they 
shutdown the operating system, the power is still ON, and I have no way to 
figure out when to turn power off. So what I'm doing is telling microups device 
to cut power off 30 seconds after shutdown has been initiated (parameter is 
Microcomputers usually have some SD card, sometimes built-in NAND memory, and 
sometimes single SATA SSD disk, so complex storage is not an issue (I think)

The question is, will my binary be able to open RS232 port eg. /dev/ttyACM0 
when filesystem is Read-Only ?
And if it is binary it will need to load some libs at least libc at the start.

The man page you pointed to says the parameter is: "halt", "poweroff", 
"reboot" or "kexec", so the first two should work for me.

Best Regards

> Lennart

systemd-devel mailing list

Reply via email to