-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
<snip>
This would be better served as the following to accomplish the immediate goal:
cat > /etc/systemd/system/timidity.service <<EOF [Unit] Description=timidity daemon
[Service] User=jmr Group=users WorkingDirectory=/home/jmr Type=forking ExecStart=/usr/bin/timidity -iAD EOF
systemctl daemon-reload
systemctl start timidity
You don't need to define an ExecStop and the type of the service should be forking as you are daemonising it - simple if you didn't daemonise it (or skip type which has this as default).
There is also no need to deal with the race condition mess that is a PID file with systemd as well... technically there is no need to mess with MAINPID in this scenario.
Points noted, I just took Andrew's file and changed the bare minimum.
This is a quite messy though as you're running a 'system service' in the context of a regular user.... you were better off doing this within the user space as you started with.
It's getting rather windozy though if proper background system stuff is moved into user space. Multiple definitions of the D: drive anyone? :-(
Running as jmr is purely temporary, ideally I will create a timidity account for it, but for the present I just hacked Andrew's script to ensure the user/group/directory worked.
The reason that failed for you before is that you were making calls to systemctl without the --user option so it was trying to act in the system context.
Right, so user is user added code then. I assumed it was for site-local service files.
However a google of "timidity systemd" has the arch wiki within the first few results that has good information which results in a technically much nicer solution.
Thanks.
Note the --global option which makes it start on a per user basis when the session for that user starts. Also note they don't daemonise it as there is no real reason to with systemd controlling the process state.
It does need to be daemonised for frescobaldi to talk to it. The default (non-daemonised) way plays a file, if it is daemonised then it sets up ports to listen on. Hence the D modifier on the interface switch. I'll be honest though, when scanning for CentOS solutions I would routinely ignore ArchLinix.
If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity
No - I want it to start on boot and sit there like a good little daemon doing what it's told.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos