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, >