System hanging for about a minute at startup and shutdown

  • So on startup, I receive the following error.


    A start job is running for folder2ram systemd service (27s / no limit).

    The 27 seconds bounces back to 30s for about 30 seconds (never counts down to 0, goes down to like 25 at lowest then goes back to 30) and then will continue to boot like normal.


    When I go to shutdown, I am met with these errors.


    Failed unmounting /var/log.
    Failed unmounting /Home. (This is my ZFS mountpoint)
    Failed unmounting /var/folder2ram/var/log.


    The system will hang there for about a minute before finally shutting down. Does anyone have any ideas what could be causing this?

    Case: U-NAS NSC-810
    Motherboard: ASRock - C236 WSI Mini ITX
    CPU: Core i7-6700
    Memory: 32GB Crucial DDR4-2133

  • In the past I had such a delay during boot while a ZFS scrub was running in the background. But it was not related to folder2ram.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • @elastic


    Does your system run on an SD card?
    Because only then will folder2ram make sense...

    [LibreELEC @ 2x RPi3, CoreELEC @ S12 Octa Core]

    [ NAS OMV 5.xx (Usul) @ NanoPI M4 ]

    [ Nextcloud 18.0.4 @ ODROID C2 ]

    [ Motioneye @ RPi4]

  • In the past I had such a delay during boot while a ZFS scrub was running in the background. But it was not related to folder2ram.

    I disabled auto scrubs.

    @elastic


    Does your system run on an SD card?
    Because only then will folder2ram make sense...

    No it runs off of an SSD though and I remember a few people still recommending folder2ram for SSD's because of the frequent writes the OS makes.

    Case: U-NAS NSC-810
    Motherboard: ASRock - C236 WSI Mini ITX
    CPU: Core i7-6700
    Memory: 32GB Crucial DDR4-2133

  • This delay is to be expected if you are running the Flash Memory Plugin. Are you?

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


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Yes. I am running the Flash Memory Plugin.


    So is this an expected behavior?

    Can I rest at ease without worrying about filesystem failure/corruption? It seems the system always performs a filesystem check on boot since it fails to unmount these partitions.


    Is there any documentation I can refer to about these unmounting issues?

    Thank you!

    • Offizieller Beitrag

    So is this an expected behavior?

    If your system has a lot to sync at shutdown and/or you have slow storage, yes.


    Can I rest at ease without worrying about filesystem failure/corruption? It seems the system always performs a filesystem check on boot since it fails to unmount these partitions.

    They aren't partitions. The flashmemory plugin creates tmpfs filesystems to avoid writing to the disk. These filesystems are sync'd to the disk on shutdown (or click the sync all button in the flashmemory plugin). If your system generated a lot of changes/files in the tmpfs filesystems or you have slow storage, that sync will take a long time at shutdown and potentially time out. I would click the sync all button in the flashmemory plugin and then see if you have the same issue shutting down. Hopefully not since most things should be sync'd.

    omv 7.4.2-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.1 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    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!

  • * Solved *
    Thank you for the clear explanation.

    Forcing the flashmemory plugin to sync solved the issue.


    Also, the time-out came from a very slow USB stick.


    Lessons learned:

    - Always benchmark your usb sticks for write speeds.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!