On Tue, Nov 22, 2022 at 10:11:15PM +0100, Ximo wrote:
> El 22/11/2022 a las 13:23, Urs Thuermann escribió:
> > After shutdown -h <time> I see no way to see this scheduled shutdown.
> > Before systemd, I could always see the shutdown process with its
> > arguments using ps(1).
> >
>
> # date --date @$(head -1 /run/systemd/shutdown/scheduled |cut -c6-15)
That looks quite fragile. If the output format changes even slightly,
it'll start to give wrong answers.
In order to offer a better solution, I'd need to *see* one of these
files. Which in turn apparently means I need to generate one. So I guess
I get to test that "cancel" option after all.
unicorn:~$ sudo shutdown -r 23:59
[sudo] password for greg:
Reboot scheduled for Tue 2022-11-22 23:59:00 EST, use 'shutdown -c' to cancel.
unicorn:~$ cat /run/systemd/shutdown/scheduled
USEC=1669179540000000
WARN_WALL=1
MODE=reboot
OK. I can work with that.
unicorn:~$ date -d @"$(awk -F= '/^USEC=/ {print $2/1000000}'
/run/systemd/shutdown/scheduled)"
Tue Nov 22 23:59:00 EST 2022
unicorn:~$ sudo shutdown -c
unicorn:~$ cat /run/systemd/shutdown/scheduled
cat: /run/systemd/shutdown/scheduled: No such file or directory
Ironically, the "sudo shutdown -c" command blasted a message onto every
terminal EXCEPT the one where I ran the command. Rather annoying.
A solution built around "dotting in" the file in a shell would also work,
but that's quite a bit more dangerous if the output format changes, or if
I'm only seeing a "best case scenario" here. Before going there, I would
want to check the systemd source code to see whether this file is written
in a way that's guaranteed to be safe for a shell to dot in. That's more
effort than I care to put into this right now.
