[sf-lug] shutdown, wall, ... (was: sudo abuse, suspend/shutdown, and polkit)

[Michael Paoli]

> From: "Akkana Peck" <akkana at shallowsky.com>
> Subject: Re: [sf-lug] sudo abuse, suspend/shutdown, and polkit
> Date: Tue, 19 Feb 2019 11:36:12 -0700

> $ systemctl suspend
> Failed to set wall message, ignoring: The name  
> org.freedesktop.PolicyKit1 was not provided by any .service files
> Failed to suspend system via logind: The name  
> org.freedesktop.PolicyKit1 was not provided by any .service files
> Failed to start suspend.target: The name org.freedesktop.PolicyKit1  
> was not provided by any .service files
> See system logs and 'systemctl status suspend.target' for details.
>
> $ systemctl status suspend.target
> ? suspend.target
>    Loaded: masked (Reason: Unit suspend.target is masked.)
>    Active: inactive (dead)

> The man pages for systemd-suspend.service says nothing about wall.

> Grepping for wall found files

So, shutdown(8) has been around since nearly forever ... certainly
from relatively early days of Unix.  Though, even long before Linux,
the particular syntax of shutdown(8) varied greatly among differing
flavors of Unix, but in general, it would:
o control/drive (indirectly ... head of the beast) orderly system
   shutdown, and generally if not always also supported transitioning
   to other run levels (e.g. drop to single user, without going fully
   down).
o could be set with some lead time before it started the actual shutdown
   (seconds or minutes from now, or at some (nearish ... within 24 hrs.?)
   future time
o would generally block new logings - either when shutdown program
   started, or often relatively close to shutdown (e.g. 10 minutes
   before shutdown sequence proper kicked off) - see also nologin(5)
   ((re)start/boot would subsequently clear that - at least when going
   to multi-user mode, if not before that)
o would handle notifying users - most notably via wall(1) ...
   and, generally, shutdown would need to be run by root (though some
   versions might offer configuration to allow some other user(s) or
   group member(s) to have authority to launch it).  Likewise wall(1) ...
   generally would need to be run as root to ensure it was actually
   effective (if users have their tty permissions (see also mesg(1))
   only allowing owner to write the tty device ... well, root has
   permissions regardless, so wall(1) used by mere mortal user generally
   wouldn't be able to write those tty devices - but root would be able
   to regardless.

So ... various flavors of hibernate/sleep and such ... they're sort of like
a partial pseudo-shutdown ... and likewise may typically also use
wall(1), etc.  So, ... some things haven't changed ... much.
Sounds rather like systemd ... well, its "handling" (trying
to handle) the shutdown(/suspend/etc.) and wall stuff, ... but ...
not quite managing (or maybe wasn't invoked with sufficient (root)
privilege).

Depending upon the version/flavor of shutdown, it may also offer
options to skip/bypass much of this processing.
There may also be alternative commands that can do similarly and/or
mostly just do what shutdown does.  E.g. halt(8), poweroff(8), reboot(8),
etc.  Historically halt(8) would instantly halt the Unix system, a
typical fast "emergency" shutdown might be something like:
# sync && sync && halt
... at least historically.  Current typical Linux halt(8) default behavior
is rather different, so ... would need something like the --force option
to get behavior similar to the classic (I'm guessing Linux versions added
that to give sysadmin ("users") a bit of protection against themselves
(... at the cost of them endangering Unix when they hop on there and
expect the Linux default behavior).
And, ... if there is or may possibly be disk/filesystem corruption
actively in progress, one might opt to *not* sync, e.g.:
# halt --force --no-sync
or on classic Unix that would typically be a mere:
# halt

And ... various run levels ... varies across Unix - and even somewhat
on Linux ... but typically could go to a "shutdown" level,
which (classicly) gets to some hardware monitor/prompt on console (a
point where safe to power down (or can boot from there), but not yet
powered down, or, shutdown and power down (if the hardware can itself
do that), or instead reboot, or to single user mode, or possibly even
some other run level mode.  See also: init, telinit