Just a quick reaction - I am fine with rewriting the scripts using
/etc/init.d/skeleton if it's a better fit.
Or we can simply add a custom:
do_status_override() {
status_of_proc "$DAEMON" "$NAME" -p "$PIDFILE"
}
that would implement the missing things.
And I think I found the most obvious error -> I intended to override
do_start_cmd and do_stop_cmd instead of do_start and do_stop functions
in the init-d-script-courier, and that would fix the missing logging and
probably the error codes as well.
Cheers,
--
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
On Wed, Apr 27, 2016, at 08:38, J Mo wrote:
>
> Most of the problems that I've found so far are actually bugs in
> init-d-script. The rest are between init-d-script and
> init-d-script-courier _override() functions not replicating needed
> functionality.
>
>
>
> Before I started looking into this, I had never heard of
> /lib/init/init-d-script before.
>
> The first thing I did was to find out who else was using it in their
> init scripts. The answer for me turned out to be almost nobody. Of the
> nine different hosts I looked at, I could find only one other package
> which used it: apache2's apache-htcacheclean, for cleaning up after
> mod_cache_disk. And even there it's not really comparable because of the
> very limited function it performs. The main apache2 init script doesn't
> use init-d-script.
>
> And since nobody apparently uses it, it didn't surprise me when I
> started finding bugs. See bug #822674 for our current most significant
> issue. Nothing will work until that gets fixed or worked around.
>
> It does not help that PIDFILE is missing from all of the init scripts,
> except for courier-authdaemon, where it's wrongly declared as
> PIDFILE="/run/courier/pid". Thus, init-d-script is looking for the
> PIDFILES in all the wrong locations. This will have to get fixed too,
> but won't make a difference because of the above mentioned bug.
>
> The "exit 0" at the end of init-d-script is probably also a bug as it
> destroys almost all return codes. I have like five other issues which
> might get turned into bugs once I've had a second look at it tomorrow.
>
>
>
> Using /etc/init.d/skeleton as a template may have seemed like a
> reasonable place to start to write a new init script, but I don't know
> if it's worth working around the issues I've found so far. I'm already
> using my own init script replacements so things will work.
>
> The Courier suite, being as weird as it is, also makes it a poor
> candidate to fit into a per-defined structure like init-d-script
> provides.
>
>
>
> Most of our other issues are that functionality normally expected isn't
> in the init-d-script-courier _override() funcs. There's no start/stop
> logging, no stdout, etc. That's all fixable though.
>
>
>
> I will look at this more later in the week and send you some proposed
> changes. I'm not sure if init-d-script should be ditched or not yet. I
> like the idea of a uniform init script, but the issues I've found so far
> explains why nobody is using it.
>
>
>
>
> On 04/21/2016 02:38 AM, Ondřej Surý wrote:
> > Please read /lib/init/init-d-script (and
> > /usr/lib/courier/init-d-script-courier) first and then come back again.
> >
>
