[plug] Systemd in VMs

[Gregory Orange]

On a related note, today I got a bit more comfortable with journalctl,
and I like the features. I just hope it's as reliable as grep/tail etc
for looking at logs. lnav(1) has been great and I'll keep using it, but
it crashes sometimes, and journalctl is much faster. Also the software I
was using didn't put anything in its /var/log/ files by default, but it
was all there in journalctl. We live in interesting times.


On 20/11/24 07:57, Juneidy wrote:
> 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
>> <mailto: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 <mailto:plug at plug.org.au>
>>     http://lists.plug.org.au/mailman/listinfo/plug
>>     <http://lists.plug.org.au/mailman/listinfo/plug>
>>     Committee e-mail: committee at plug.org.au <mailto:committee at plug.org.au>
>>     PLUG Membership: http://www.plug.org.au/membership
>>     <http://www.plug.org.au/membership>
>>
> 

-- 
Gregory Orange