I’m trying to run the odrive-agent as a systemd service as documented in the installation instructions. However, the application times out when attempting to start the service:
❯ systemctl --user start odrive.service
Job for odrive.service failed because a timeout was exceeded.
See "systemctl --user status odrive.service" and "journalctl --user -xe" for details.
And viewing the status effectively just says that the service is inactive.
Actually, it’s working now.
❯ systemctl --user status odrive.service
● odrive.service - Run odrive-agent as a user service
Loaded: loaded (/home/jrwrigh/.config/systemd/user/odrive.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2021-05-12 17:11:03 EDT; 48s ago
Process: 130567 ExecStart=/home/jrwrigh/.local/src/odrive/odriveagent (code=exited, status=0/SUCCESS)
May 12 17:10:50 T14ThinkPad systemd[1266]: Starting Run odrive-agent as a user service...
May 12 17:11:03 T14ThinkPad systemd[1266]: odrive.service: Succeeded.
May 12 17:11:03 T14ThinkPad systemd[1266]: Started Run odrive-agent as a user service.
I guess it just takes a little while for it to actually become active? Longer than systemd is used to? Maybe there’s a way to make systemd be a bit more patient?
Sure, I can try that. I’ve also noticed that systemd is actually starting and restarting the service over and over.
May 12 19:54:21 T14ThinkPad systemd[1266]: odrive.service: start operation timed out. Terminating.
May 12 19:54:21 T14ThinkPad systemd[1266]: odrive.service: Failed with result 'timeout'.
May 12 19:54:21 T14ThinkPad systemd[1266]: Failed to start Run odrive-agent as a user service.
May 12 19:54:26 T14ThinkPad wpa_supplicant[1123]: RRM: Ignoring radio measurement request: Not RRM network
May 12 19:54:26 T14ThinkPad wpa_supplicant[1123]: RRM: Ignoring radio measurement request: Not RRM network
May 12 19:54:31 T14ThinkPad systemd[1266]: odrive.service: Scheduled restart job, restart counter is at 97.
May 12 19:54:31 T14ThinkPad systemd[1266]: Stopped Run odrive-agent as a user service.
May 12 19:54:31 T14ThinkPad systemd[1266]: Starting Run odrive-agent as a user service...
Note the restart count at 97. That said, odrive is somewhat functional despite this, though commands can only take last a minute or so before the agent gets shut down.
I tried adding a TimeoutStartSec argument to the service definition file, but that lead to the same issues. How is odrive-agent communicating successful startup to systemd?
Edit:
To be explicit, my systemd service definition file is:
[Unit]
Description=Run odrive-agent as a user service
Wants=network-online.target
After=network.target network-online.target
[Service]
Type=forking
ExecStart=%h/.local/src/odrive/odriveagent
Restart=on-failure
RestartSec=10
TimeoutStartSec=2min
[Install]
WantedBy=default.target
The change in the service definition file did lead to a change in behavior. The start-stop cycle is around 3 minutes long instead of a little over a minute long. So that part at least appears to be working as expected. But systemd never gets a confirmation signal from the odrive-agent that is has successfully started, so it restarts the service.
Please correct me if I’m wrong, but I believe the issue is that the odrive-agent is not actually a “forking” process, at least by systemd’s definition.
A forking process expects the initial execution to exit with some exit code, and have the daemon be running on a different forked process. For example, ssh-agent, which is started by eval $(ssh-agent) which exits on command line, but still has the agent running in the background automatically.
Comparatively, odrive-agent (without systemd) requires that it be explicitly backgrounded via nohup. ie. not automatically by forking.
By changing Type=forking to Type=simple, the service starts successfully first time and (at least in the past 10 minutes) and I haven’t had any issues with long running commands.
Edit: This stackexchange answer has a good explanation of the differences.
Hi @jrwrigh.iii ,
You are correct. The odriveagent does not fork, so type should be defined as simple or exec.
I went back and looked at my own definition on one of my Linux instances and it is set to simple. I see that we have it as forking in our documentation, so I will correct that.
Sorry for the confusion and incorrect information there. Thanks for bringing it to our attention.