Hi,
On Sun, Dec 25, 2005, Nico Golde wrote:
> @Loic do you have an idea how to workaround this, cause its
> fetchmail which exists here not really a part of postinst
Reading the init script suggested the following:
- daemon mode is forced if not specified in /etc/fetchmailrc
- it doesn't check for the exit code of fetchmail or for the
correctness of the config
(the later seems normal to me)
I did a small test and configured fetchmail to run in daemon mode with
no server to poll and it exited as for Eduard with:
fetchmail: no mailservers have been specified.
The exit code in this case is 5: "There was a syntax error in the
arguments to fetchmail." (from the man page)
I would have agreed to modify the init script to check the return code
of fetchmail for "no server configured" errors, but in this case the
error is too important for us to ignore it: if the fetchmail returns
"syntax error" after an upgrade and can't be started, there's a problem
we have to face (either it was there before the upgrade and the admin
is responsible, or it was introduced with the upgrade, and we have to
suggest how to fix it).
IMO, we're victim of bad design decisions both in Debian and upstream:
1/ the mere _presence_ of /etc/fetchmailrc is supposed to be
an indication of "need to run a system-wide fetchmail as root in daemon
mode" (whatever the file holds).
2/ Also, this forbids shipping a /etc/fetchmailrc file in Debian as a
template for admins and to deal with upstream configuration file
changes transparently.
3/ I also believe it's a small bug that the daemon mode exits when no
server is configured: when you change a fetchmail configuration file
and a fetchmail daemon is running against it, it usually restarts
transparently rereading its configuration. This behavior works
correctly, even when adding or removing servers, but it doesn't work
when zero server are configured: why special case this?
Would only 3/ be fixed, we would be fixed, but that's an upstream
decision.
If this bug is a consequence of an upstream change where 3/ was
supported in the past and isn't anymore, and would we support upgrading
a configuration (eg. 2/), we could simply disable the system fetchmail
when we upgrade an old configuration to a newer one (that would require
1/ or mv /etc/fetchmailrc /etc/fetchmailrc-syntax-errors.bak).
Nico, I propose we introduce /etc/default/fetchmail to control the
system wide daemon (instead of checking for the presence of
/etc/fetchmailrc, we would use START_DAEMON=yes in this new config file
isntead). Once this is done, we can use the following approach on
upgrades:
if /etc/fetchmailrc is present on the system prior to the upgrade then
if we manage to start a system-wide fetchmail with this file then
write START_DAEMON=yes in /etc/default/fetchmail
else
output an error mesage that fetchmail couldn't be started and
that the daemon will be deactivated
write START_DAEMON=no in /etc/default/fetchmail
endif
else
write START_DAEMON=no in /etc/default/fetchmail
fi
In the case of Eduard, we would find a /etc/fechmailrc on the
system, decide it doesn't work, and hence set START_DAEMON=no.
Let me know what you think of the global approach, the implementation
might be harder[1] than the algorithm looks like.
[1] would fetchmail offer a "check configuration syntax" feature, that
would be trivial, but due to the fact that fetchmail is started from
start-stop-daemon, we have no idea to tell whether fetchmail is
running correctly in daemon mode, or died rapidly; we could eg.
sleep for a couple of seconds and check for the presence of the
process (it's not perfect but should work); or we could simply
check ourselves whether some mail servers were defined in the config
instead (but that does not cover all syntax error cases...)
--
Loïc Minier <[EMAIL PROTECTED]>
