Closed sugoidogo closed 2 years ago
Initially that was how I designed the unit, but run.sh uses the -d option, which if I recall correctly is the daemon flag, meaning the command exits after the container has started. Normally that's not an issue and the unit can simply use forking mode to have systemd continue tracking the process, but in the case of docker it's not forked from the tracked process, it's a pre existing daemon, so systemd would have no way of tracking the run state of expanse. That's one of the reasons I wanted to remove docker as a requirement and instead have it as an optional deployment method, but I could also just add a --no-daemonize
flag to the run.sh and use that in the systemd unit instead.
Sorry I think i resolved an edit of yours by accident, I'm going out to dinner right now but I'll review again once I get back.
Sorry I think i resolved an edit of yours by accident, I'm going out to dinner right now but I'll review again once I get back.
ok, i unresolved it
Since $PWD
doesn't include a trailing slash, the regex in the README functions as intended without changes, but explicitly relative paths are not supported in systemd.
sugoidogo@dev:~/expanse$ sudo systemctl enable ./expanse.service --now
Created symlink /etc/systemd/system/expanse.service → /home/sugoidogo/expanse/expanse.service.
Created symlink /etc/systemd/system/default.target.wants/expanse.service → /home/sugoidogo/expanse/expanse.service.
Failed to start expanse.service: Unit expanse.service has a bad unit file setting.
See system logs and 'systemctl status expanse.service' for details.
sugoidogo@dev:~/expanse$ sudo systemctl status expanse.service
○ expanse.service - fully selfhosted multi-user web app for externally storing Reddit items (saved, created, upvoted, downvoted, hidden) to bypass Reddit's 1000-item listing limits
Loaded: bad-setting (Reason: Unit expanse.service has a bad unit file setting.)
Active: inactive (dead)
Docs: https://github.com/jc9108/expanse
Sep 27 05:19:31 dev systemd[1]: /etc/systemd/system/expanse.service:11: Neither a valid executable name nor an absolute path, ignoring: ./run.sh
Sep 27 05:19:31 dev systemd[1]: /etc/systemd/system/expanse.service:12: Neither a valid executable name nor an absolute path: ./run.sh
Sep 27 05:19:31 dev systemd[1]: expanse.service: Unit configuration has fatal error, unit will not be started.
systemd will search for the executable (in this case run.sh
) in the WorkingDirectory
and PATH
only, otherwise absolute paths must be used. There are two solutions to this:
/opt/expanse/
) to all Exec*
entries, so that they are edited along with WorkingDirectory
by sedLet me know how you want me to proceed.
for option 1, did you mean explicitly relative paths?
anyways, i prefer if you go with option 2. you can also get rid of line 10 (WorkingDirectory
) if you do this, no?
Yes, I did mean explicitly relative, my mistake. Working directory is still needed because the run script uses relative paths, without it those commands will be run in the root directory.
Now working as intended on my end. Added a step to the systemd section of the readme to make sure run.sh is executable and committed the executable bit to the repo.
my mistake, been up all night. Currently 6 am where I'm at.
np, thanks for your contributions
sorry one more thing, if you already made run.sh
executable by default, can't we take out step 3 in the new readme section?
Git will mark it executable if the repo is cloned, but if they download it via http as a zip file I'm not sure it will be. It's also an extremely common point of confusion when using scripts in service files, so keeping that line is likely to reduce a lot of support requests for EXEC
errors in systemd.
thanks for this. can you make it use the
run.sh
commands instead? so the commands arent repeated in 2 places, and if there are changes to the commands they will be automatically updated here too. e.g.,sh ./run.sh prod update
to replace lines 11 and 12 inexpanse.service
and etc ?