MailScanner 5 on Gentoo

[Michael Weiser]

Hi Jerry,

On Sun, Nov 13, 2016 at 11:05:37PM -0500, Jerry Benton wrote:

> Ok, I can???t tell if you are happy about v5 or not.

Now I can't tell if you're joking: I'm very happy, honest. Because it's
FHS-compliant now, packaging became much more straight-forward. I like
the new naming scheme for commands and ms-cron for cronjobs. I think
it's a huge improvement all around and I basically like all about it.

> So, here is some of the logic:

> - I put the config in /etc/MailScanner/defaults because configs are in
> a different place on every distro. This keeps it in one place no
> matter what distro you are using. I support a lot of different
> distros, and trying to find it in 5 different places on 5 different
> distros is a pain in the ass. I would suggest leaving it where it is
> and using a symlink for your distro. 
> - The same logic was used for ms-init, /var/lock/subsys/Mailscanner,
> and /var/log/MailScanner.off

I feel your pain and I read and understood the list archives for the
rationale. Gentoo users and supporters being able to find things as per
their known path conventions is just as valid a point, IMO. AFAIK Gentoo
users are encouraged to report to the Gentoo bugzilla first (in the
assumption that the packager screwed up :) and possibly take it upstream
from there having the package maintainer as a reproducer, qualifier and
translator.

> - run_mailscanner is in place so that MailScanner does not get started
> accidentally before MailScanner.conf has been setup. 

> - The PID of the mater process is put in the PID file. If ms-check
> does not find a matching PID of what it should be, it restarts
> everything. 

My niggle here is that ms-check also restarts the daemon if the PID file
is missing altogether. That makes it a masked start script. Consider the
following workflow:

A user installs MailScanner and as always first goes into
/etc/conf.d/$service (or /etc/MailScanner/defaults in this case) and
looks for general overall stuff to adjust. Obviously he'll decide to set
run_mailscanner to 1 because he'll want the service to run eventually.
Then he'll turn his attention to MailScanner.conf and get lost in its
plenthora of options. Meanwhile cron.hourly runs ms-cron which runs
ms-check and starts the daemon with an unfinished config.

I guess this is not a problem with the a stock tarball install because
it doesn't install cron jobs automatically. But I'd like to provide them
as part of the package. And I see that the RPM package does so as well.

I guess we could have an additional run_cron defaulting to 0 with a fat
warning to only set that to 1 after everything is configured. Or add
such a warning to run_mailscanner.

But is there an actual error condition that would cause MailScanner
to stop unintentionally and still clean up its PID file?
-- 
Thanks,
Michael