Bug#775578: Reproduceable issue - spamassasin does not enable the service systemd when it was enabled for Sysvinit

[Javier Fernández-Sanguino Peña]

Dear all,

I also had the same issue (spamassasin would not start after boot on
upgrade). I believe this bug is the same as Ubuntu's bug 1503611:
https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1503611
(see there for other similar issues and the fix)

In my case, I run fetchmail and procmail in a user, and that user runs a spamassasin
filter ('| /usr/bin/spamc'). Spamc could not connect to Spamassasin and I was
getting a lot of the errors below in the /var/log/mail.log file:

Apr 10 08:15:14 silicio spamc[3785]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
Apr 10 08:15:14 silicio spamc[3785]: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused
Apr 10 08:15:14 silicio spamc[3794]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
Apr 10 08:15:14 silicio spamc[3794]: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused

These errors when away as soon as I would start the service
(/etc/init.d/spamassassin start) but if they went undetected they would fill
up my /var/log/ partition quite fast.

Basicly I think the issue can be summarised as follows:

 - The default status of spamassasin for SysV rc is not run on boot (ENABLED=0 in
   /etc/default/spamassassin)

 - Some users (like me) that want it to have it started set ENABLED=1 in
   that configuration file  and the service will start on boot

 - On upgrade to systemd, that flag is not considered and service is not
   started by default. The "ENABLED" flag setting is now unused

To fix this bug, spamassasin should check, on upgrade:

  - is ENABLED=1 in the configuration file  set?
  - is the service started?
  
If it is, then it should assume that the service should also be enabled on
systemd, by running: 'systemctl enable spamassassin.service'

Currently, this is something the admininistrator has to detect and do
manually. It could be easily programmed into sa's postinst, however.

At the very minimum, this needs to be documented in the NEWS.Debian file. It
is documented in the configuration file /etc/default/spamassassin, but that
need not be reviewed by an administrator during an upgrade.

Best regards


Javier

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160410/316578df/attachment.sig>