[plug] Systemd in VMs

[Juneidy]

My journey in linux started in 2017, I've only ever known systemd. The first time I've ever conciously "build" my own linux, everything is already systemd. systemd-boot, systemd-networkd, systemd-resolved, all services like startups are managed by systemd.

At times I would wonder what is it like back then before the times of systemd.
On Wednesday, November 20th, 2024 at 07:52, Byron Hammond <byronester at gmail.com> wrote:

> I too am one of the `halt -p` guys, and that is an evolution from shutdown and its various changes many years ago.
> 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.
> What can you do?
>
> On Tue, 19 Nov 2024 at 22:50, Brad Campbell <brad at fnarfbargle.com> wrote:
>
>> On 19/11/24 22:43, Gregory Orange wrote:
>>> On 19/11/24 16:10, Brad Campbell wrote:
>>>> 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".
>>>> These needed their shutdown command changed from '/sbin/poweroff' to 'systemctl poweroff' to prevent them corrupting stuff on shutdown.
>>>
>>> So many quirks of habit that we have, subtly different to each other.
>>> I've long run `halt -p`, I think because `halt` (or was it shutdown
>>> without -h?) on FreeBSD $version at $job[x] shutdown the OS but didn't
>>> power off.
>>>
>>> You've prompted me to look at an Ubuntu 22.04 machine...
>>> ubuntu at dev22:~$ ls -l `which poweroff`
>>> lrwxrwxrwx 1 root root 14 Nov 22 2023 /usr/sbin/poweroff -> /bin/systemctl
>>> ubuntu at dev22:~$ ls -l /sbin/poweroff
>>> lrwxrwxrwx 1 root root 14 Nov 22 2023 /sbin/poweroff -> /bin/systemctl
>>>
>>> Interesting.
>>> The manpage talks about preserving compatibility with SysV commands.
>>> I wonder if you're on Ubuntu 24.04.
>>
>> No, 20.04. I'm sure it's "compatible" as much as anything systemd remains "compatible". My experience hasn't been good.
>>
>>> Also, are you talking about a KVM host? From memory I tend to run `virsh
>>> shutdown $id` and that does things cleanly. I can `destroy` if I want to
>>> be brutal.
>>
>> 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.
>>
>> 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".
>> 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.
>>
>> Regards,
>> Brad
>> _______________________________________________
>> PLUG discussion list: plug at plug.org.au
>> http://lists.plug.org.au/mailman/listinfo/plug
>> Committee e-mail: committee at plug.org.au
>> PLUG Membership: http://www.plug.org.au/membership
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20241119/4cedc35d/attachment.html>