On Fri, Jul 27, 2012 at 4:04 PM, David Benfell
<benf...@parts-unknown.org> wrote:
> On 07/27/2012 02:01 PM, Tom Gundersen wrote:
>>
>> Not really, as far as I know. However, it seems that it is common
>> to put "helper scripts" that are shipped with systemd in
>> /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/,
>> so for user-created helper scripts, I think I'd put them in
>> /etc/systemd/.
>>
> That works for me. With some intervening logic to monitor the
> jobs--since systemd won't be able to monitor them itself--I think I
> can pull this off.
also note that you likely want to simply run the service differently
that you had previously.
for example, i modify several .service files -- even ones that are
shipped upstream -- because they are pointlessly configured as
`forking` when they could be much better integrated (ddclient, dhcpd,
hostapd, SEVERAL unfortunately) ...
eg, in general, PID files are not needed anymore, and logs should go
to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect
output (see man systemd.exec for stdout/err options, among others).
... then you can just:
ExecStop=-/bin/kill $MAINPID
.. and be done with it :-)
part of succeeding with systemd is recognizing that 3/4 of the @#$%
-required- before is not only -unnecessary-, but now a hindrance!
other notes from your pasted unit file:
- Exec* requires absolute paths to binaries
- $JAVA_OPTS is different from ${JAVA_OPTS}; the former is subjected
to word-splitting while the latter is not (see man bash)
--
C Anthony
