After being able to piece together what happened with the machine's logs and the bash history I recommended to simply exit all programs/sessions with Ctrl+D. It works almost everywhere and would have prevented this exact issue.
After being able to piece together what happened with the machine's logs and the bash history I recommended to simply exit all programs/sessions with Ctrl+D. It works almost everywhere and would have prevented this exact issue.
For whatever reason if you type a variable/symbol it assigns it the value 0. If you type exit nothing happens immediately but as soon as the next process exits usually a few seconds to 10s of seconds later the entire system kernel panics on a null pointer de-reference.
Kernel paniced our production ZFS filer twice before I cottoned on. Newer releases special cased “exit” not to do that.
For those familiar with Solaris, is there any reason they did it this way?
How can you possibly set the default behaviour of assigning any symbol a value of 0 by default?
For example, on our Solaris machines, after install, "reboot" does not do a clean reboot, it's a hard reset. If you want a clean reboot you need "init 6". Same story for "shutdown" and "init 5".
"killall" also kills all processes. Not the one you specified. Or more specifically it SIGKILLs all processes that have open files (ssh session and server go byebye). If you type "reboot" or "shutdown", this is in fact the binary that gets called do that.
Sadly, Solaris is also one of the few systems that support the NFSv4 ACLs (Linux supports NFSv4 but not the ACL Extension, TrueNAS has a patch for that).
The only fork of Ganesha that supports it on a proper filesystem is the TrueNAS fork and that only on their ZFS Fork that brings NFSv4 ACLs to Linux.
So really, no. You can't use NFSv4 ACLs with Ganesha on Linux outside of Forks or using scale-out data stores.
That was a fun lesson…
Since then I always shut down my machine using the GUI and I have Tmux configured with different colors for SSH sessions.
Also, it's possible to circumvent it when you have scripts that need to reboot the machine without interaction by issuing `reboot </dev/null` in the script.
After that I looked up how to enable wake-on-lan and open up a port to be able to do that remotely.
That said, if your device is based on some kind of Espressif ESP32 module, you might be able to find the right four pins on the circuit board and find or cobble together a configuration to talk to the I/O ports. Hardware required is a (usually USB) RS232 interface at 3.3 volts, some medium-thin cables, screwdriver, soldering iron, probably multimeter to check things. The firmware flashing and WiFi setup are fairly independent of the I/O port configuration, so you can flash something that can bring up the WiFi connection and web interface and experiment from there.
They won’t have the permission if connected remotely though.
Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).
In the end, the user being able to accidentally run "systemctl exit" may be indicative of a policy issue (ie don't allow root logins).
This article suggests there are ways for programs to issue unaudited commands with elevated privileges to systemd.
"Systemd has a D-Bus interface that people can use, there's hardware events that may trigger a reboot, there are various programs that may decide to ask systemd to reboot the system, and under some circumstances systemd itself can decide that a particular, harmless looking process failure or 'systemctl' transaction actually will trigger a reboot through some weird chain of dependencies and systemd unit settings"
Complaining about systemd is as old as systemd, and borders on a religious war, a proxy towards "modern linux" and "old school unix" methods.
Having 2 alternative commands for the same functionality is not a good design decision IMHO. But not the most central design decision for systemd.
I prefer openRC, and I'll wave a flag or whatever but to each their own.
WinNT4 was goat.