Bug#775578: systemd kills spamassassin on system start

James Bottomley James.Bottomley at HansenPartnership.com
Thu Feb 11 23:53:18 GMT 2016


On Thu, 2016-02-11 at 23:41 +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 17 Jan 2015 09:08:32 -0800 James Bottomley
> <James.Bottomley at HansenPartnership.com> wrote:
> > Package: systemd
> > Version: 215-8
> > Severity: normal
> > 
> > Almost every time the system reboots, spamassassin fails to start. 
> >  The systemd logs for this are:
> > 
> > # systemctl status -l spamassassin.service
> > ● spamassassin.service - Perl-based spam filter using text
> > analysis
> >    Loaded: loaded (/lib/systemd/system/spamassassin.service;
> > enabled)
> >    Active: failed (Result: timeout) since Sat 2015-01-17 08:49:04
> > PST; 3min 45s ago
> >   Process: 528 ExecStart=/usr/sbin/spamd -d -
> > -pidfile=/var/run/spamassassin.pid $OPTIONS (code=killed,
> > signal=TERM)
> > 
> > Jan 17 08:48:10 bedivere spamd[528]: logger: removing stderr method
> > Jan 17 08:49:04 bedivere systemd[1]: spamassassin.service start
> > operation timed out. Terminating.
> > Jan 17 08:49:04 bedivere systemd[1]: Failed to start Perl-based
> > spam filter using text analysis.
> > Jan 17 08:49:04 bedivere systemd[1]: Unit spamassassin.service
> > entered failed state.
> > Jan 17 08:49:04 bedivere spamd[748]: spamd: server killed by
> > SIGTERM, shutting down
> > Jan 17 08:49:04 bedivere spamd[748]: spamd: cannot unlink
> > /var/run/spamassassin.pid: No such file or directory
> > 
> > This server is still x86 and a big internet system, so it has lots
> > of
> > intensive processes on start, like fail2ban , clamd and apache.  It
> > looks like because of this, systemd gives spamassassin a few
> > seconds
> > (there's no log of how long; the logger message is from the pre
> > -reboot
> > os) to start and it takes longer.
> > 
> > As far as I can tell, this value doesn't seem to be configurable or
> > even package specific.  It looks remarkably silly for the init
> > system
> > to impose an absolute timeout on service start, particularly when
> > it
> > doesn't take into account the characteristics of the machine or ask
> > the package how long it might reasonably take.
> > 
> > So far, it's only spamassassin, so it's annoying but not serious to
> > have to log in and restart it after every reboot.  However, if
> > systemd
> > did this to a necessary service, it would become a serious bug
> 
> Can you provide instructions how this issue can be reproduced?

You mean reproduce this outside of booting the system? I have no idea
how to do that.  I suspect it's a load issue, so this is the system:

cat /prbedivere:~# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 2
model name	: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping	: 9
microcode	: 0x2e
cpu MHz		: 2813.471
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
pebs bts cid xtpr
bugs		:
bogomips	: 5626.94
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 32 bits virtual
power management:

bedivere:~# cat /proc/meminfo 
MemTotal:        1022016 kB
MemFree:           43816 kB
MemAvailable:     346924 kB
Buffers:           36980 kB
Cached:           295580 kB
SwapCached:        39344 kB
Active:           528756 kB
Inactive:         395168 kB
Active(anon):     321488 kB
Inactive(anon):   306540 kB
Active(file):     207268 kB
Inactive(file):    88628 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        131016 kB
HighFree:           7628 kB
LowTotal:         891000 kB
LowFree:           36188 kB
SwapTotal:       1951892 kB
SwapFree:        1582008 kB
Dirty:               120 kB
Writeback:             0 kB
AnonPages:        568992 kB
Mapped:            54324 kB
Shmem:             36664 kB
Slab:              36280 kB
SReclaimable:      21972 kB
SUnreclaim:        14308 kB
KernelStack:        3096 kB
PageTables:         4420 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2462900 kB
Committed_AS:    1973536 kB
VmallocTotal:     122880 kB
VmallocUsed:       11120 kB
VmallocChunk:     103032 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       4096 kB
DirectMap4k:       86008 kB
DirectMap4M:      823296 kB

You can probably configure a VM roughly to match that

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20160211/095b37c8/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list