On April 4, 2015 12:14:08 PM EDT, Pete Travis <lists at petetravis.com> wrote:>On Apr 4, 2015 7:55 AM, "J Martin Rushton" ><martinrushton56 at btinternet.com> >wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Thanks Andrew. >> >> One more problem solved, as I discovered last thing yesterday there >> was a missing "[Install]". Using your copy of the httpd service I >> cut-and-pasted it onto the end of the service file you'd given me >> earlier and at last was able to load the service. It wouldn't run, >> but at least it was some progress. >> >> I ran systemctl daemon-reload and rebooted. >> >> It is still failing though: >> >> # systemctl status timidity >> timidity.service - timidity daemon >> Loaded: loaded (/etc/systemd/system/timidity.service; >enabled) >> Active: failed (Result: exit-code) since Sat ... >> Process: 955 ExecStop=/bin/kill -s TERM $MAINPID >(code=exited, >> status=1/FAILURE) >> Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, >> status=0/SUCCESS) >> Main PID: 790 (code=exited, status=0/SUCCESS) >> > ><snip> > >The process exited, so systemd thinks the service has exited. You have >a >'-D' option, which probably means daemonize, but you haven't set an >appropriate Type declaration in the service file. > >If the service offers it, the best way to do simple services with >systemd >is with *foreground* options in ExecStart. Then set Type=simple. >STDOUT/STDERR all goes to the journal, making it easier to see what >happens >if the service legitimately fails. > >Take a look at packaged files in /usr/lib/systemd/system - plenty of >examples to work from. > >--Pete >_______________________________________________ >CentOS mailing list >CentOS at centos.org >http://lists.centos.org/mailman/listinfo/centosIs $MAINPID defined in your pidfile? It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined. -- Jonathan Billings <billings at negate.org>
On 4 April 2015 at 18:40, Jonathan Billings <billings at negate.org> wrote:> > > On April 4, 2015 12:14:08 PM EDT, Pete Travis <lists at petetravis.com> wrote: >>On Apr 4, 2015 7:55 AM, "J Martin Rushton" >><martinrushton56 at btinternet.com> >>wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Thanks Andrew. >>> >>> One more problem solved, as I discovered last thing yesterday there >>> was a missing "[Install]". Using your copy of the httpd service I >>> cut-and-pasted it onto the end of the service file you'd given me >>> earlier and at last was able to load the service. It wouldn't run, >>> but at least it was some progress. >>> >>> I ran systemctl daemon-reload and rebooted. >>> >>> It is still failing though: >>> >>> # systemctl status timidity >>> timidity.service - timidity daemon >>> Loaded: loaded (/etc/systemd/system/timidity.service; >>enabled) >>> Active: failed (Result: exit-code) since Sat ... >>> Process: 955 ExecStop=/bin/kill -s TERM $MAINPID >>(code=exited, >>> status=1/FAILURE) >>> Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, >>> status=0/SUCCESS) >>> Main PID: 790 (code=exited, status=0/SUCCESS) >>> >> >><snip> >> >>The process exited, so systemd thinks the service has exited. You have >>a >>'-D' option, which probably means daemonize, but you haven't set an >>appropriate Type declaration in the service file. >> >>If the service offers it, the best way to do simple services with >>systemd >>is with *foreground* options in ExecStart. Then set Type=simple. >>STDOUT/STDERR all goes to the journal, making it easier to see what >>happens >>if the service legitimately fails. >> >>Take a look at packaged files in /usr/lib/systemd/system - plenty of >>examples to work from. >> >>--Pete >>_______________________________________________ >>CentOS mailing list >>CentOS at centos.org >>http://lists.centos.org/mailman/listinfo/centos > > Is $MAINPID defined in your pidfile? > > It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined. >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. 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. 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. 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. https://wiki.archlinux.org/index.php/Timidity#Daemon 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. If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <snip>>> The process exited, so systemd thinks the service has exited. >> You have a '-D' option, which probably means daemonize, but you >> haven't set an appropriate Type declaration in the service file. >> >> If the service offers it, the best way to do simple services >> with systemd is with *foreground* options in ExecStart. Then set >> Type=simple. STDOUT/STDERR all goes to the journal, making it >> easier to see what happens if the service legitimately fails. >> >> Take a look at packaged files in /usr/lib/systemd/system - plenty >> of examples to work from. >> >> --Pete _______________________________________________ CentOS >> mailing list CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos > > Is $MAINPID defined in your pidfile? > > It sounds to me like only the 'kill' is exiting with a non-zero > exit code because the variable is undefined. >Taking the above in order: 1) Yes the "D" does mean deamonise, as I mentioned previously. However it is not -i -A -D, but -i (interface is) A (Alsa, modified by) D (run as a deamon). Confusingly -D on its own refers to the drum channel. 2) -iA reads a file name as argument 1 and plays that. -iAD sets up sequencer ports to which an external program can write. 3) I've use Type=forking, with some success - see below. 4) pidfile wasn't being created. When I tried a startup the command hung for several minutes before returning with and error message. Also for the first time I was seeing output from timidity in messages. There was the usual clutch of SELinux messages, and although I am running permissive during test I created the policy modules to stop them. The status showed that systemd could not read the pidfile, then it claimed that timidity had timed out. Next timidity logged its successful startup mesages before systemd claimed to have failed to start it! Just out of interest I touched the pidfile and chmod'ed it 777. Suddenly it all worked! Systemd is spawning off timidity as user jmr, and timidity was not then able to create a file in /var/run. Failry obvious once you see it. So: Thanks to all who have helped. The principle lessons learnt seem to be: 1) Irrespective of the README in /etc/init.d, traditional init scripts will not work unless they fit some assumed and undocumented model. Do not waste time trying to use them. 2) /etc/systemd/user is borked in my version of CentOS: systemctl doesn't read files from there. 3) systemd must never be considered a simple replacement for init files, any attempt to use it in the same way is doomed to failure. You need to allow a few man-days to achieve success. Hopefully the time needed will reduce with experience, but I'll certainly not be upgrading any production servers until I'm forced to! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVID9WAAoJEAF3yXsqtyBlCw0P/1N9PpMZ8MYlVljW1qPd4A9z dblOiS/lerhx2GkqJZXbMCaJg1k5W54HUj8LztaNQhi4+B9GC2p2/PY1Gz3zAU4f rryfi6yVffeEAgw2FlrtJXCPn9pgjr6tr2JZH+2dM2zqEp4UYLpbPmjNBrrkAzsm najv0+05GTEMHKxMSQR8eKOfF02u7ccGJ68LvZUdJ2kGgCW9z7/lZcbCHQEc2NCS 06FiDTa2XmOk6i8RTpoIgpQ70ZGRZF7mP8IArRjvusmdvfGuwKoNgFdYiEtsVZIQ +vHGyq20/SG/XnW83OpJ4gmDnA7wdpMY+InqA+UuPpz+yaP75MM5qF+fcAqTOE2N 1kAbe1x/z5FhVzRg8v758+TPW6zGX09w/wglaXrEWLMrI2WjSHr1nbaAUsZm+OkK DYWcncf+Uj4XjNtL9UzdlmwlD2m3MgPVCAnoRQ8ncA4OMWkoll+vjkK1w6FngRo/ oMqnv+5g6gqDZVzc6VEBMObGTlizL74tiSiY1Fk0X5IiIH2CEMOzpGbXM1XMxh5C dYG6VMfen6KaISRJplUhq8LJLm0s/Ntkz77wRjnKDV3rRJsrZygLCgP/qFrDhwF8 HtoZ1IOpe4bfyeUTpduOz5AAZfHTZAOkxdKgBus4WuSMYOeqcZZgoR7WvKXL4PA8 ae5VpcKDuhghLqc8ZhRF =ZJ7p -----END PGP SIGNATURE-----
-----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. > > https://wiki.archlinux.org/index.php/Timidity#DaemonThanks.> 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 > timidityNo - I want it to start on boot and sit there like a good little daemon doing what it's told.> _______________________________________________ CentOS mailing > list CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVIETbAAoJEAF3yXsqtyBluCMQALQmXr1j79saRLd3ulUD5L2W rF3dZ4GCLwWJMlCE9ITwJZE5afimlYWLBsQXRDbdw+EZ8xLrUNfmL4aiGW77LIoK cpkC1G/t3ZShUNjuu3pE4qxvBzSN3juLK8E9losaLKlpGaPlzqgVynZamyxX4kWp PHTQM1tyOh8lcZcjvb2nn81A0fWKHzzi9aXHDFsejsntFUd0QzsKkFOuXLHJNY/P yynX9fyiQ+1EvbjKL+i5ckMKMQg2ozdhTWzVtWqEZEHKu6ouaK+9+kiYM7k2Wy78 XrM/ccp/fEjMIcd8csaydg6N76oGrwGFhoIpuwbfk28wSiPX+RG1hmUN2zzXMNzw XN5scxJpBnpsKGB6WmUHw7ELK04r26orO1hPJW//4voYWyT5kIC2vg4d2viPuHgD zg7ogmUrTZAOa2Fh1dUXkYwLZyjT97hbteIj/hJBvpRJ42Gupnh5YDFmV29s1y8L OnFKy4iBSn0dEHspkHDaHBXEPOkqwcSf0p1gfGG7QTP2CdeUeKq8nj/BbMYRPDpy KsP7f6A0+xRTh+WTm74A1W4xGM9RIK58yoZ0+DcT318VvzjkVtYmbEILBjtz3Ag9 eiRWLLNiJvVn2tWBf5+p8YkELiJQknWk9bglYf9jmLzAegOm79QUwg53QGLMJ3Li fTqMaOEqRUyJF6XOSY+9 =yqOD -----END PGP SIGNATURE-----
On Apr 4, 2015, at 3:45 PM, J Martin Rushton <martinrushton56 at btinternet.com> wrote:> 2) /etc/systemd/user is borked in my version of CentOS: systemctl > doesn't read files from there.It does. If you use systemctl --user. But you're not using the userspace systemd to run this, you're running the system systemd, so there's no reason to ever touch /etc/systemd/user/. It may be possible to do what you want with a 'systemd --user' process, but as you've described in another email, you don't want it running with your user session, you want it as a daemon. -- Jonathan Billings <billings at negate.org>