[opensuse-kubic] What other automated system reboots are there in MicroOS other than the automated Daily Transactional-Updates?
Hi All, I have recently decided to use the MicroOS as my hypervisor for KVM/Libvirt box which is going to be used in a mission critical project in a few months. I am currently putting the MicroOS installation on the server through it's paces before rolling it out. As stated previously, due to the use case of the Server, I want to be in full control off the system updates, and reboot cycles. The plan is to ultimately have weekly manual system updates during the weekends. I have already found, and disabled, the automated Transactional-Updates (ransactional-update.timer & rebootmgr.service) and the system no longer checks for updated versions and subsequently automatically reboot. That being said, it seems that there is still another reason for the server to reboot itself automatically. I regularly check the system uptime and it seems that in the week time that I have disabled the automated Transactional Updates the system still reboots once a week (Happened on Friday May 1st 17:34 local time). So, I would like to know if I am missing any other automated reasons why MicroOS would automatically reboot? and how can I disable them, if possible. Thanks. -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Sat, May 02, The Undertaker wrote:
That being said, it seems that there is still another reason for the server to reboot itself automatically. I regularly check the system uptime and it seems that in the week time that I have disabled the automated Transactional Updates the system still reboots once a week (Happened on Friday May 1st 17:34 local time).
You could look at the journalctl output, when the machine did reboot and if there is a reason logged why.
So, I would like to know if I am missing any other automated reasons why MicroOS would automatically reboot?
There is nothing which reboots MicroOS automatically except the update stack. Disabling transactional-update.timer should be enough. Diabling rebootmgr has more the opposite effect: if something tries to reboot with rebootmgr, and it's disabled, it will do an immeadiate hard reboot instead. But except transactional-update I'm not aware of any other tool calling it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Sat, 2 May 2020 at 13:44, Thorsten Kukuk <kukuk@suse.de> wrote:
You could look at the journalctl output, when the machine did reboot and if there is a reason logged why.
Thanks for the tip, but sadly there does not seem to be anything interesting in the last few hours leading up to the reboot other than some snapper activity, none of which seems relevant (in my limited knowledge that is.) May 01 10:49:50 localhost systemd-helper[7871]: running timeline cleanup for 'root'. May 01 10:49:50 localhost systemd-helper[7871]: running empty-pre-post cleanup for 'root'. May 01 10:49:50 localhost systemd[1]: snapper-cleanup.service: Succeeded. May 01 10:54:49 localhost systemd[1]: Starting Cleanup of Temporary Directories... May 01 10:54:49 localhost systemd-tmpfiles[7889]: [/usr/lib/tmpfiles.d/tmp.conf:13] Duplicate line for path "/var/tmp", ignoring. May 01 10:54:49 localhost systemd-tmpfiles[7889]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. May 01 10:54:49 localhost systemd-tmpfiles[7889]: [/usr/lib/tmpfiles.d/var.conf:19] Duplicate line for path "/var/cache", ignoring. May 01 10:54:49 localhost systemd-tmpfiles[7889]: [/usr/lib/tmpfiles.d/var.conf:21] Duplicate line for path "/var/lib", ignoring. May 01 10:54:49 localhost systemd-tmpfiles[7889]: [/usr/lib/tmpfiles.d/var.conf:23] Duplicate line for path "/var/spool", ignoring. May 01 10:54:49 localhost systemd[1]: systemd-tmpfiles-clean.service: Succeeded. May 01 10:54:49 localhost systemd[1]: Finished Cleanup of Temporary Directories. May 01 11:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 11:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.175' (uid=0 pid=7903 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 11:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 11:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 12:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 12:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.177' (uid=0 pid=7948 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 12:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 12:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 13:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 13:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.179' (uid=0 pid=7974 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 13:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 13:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 14:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 14:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.181' (uid=0 pid=8001 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 14:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 14:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 15:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 15:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.183' (uid=0 pid=8028 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 15:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 15:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 16:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 16:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.185' (uid=0 pid=8066 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 16:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 16:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. May 01 17:00:24 localhost systemd[1]: Started Timeline of Snapper Snapshots. May 01 17:00:24 localhost dbus-daemon[1665]: [system] Activating service name='org.opensuse.Snapper' requested by ':1.187' (uid=0 pid=8092 comm="/usr/lib/snapper/systemd-helper --timeline > May 01 17:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 17:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. -- Reboot -- I also can't find anything relevant after the reboot; ay 01 17:00:24 localhost dbus-daemon[1665]: [system] Successfully activated service 'org.opensuse.Snapper' May 01 17:00:24 localhost systemd[1]: snapper-timeline.service: Succeeded. -- Reboot -- May 01 17:34:07 localhost kernel: Linux version 5.6.6-1-default (geeko@buildhost) (gcc version 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2] (SUSE Linux)) #1 SMP Wed A> May 01 17:34:07 localhost kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.6.6-1-default root=UUID=435f85e7-f149-4419-bbef-5c3bafe73add rd.timeout=60 splash=silent swapaccount=1 mitigation> May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256' May 01 17:34:07 localhost kernel: x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers' May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[5]: 960, xstate_sizes[5]: 64 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[6]: 1024, xstate_sizes[6]: 512 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[7]: 1536, xstate_sizes[7]: 1024 May 01 17:34:07 localhost kernel: x86/fpu: xstate_offset[9]: 2560, xstate_sizes[9]: 8 May 01 17:34:07 localhost kernel: x86/fpu: Enabled xstate features 0x2ff, context size is 2568 bytes, using 'compacted' format. May 01 17:34:07 localhost kernel: BIOS-provided physical RAM map: May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000008dfff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000000008e000-0x000000000008ffff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000000090000-0x000000000009ffff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000008ab10fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008ab11000-0x000000008ab18fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008ab19000-0x000000008b391fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b392000-0x000000008b3c5fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b3c6000-0x000000008b558fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b559000-0x000000008b559fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b55a000-0x000000008b6cefff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b6cf000-0x000000008b6cffff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000008b6d0000-0x0000000094695fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000094696000-0x0000000095733fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000095734000-0x0000000095736fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x0000000095737000-0x0000000096979fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x000000009697a000-0x00000000a0179fff] usable May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x00000000a017a000-0x00000000a0e79fff] reserved May 01 17:34:07 localhost kernel: BIOS-e820: [mem 0x00000000a0e7a000-0x00000000a3279fff] ACPI NVS . .....the entries continue for another 10 pages afterwards. I did not feel like they were necessary to include here for the sake of brevity. I shall further monitor the server and see if I can figure out what is making it reboot.
There is nothing which reboots MicroOS automatically except the update stack. Disabling transactional-update.timer should be enough.
Diabling rebootmgr has more the opposite effect: if something tries to reboot with rebootmgr, and it's disabled, it will do an immeadiate hard reboot instead. But except transactional-update I'm not aware of any other tool calling it.
Okay this was interesting! I will re-enable the rebootmgr despite nothing other than transactional-update calling it. Thanks, Mo. On Sat, 2 May 2020 at 13:44, Thorsten Kukuk <kukuk@suse.de> wrote:
On Sat, May 02, The Undertaker wrote:
That being said, it seems that there is still another reason for the server to reboot itself automatically. I regularly check the system uptime and it seems that in the week time that I have disabled the automated Transactional Updates the system still reboots once a week (Happened on Friday May 1st 17:34 local time).
You could look at the journalctl output, when the machine did reboot and if there is a reason logged why.
So, I would like to know if I am missing any other automated reasons why MicroOS would automatically reboot?
There is nothing which reboots MicroOS automatically except the update stack. Disabling transactional-update.timer should be enough.
Diabling rebootmgr has more the opposite effect: if something tries to reboot with rebootmgr, and it's disabled, it will do an immeadiate hard reboot instead. But except transactional-update I'm not aware of any other tool calling it.
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Sat, May 02, The Undertaker wrote:
I shall further monitor the server and see if I can figure out what is making it reboot.
You can look at /var/log/transactional-update.log to see, if transactional-update was still alive. Else I have no idea, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
On Sat, 2 May 2020 at 17:58, Thorsten Kukuk <kukuk@suse.de> wrote:
You can look at /var/log/transactional-update.log to see, if transactional-update was still alive.
I did check and there doesn't seem to be anything related there either. Still trying to the bottom of this, but I might be on to the root cause. After checking pretty much anything that I could think of decided to go into the server room and check the server in question when it restarted again. At that moment I believe I noticed spark sounds from the power strip feeding the server and not after wards. Did check the power strip and had it replaced. The server has been up and running for nearly three days now and no further restarts. I will let the server be for a while (week or so) before scratching this out and will report back. Thanks for all the help. -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
participants (2)
-
The Undertaker -
Thorsten Kukuk