[CoreOS] IntelNUC takes extremely long to poweroff

Hi there,
im using my IntelNUC as HomeServer running Docker and only mounting volumes via nfs directly from within my docker-compose files → So nothing is mounted via fstab or something

As i poweroff my server with e.g. sudo systemctl poweroff it needs forever to really poweroff

Seems to be stuck on systemd-shutdown (see photo of my little debugging screen used for my server-rack)

What can i do about these services preventing my server to really poweroff

Listed services are e.g.:

  • 5x s6-svscan
  • tini
  • tail
  • run-document-se
  • python
  • gotenberg
  • uwsgi

Do any of the systems that access this server have files open?
Are any files open in the nfs volumes?

Shutdown in those cases may be forced to wait for the files to be closed – either forcefully or gracefully.

Good question …

On my intel NUC with CoreOS are tons of Docker Containers running

Its my homeserver and therefore it has many many different services

But in general

  • Only the IntelNUC with CoreOS is accessing my TrueNAS SCALE NAS
  • Nothing is accessing my IntelNUC via NFS
  • I only access the services running on the IntelNUC via Browser mainly
  • The moment where the shutdown is stuck, docker should already be shut down because this is part of the shutdown process???

So i think my answer should be NO → Noone accesses the IntelNUC via NFS, the NUC only accesses my (always running) NAS via volume mount in docker-compose

Thank you for taking the time

If file systems are mounted or files are open with nfs the shutdown must wait until the devices are properly disconnected. I suggest that you revise the shutdown process to close down all the mounted file systems (docker containers) and services before actually trying to shutdown the NUC.

None of those services come from Fedora CoreOS but likely from applications that you run in Docker containers. You should probably look at what’s blocking them from stopping properly.

OK,
thanks for your hints!

I tried to add

{
  "shutdown-timeout": 30,
}

to the /etc/docker/daemon.json file and it seems to work

I just want it to shutdown even if some services are still doing stuff → Right now my only solution was anyways a hard poweroff via long-press of the power-button

You certainly can always do a hard shutdown that way.
When doing so you always run the risk that something, somewhere, may become corrupted by doing a forced power-off shutdown in that manner.

Hi,
I don’t know how you manage your containers
I did have some issues with container stop managed by systemd services and give a look to KillMode (none, mixed, process, …) the Type (forking, notify, …) that help systemd to know how to stop a container in a safe way
e.g., to stop my jenkins container in a safe way i had to set :

        [Service]
        Environment=PODMAN_SYSTEMD_UNIT=%n
        Restart=on-failure
        TimeoutStopSec=30
        Type=notify
        KillMode=mixed
        NotifyAccess=all
        ExecStart=/usr/bin/podman run \
          --log-driver=journald \
          --detach \
          --rm \
          --replace \
          --name=%N \
          --sdnotify=conmon \
          --pod=pod-jenkins \
          --label="io.containers.autoupdate=registry" \
          -e JENKINS_OPTS="--sessionTimeout=120 --sessionEviction=3600" \
          -v /run/mount/backup:/backup \
          -v jenkins:/var/jenkins_home \
          docker.io/jenkins/jenkins:rhel-ubi9-jdk17
        ExecStop=/usr/bin/podman exec jenkins java -jar /var/jenkins_home/jenkins-cli.jar -auth @/var/jenkins_home/jenkins-cli-token -s http://localhost:8080 -webSocket safe-shutdown

The ExecStop start a safe shutdown process
Type=notify is allowed as the process implement the notify interface, if not, systemd is never notified of service shutdown and wait for a long time …
and so on …

you can play with different options that let your container start and stop with systemd in a really clean way