CODEWITHSUNDEEP
portabilityinitupstartsystemd
guettli
guettli

Reputation: 27069

Portable Init Script?

How to write a portable init Script which works with

Other platforms (Windows, Android, OS-X) are not important in my context.

Upvotes: 3

Views: 319

Answers (2)

Doncho Gunchev
Doncho Gunchev

Reputation: 2239

Both systemd and upstart support sysinit style scripts. RHEL 6 uses upstart but most scripts are normal init.d bash scripts. RHEL 7 and Fedora 19 (and earlier) use systemd, but they happily run old init scripts.

You can use normal old style daemon that forks with init script. If the application does not fork on its own you can use something like supervisord to do the forking for you and directly integrate with separate systemd script. I do not know details about upstart except it uses it's own format, but supporting it (if you do not have to support old/current linux systems) seems reasonable only for non-linux distributions. systemd is currently Linux specific, though I've seen work being done to port it to BSD.

You may be interested in how they integrated CUPS. Last time I checked the systemd "script" starts the daemon with -f option (foreground) - ExecStart=/usr/sbin/cupsd -f. The init.d script does not add that flag.

In short - for now use old style System V init.d script if you want one solution that works everywhere. Add systemd support if you have some spare resources and if you have enough, you can certainly support the three systems separately (greatest benefit for the users, but a lot of work).

I'd personally create init.d + systemd scripts and would not care about upstart. Chances are systemd will soon replace upstart (also look here) and init.d scripts will remain usable on the rest of the UNIX-es.

Upvotes: 2

Sergey Kanaev
Sergey Kanaev

Reputation: 592

As far as I know systemd allows to run init.d scripts, so you can do a script that is portable with upstart and init.d.
The other thing is that all of them (systemd, init.d, upstart) uses its own syntax. The only solution I see is to create three different scripts that call some application of the most common service interface - a forking service application. That way all of the managers will know how to handle your service. And provide your application with all three kinds of scripts. Then, installer will have to choose what script is to be installed with your service application.

Upvotes: 1

Related Questions