OMV8 upgrade - slow shutdown (s6-svscan)

1st Official Post

    I am planning to go for OMV8 but could not find any upgrade guide from 7 to 8.

    Can i assume using the process described here from 6 to 7 is still correct also for 7 to 8?

    Post
    RE: Is there a guide to in place upgrade?
    Contributions wanted:
    1. Backup the OS drive (this is allways a good idea, not only for upgrades)
    2. Make sure, you have enough free space on your os drive
    3. Check any installed plugins if they have been ported to OMV6
      If you are using plugins which have not been / will not be ported, get rid of the plugins except unionfs / mergefolderfs. These two will automatically be be converted to the newer mergerfs plugin
      (Many plugins can be replaced by docker containers. Do this before upgrading)
    4. If you installed
    …
    Zoki

    - OMV7 on Asus Prime N100 -

    Snapraid on 2 Data drives & 1 Parity

    latest proxmox kernel

    • Official Post
    Quote from monsen

    Can i assume using the process described here from 6 to 7 is still correct also for 7 to 8?

    I think that process is overkill. I just run omv-release-upgrade. I just upgrade seven omv7 systems and had no issues (other than nut plugin which has been fixed).

    omv 8.0.10-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.7 | compose 8.1.3 | cterm 8.0 | borgbackup 8.1.6 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Like 2

  • monsen

    Added the Label resolved

    There is one thing i remarked: shutdown takes a while after upgrade because the system is waiting for "s6-svscan" process.

    - OMV7 on Asus Prime N100 -

    Snapraid on 2 Data drives & 1 Parity

    latest proxmox kernel

    • Official Post

    That is running in a docker container. So, it is docker taking longer to shutdown.

    omv 8.0.10-2 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.7 | compose 8.1.3 | cterm 8.0 | borgbackup 8.1.6 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    yeah that is what my research pointed to. I think this was not the case before the OMV upgrade. I will try to pinpoint the container that causes it.

    - OMV7 on Asus Prime N100 -

    Snapraid on 2 Data drives & 1 Parity

    latest proxmox kernel

    Quote from monsen

    yeah that is what my research pointed to. I think this was not the case before the OMV upgrade. I will try to pinpoint the container that causes it.

    Let us know what the culprit is. I am seeing a 90 second hang during shutdown since upgrading to OMV 8.


    Code
    OMV 8 systemd-shutdown[1]: Waiting for process: 10046 (s6-svscan), 9988 (s6-svscan), 9965 (s6-svscan), 11948 (python3), 882573 (Plex Media Serv), 10031 (s6-svscan), 881402 (s6-svscan), 9984 (s6-svscan), 957120 (s6-svscan), 881448 (s6-supervise), 10737 (s6-supervise)

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

    Well i assume this could be fixed by running a shutdown script that stops containers with an S6 overlay before shutdown. But i struggle to find the causing containers up to here

    - OMV7 on Asus Prime N100 -

    Snapraid on 2 Data drives & 1 Parity

    latest proxmox kernel

    Could be a lot of work if you have many containers, but one way to find the causing ones is to stop all of them then reboot. It shouldn't hang at all. Then start them one at a time and reboot to see if that one causes a hang.


    I've fooled with this long enough and I surrender for now.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

    You might want to change the Subject of the thread to something that is more suggestive of what it has drifted into.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • monsen

    Changed the title of the thread from “Looking for upgrade guide 7->8” to “OMV8 upgrade - slow shutdown (s6-svscan)”.
    • Official Post

    monsen Have you seen this?

    Post
    RE: OMV 8 long pause while shutting down.
    I think this might be likely due to the recent e5b14c7 commit to the openmediavault-compose plugin, that added the Live Restore option to docker's daemon.json file.

    Over at the NixOS forums they discuss this option causing systems to hang at shutdown, with this person explicitly disabling it in their NixOS config to fix it.

    @axiauk  @gderf Could you see if you notice any difference to the hang time between using sudo shutdown -r now as compared with sudo reboot ?

    I wonder if maybe…
    gecko

    This might have helped. Problem is that my system is headless. I will have to plug it to a monitor to see if that message is gone. Will do in the coming days and report back.

    - OMV7 on Asus Prime N100 -

    Snapraid on 2 Data drives & 1 Parity

    latest proxmox kernel

    Quote from monsen

    This might have helped. Problem is that my system is headless. I will have to plug it to a monitor to see if that message is gone. Will do in the coming days and report back.

    You could try spamming ssh log-in attempts post reboot, and then compare between Live Restore being enabled and disabled how long it takes for the first successful login. By all accounts it can make a 90 second difference so should be testable without having to go to the trouble of attaching a monitor to your headless setup just to see if it worked.


    From the sounds of things though, I imagine disabling Live Restore will have solved your issue as it seems to have done for others.

    OpenMediaVault 7 running on RaspberryPi 5, 16GB RAM model, with Radxa SATA HAT. 2x 10TB HDD in ZFS Mirror. 1x 2TB HDD in ZFS Simple Mode.

    1x USB3 -> NVMe 256GB SSD, XFS formatted, for Docker Installation and Compose Data. 1x USB3 -> SATA 256GB SSD, EXT4 formatted, OMV Boot/Root Drive.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login