<div dir="ltr">I too am one of the `halt -p` guys, and that is an evolution from shutdown and its various changes many years ago.<div>I suppose this thread has got me thinking about the desire to not disturb long standing traditions and behaviour, retain compatibility, but still progress and evolve at the same time.</div><div>What can you do?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Nov 2024 at 22:50, Brad Campbell <<a href="mailto:brad@fnarfbargle.com">brad@fnarfbargle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19/11/24 22:43, Gregory Orange wrote:<br>
> On 19/11/24 16:10, Brad Campbell wrote:<br>
>> Due to "legacy" on shutdown the host iteratively sshs into each VM and performs an '/sbin/poweroff' to cleanly stop the VMs before putting a virtual axe through them. This has been the way it's worked for >10 or so years. The Ubuntu VMs are "relatively" new. With those, '/sbin/poweroff' shuts the VM down, but does it by forcibly and unceremoniously terminating all running processes. This makes for a nice quick shutdown, but leaves databases in various states of "broken" because nothing has a chance to shut down "cleanly".<br>
>> These needed their shutdown command changed from '/sbin/poweroff' to 'systemctl poweroff' to prevent them corrupting stuff on shutdown.<br>
> <br>
> So many quirks of habit that we have, subtly different to each other.<br>
> I've long run `halt -p`, I think because `halt` (or was it shutdown<br>
> without -h?) on FreeBSD $version at $job[x] shutdown the OS but didn't<br>
> power off.<br>
> <br>
> You've prompted me to look at an Ubuntu 22.04 machine...<br>
> ubuntu@dev22:~$ ls -l `which poweroff`<br>
> lrwxrwxrwx 1 root root 14 Nov 22  2023 /usr/sbin/poweroff -> /bin/systemctl<br>
> ubuntu@dev22:~$ ls -l /sbin/poweroff<br>
> lrwxrwxrwx 1 root root 14 Nov 22  2023 /sbin/poweroff -> /bin/systemctl<br>
> <br>
> Interesting.<br>
> The manpage talks about preserving compatibility with SysV commands.<br>
> I wonder if you're on Ubuntu 24.04.<br>
<br>
No, 20.04. I'm sure it's "compatible" as much as anything systemd remains "compatible". My experience hasn't been good.<br>
<br>
> Also, are you talking about a KVM host? From memory I tend to run `virsh<br>
> shutdown $id` and that does things cleanly. I can `destroy` if I want to<br>
> be brutal.<br>
<br>
Yes, I was working my way toward migrating to that. What I found however was differing responses to ACPI prompts. This renders the virsh shutdown somewhat unreliable. When it's happening in the context of "UPS says we have 10 minutes of runtime left, please shut down cleanly and promptly" reliability is to be valued.<br>
<br>
The worst is Windows. Depending on the version, and whether someone has logged in or not, the response to an ACPI power button varies from "I'll do what you intended and shut down" to "I'm going to pretend I never heard that".<br>
So the only way to *reliably* shut down a windows guest I've found is using SAMBAs net rpc command to issue a shutdown rpc call. If I'm going to have to do that then I might as well keep my "ssh using a special shutdown key" method and reliably shut the linux guests down also. If they don't shut down in 300 seconds then I use virsh destroy to slay them.<br>
<br>
Regards,<br>
Brad<br>
_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a><br>
</blockquote></div>