-g option should not really be needed

[Lockywolf]

Hello!

I think that a stateful call to -g is not actually required.

Whether the previous shutdown was graceful or not can be decided by

if [[ x"$(last -xn2 shutdown reboot | head -n 2 | awk '{print $1;}' | tr -d '\n')" == x"rebootshutdown" ]]

or something like that.
c.f. https://access.redhat.com/articles/2642741

The line above should also work on openbsd, with rebootshutdown replaced with shutdownreboot, or something like that.

[Ricardo F.]

Hi,

Please, could you explain it a bit more? maybe with an example.
Where the bash call to last (and their inner call to /var/log/wtmp) could replace the -g Tuptime argument?

Thanks,

[Deleted user]

When "tuptime" is called the first time after a boot (i.e., when current uptime starts later than the last tuptime hearbeat), it can find out whether the last shutdown was graceful or not by using the aforementioned command (call to last). Then the previous shutdown can be marked as graceful.

[Ricardo F.]

last command register the power events via the systemd-update-utmp.service unit, and their definition file contains:

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-update-utmp reboot
ExecStop=/lib/systemd/systemd-update-utmp shutdown

Basically an execution at Stop and Start with a parameter for each one. The equivalent as tuptime does in their unit file:

[Service]
User=tuptime
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/tuptime -x
ExecStop=/usr/bin/tuptime -xg
StateDirectory=tuptime

So, if tuptime needs to rely on last, it needs this command as dependency, at the end, to do the same at the SystemD level.

[Deleted user]

Well, that is the point, isn't it? Whatever is considered a "graceful shutdown" is up to the system init manager to decide.
In my case (not systemd), a graceful shutdown is registered with halt -w, which system scripts do automatically (just as systemd do does in your example).

[Ricardo F.]

A "graceful shutdown" are the words to define the way to brought down the system in a safe way, and that is one of the tasks of the init manager. The wall that are hitting last and tuptime are the same, they need to know if that process was done right or not. For this tasks tuptime doesn't require more dependencies than the init manager and the raw information than the O.S. provides, in parallel with last.

With your proposal, tuptime forguet the use of -g at shutdown, but it still requires the execution at the very end to register the time passed in any case. At startup, it would need to parse wtmp with the O.S. particular tool (last in this case, but surely it changes their output and needs some quirks for for BSDs and particular Linux sauces) or do it directly in some way. Compare reading a few values always available from the kernel with relying in a file that is not absolutely sure that it will be there, other tool is populating and sometimes is empty due the rotate cycle.

Also, in this proposal case, why don't fall into the information of wtmp to avoid getting the kernel information directly? It could also provide the startup time.

As summary, tuptime do their job with a few trustful sources of information and the narrow range of dependencies possible, the shift from -g to wtmp adds a complexity that doesn't add value.

Anyway, what is the root problem with -g that have originated this request?

Let me paste here an example of two outputs of last shutdown and startup:

$ last -xn2 --time-format full shutdown reboot 
reboot   system boot  4.19.0-5-amd64   Fri Apr 29 04:36:46 2022   still running
shutdown system down  4.19.0-5-amd64   Thu Apr 28 23:02:42 2022 - Fri Apr 29 04:36:46 2022  (05:34)

wtmp starts Thu Apr 28 22:32:17 2022

$ tuptime -t -S-1 -r
 No.        Startup T.    Uptime         Shutdown T.   End    Downtime
                                                                      
28   04:36:41 29/04/22   56m 37s                                      
27   22:31:55 28/04/22   30m 46s   23:02:41 28/04/22   OK    5h 34m 0s