[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Two line init.d scripts? Sure, that will work!

Petter Reinholdtsen <pere@hungry.com> writes:

> The reason I bring this up on debian-devel@ is twofold.  First, I want
> to gather feedback on the idea.  Will it work for your package, or are
> some more hooks needed?

With my syslog-ng upstream hat on: please, for the love of $deity, no!
It's bad enough having to care about three init systems on Linux, then
some more on the BSDs, and not break legacy unixes either.

With my syslog-ng debian maintainer hat on, I honestly do not want to
deal with even more (and since I provide backports, I can't just abandon
the old init script for the foreseeable future, either).

Also, pushing complexity into a common script would only mean that if,
for some reason, it needs a fix that only syslog-ng triggers, I'm
screwed, and need to fall back to a full-blown script anyway. Having had
a look at the current sysvinit file of syslog-ng, I'd fall back there
anyway (mostly for the silly dance done in syslogng_wait()).

The idea is nice in theory, but unless you go the full mile, and do a
truly declarative syntax like systemd, from my point of view, it will be

As a comparsion, here's the systemd unit file (15 lines including blanks):

| [Unit]
| Description=System Logger Daemon
| Documentation=man:syslog-ng(8)
| [Service]
| Type=notify
| Sockets=syslog.socket
| ExecStart=/usr/sbin/syslog-ng -F
| ExecReload=/bin/kill -HUP $MAINPID
| StandardOutput=null
| Restart=on-failure
| [Install]
| WantedBy=multi-user.target
| Alias=syslog.service

Or the upstart service thingy (which I actually have never tried), which
is 9 lines including blanks:

| description	"system logging daemon"
| start on filesystem
| stop on runlevel [06]
| expect fork
| respawn
| exec syslog-ng --process-mode=background

I assume an OpenRC init file would be similarly short.

What would your solution buy me, that neither systemd, nor upstart do?
Both which of those provide me features not present in sysvinit, which
are tremendously useful for my use cases.


Reply to: