[arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?

[C Anthony Risinger]

On Fri, Jul 27, 2012 at 4:53 PM, Tom Gundersen <teg at jklm.no> wrote:
> On Fri, Jul 27, 2012 at 11:39 PM, C Anthony Risinger <anthony at xtfx.me> wrote:
>> 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).
>
> Please file bugs if you think there are errors. Sometimes
> "Type=forking" is the right thing to do. If the daemon is not
> socket/dbus actiavted, then Type=forking is the only way to know if a
> service has finished starting.

ah, you/Mantas are probably correct here -- i didn't think about such
cases -- i don't seem to be using anything in such a way to be
negatively affected.

for most of my custom stuff i've tried to use out-of-band triggers
like sysfs files appearing/etc ... will explore this more, thanks.

>> ExecStop=-/bin/kill $MAINPID
>
> Hm, this should be uneccesary, no? If no ExecStop is configured the
> process will get a SIGTERM when the service is stopped.

ah yes, right right ... i mainly wanted to demonstrate the simplicity
of "not thinking in terms of rc.d scripts" ... which is now even
simpler thanks to your "you don't need anything at all" :-) hard to
get much more concise than "nothing".

-- 

C Anthony