I’ve got a QNAP NAS and two Linux servers. Whenever the power goes down, the UPS kicks in and shut downs the NAS and the Linux servers, all good. The servers + NAS are automatically started when the power comes back on line using WOL. All good.

The problem is that I have apps running using Docker which heavily rely on connections to the NAS. As the Linux servers boot quicker than the NAS, the mount points are not mounted, and thus everything falls apart. Even when I manually re-mount, it’s not propagated to the Docker instances. All mount points use NFS.

Currently, I just reboot the Linux servers manually, and then all works well.

Probably easiest would be to run a cron job to check the mounts every x minutes, and if they are not mounted, then just reboot. The only issue is that this may cause an infinite loop of reboots if e.g. the NAS has been turned off.

I could also install a monitoring solution, but I’ve seen so many options that I’m not sure which one to do. If it’s easier with a monitoring solution, I’d like the simplest one.

Avid Amoeba
link
fedilink
English
29
edit-2
9M

This is the answer. You can straight up make things dependent on .mount units that represent stuff in fstab. To add, you can create any number of systemd services that just check if something is “as you want it” and only then “start”. You simply make the Exec line “/bin/bash -c ‘your script here’”. Then you make whatever else you want dependent on it. For example I have such a unit that monitors for Internet connection by checking some public DNS servers. Then I have services that depend on Internet connection dependent on that. Here’s for example my Plex service which demonstrates how to depend on a mount, docker and shows how to manage a docker container with systemd:

~$ cat /etc/systemd/system/plex-docker.service
[Unit]
Description=Plex Media Server
After=docker.service network-internet.service media-storage\x2dvolume1.mount
After=docker.service

[Service]
TimeoutStartSec=0
Restart=always
RestartSec=10
ExecStartPre=-/usr/bin/docker rm -f plex
ExecStartPre=/usr/bin/docker pull plexinc/pms-docker:latest
ExecStart=/usr/bin/docker run \
        --name plex \
        --net=host \
        -e TZ="US/Eastern" \
        -e "PLEX_UID=1000" \
        -e "PLEX_GID=1000" \
        -v /tmp:/tmp \
        -v /var/lib/plex/config:/config \
        -v /var/cache/plex/transcode:/transcode \
        -v "/media/storage-volume1:/media/storage-volume1" \
        plexinc/pms-docker:latest

[Install]
WantedBy=multi-user.target

BTW you can also do timers in systemd which allows doing what you can do with cron but much more flexibly and utilize dependencies too.

Sam Black
link
fedilink
English
109M

You can use RequiresMountsFor= (eg RequiresMountsFor=/media/storage-volume1) instead of manually adding .mount to After/Requires - you can then use .mount files or fstab as you’re stipulating the path rather than a potentially changeable systemd unit name.

The systemd.mount manpage also strongly recommends using fstab for human added mount points over .mount files.

Avid Amoeba
link
fedilink
English
19M

Oh this is nice. I’ll probably start using it.

@sylverstream@lemmy.nz
creator
link
fedilink
English
29M

That’s interesting! I’ve converted all my docker run commands to docker compose, as I found that easier to manage. But, I guess you can’t do the dependencies like you have. Also, yours has the advantage it always pulls the latest.

qaz
link
fedilink
English
19M

Perhaps you could also add the mounts as dependencies to the Docker daemon.

key
link
fedilink
English
29M

Doesn’t seem mutually exclusive. Replace the docker rm with compose down and the docker run with compose up.

Avid Amoeba
link
fedilink
English
1
edit-2
9M

Exactly. In fact I have a few multi-container services with docker-compose that I have to write systemd unit files for.

Create a post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

  • 1 user online
  • 191 users / day
  • 419 users / week
  • 1.14K users / month
  • 3.85K users / 6 months
  • 1 subscriber
  • 3.71K Posts
  • 74.6K Comments
  • Modlog