I looked at your new init-d scripts and the referenced bugs, and I am
not convinced we need to go to shell spaghetti again, as:

- Re #822753, see #208010 - there's no Debian policy on init.d script
exit codes unfortunately, so init-d-script is compliant.

- Re #822674 - this is easy to fix, by adding do_status_override() in
init-d-script-courier.

So in the end, I think this patch is all that's needed to make
do_status() work:

https://anonscm.debian.org/git/collab-maint/courier.git/commit/?id=0d998590ca2e02a263de14a0147e1fcf6ba871bd

And I added NEWS.Debian to courier-mta package about the split:

https://anonscm.debian.org/git/collab-maint/courier.git/commit/?id=d6aa0d670db053782ffab9c94b6882881ada773d

Please open individual bugs about the init scripts if you find that
something doesn't work as it should as I think the currents script
mirror the behavior of the scripts you sent 1:1.

Cheers,
-- 
Ondřej Surý <ond...@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Sun, May 8, 2016, at 02:57, J Mo wrote:
> 
> Hi
> 
> Sorry I've been silent. My linux desktop motherboard died about a week 
> ago and I had to deal with issues surrounding that.
> 
> Here are the init scripts which I am currently using. These work for me:
> 
> http://jmomo.net/files/courier-init/
> 
> If you find any problems let me know and we can work it out. Keep an eye 
> out for any bash-isms I might have missed.
> 
> 
> 
> Notes/thoughts:
> 
> I am not using any other parts of the courier suite. I would not mind 
> looking at all of those and doing it but I'm not sure I have the time 
> right now. I'll add it to my TODO list and let you know if I get around 
> to it.
> 
> These don't use the init-d-script method because bugs #822753 and 
> #822674 break it for us. I don't think init-d-script is usable. I like 
> the idea but it has multiple serious bugs and is abandoned by it's 
> authors as far as I can tell. Fixing and testing would take a lot of 
> work and it's pretty obvious that basic LSB/Debian policy testing was 
> never done.
> 
> I'm not sure what the original motive was for splitting up courier-mta 
> into courier-mta, courier-msa, courier, and courier-filter, but I kept 
> it that way. However, this is a behavior change which is worthy of a 
> NEWS item by itself. People who expect configuration to be reloaded by 
> using courier-mta are not getting what they used to get.
> 
> courierd itself does not create a PID file, so getting status on it is 
> non-ideal, but it works. This is an upstream issue.
> 
> courier-authdaemon status can not be obtained by a non-privileged user 
> due to directory permissions. This is consistent with prior behavior.
> 
> Those init scripts may need to consider if upstart or systemd is in use 
> on the system and behave appropriately. I don't know what official 
> policy is on this one. I need to look it up. Added it to my TODO list.
> 
> I called the main courier daemon a "scheduler" since that's mostly what 
> it does but you might want to call it something else? I don't know.
> 
> 
> 
> On 04/27/2016 12:14 AM, Ondřej Surý wrote:
> > 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,
> 

Reply via email to