Could you expand on that? Are you suggesting it could be a different service file causing this? Or a larger issue with systemd itself?
not sure if this matters but this command does not have a leading
- that @random404 had mentioned was needed?
Process: 595 ExecStartPre=/bin/fusermount -uz /home/craftyclown/Skull (code=exited, status=1/FAILURE)
You'd have to examine your setup and see what systemd is doing.
Are you using Requires or Wants in another service file?
You can add in:
To your service and see if that one is actually causing the issue or it's some interaction with another service.
You can change Restart=on-failure to no so it does not restart.
For some reason the leading - doesn't show on the status, despite it being in the script. I posted my script and the status next to each other to show the usage. I think the error on the status is the intended outcome as it is unable to find an existing mount to clear. that said I don't think this is even necessary as it is the left over processes rather than the mount causing the issue.
@Animosity022 what you are suggesting makes most sense, ie some kind of IO process is hanging onto the mount and causing it not to disconnect cleanly, leaving processes behind. Docker is definitely one of the causes of this, but I need to find out what else is doing it.
All this said, I do want to carry on using docker and an rclone mount, so would there be a way of checking for left over processes and clearing them, either when the mount is stopped or when it restarts?
So the challenge is it depends on what's going on via the system.
If you have a mount and the process is killed, things still hang onto that mount point if they are running or in this case, timing out on IO and you get into an odd state which at times, you may have to bounce the server to get things back to normal depending on what is hanging onto it.
They gave a few suggestion with pre checks but your issue feels pretty unique as I can't easily explain what could do that as I've not seen it before.
That output leds me to believe that systemd is doing as systemd is tracking the extra process. Without debug logs for systemd, it's tough to guess or even suggest what to look at as the situation is just bizarre.
If you recreate the issue, you'd want to check those two processes and see and maybe trace what time they started and check the systemd logs via debug and try to see what's going on.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.