Bug#344582: [pkg-fetchmail-maint] Bug#344582: fetchmail: postinst fails if no servers are in the config

[Loïc Minier]

        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 <lool at dooz.org>