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,
