Summary: | >=mail-filter/spamassassin-3.4.2: spamd cannot start | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robin Bankhead <gentoo> |
Component: | Current packages | Assignee: | Philippe Chaintreuil <gentoo_bugs_peep> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | bug, hydrapolic, jaak, mjo, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Syslog output |
Description
Robin Bankhead
2018-10-21 19:26:19 UTC
Happened to me as well, but I somehow got it to work. I suspect that a simple `sa-update && sa-compile` might help (I downgraded, started the service, stopped the service, ran `sa-update && sa-compile`, upgraded, ran `sa-update && sa-compile` and then started it successfully). (In reply to Jaak Ristioja from comment #1) > Happened to me as well, but I somehow got it to work. I suspect that a > simple `sa-update && sa-compile` might help (I downgraded, started the > service, stopped the service, ran `sa-update && sa-compile`, upgraded, ran > `sa-update && sa-compile` and then started it successfully). Thanks, I ran the above line once and it segfaulted, but a second time both commands succeeded and spamd started successfully. This is the first I've been aware of sa-compile. Should it always be run after sa-update? Yes, it's a good practice to run sa-update && sa-compile. If it's good practice, it seems to me that it should be in the ebuild. (I was bitten by this as well) It's in the update cron: https://github.com/gentoo/gentoo/blob/master/mail-filter/spamassassin/files/update-spamassassin-rules.cron It's also mentioned in https://wiki.gentoo.org/wiki/SpamAssassin. Are either of you able to reproduce the crash? SpamAssassin simply won't work until you've run sa-update once, but spamd shouldn't segfault under any circumstances. (Does it really segfault, or just exit?) If it segfaults and is reproducible, we could get a backtrace and report it upstream -- hopefully in time for v3.4.3. Regarding sa-update and sa-compile in the ebuild: we're generally not allowed to access the network in ebuild phases that can cause a build failure. I guess we could do an sa-update && sa-compile in "emerge --config", but IMO that's more esoteric than sa-update and sa-compile themselves. I don't think it crashed as much as it failed to start. I can't find the exact message anymore. I can understand not allowing network access during ebuild. Thanks! (In reply to Michael Orlitzky from comment #6) > Are either of you able to reproduce the crash? SpamAssassin simply won't > work until you've run sa-update once, but spamd shouldn't segfault under any > circumstances. (Does it really segfault, or just exit?) > The segfault I mentioned was by sa-compile (during sa-update && sa-compile). I have this in the log: Oct 21 22:24:31 hazel kernel: sa-compile[10942]: segfault at d9c876fb98 ip 00007f1f04af2a71 sp 00007ffccd6e26b0 error 4 in libmysqlclient.so.18.4.0[7f1f04ab4000+34c000] Oct 21 22:24:31 hazel kernel: Code: 00 e8 fb 1b ff ff 48 8b bb 20 04 00 00 e8 ef 1b ff ff 48 8b bb 28 04 00 00 e8 e3 1b ff ff 48 8b 83 88 04 00 00 48 85 c0 74 2c <48> 8b b8 a8 00 00 00 e8 cb 1b ff ff 48 8b 83 88 04 00 00 48 8b 78 I had just (during the same world upgrade) migrated from the libmysqlclient bundled in dev-db/mysql to dev-db/mysql-connector-c - perhaps that's related? (I haven't seen any other issues with packages that use libmysqlclient, and SA is using mysql fine now). > If it segfaults and is reproducible, we could get a backtrace and report it > upstream -- hopefully in time for v3.4.3. > I can try running sa-compile again to see if it recurs, when a non-busy time comes. I suspect it will have been a one-off due to not having run sa-update in some time, though. As for spamd's failure to start, the output above and in the attached log is all I have. No segfaults mentioned there. > Regarding sa-update and sa-compile in the ebuild: we're generally not > allowed to access the network in ebuild phases that can cause a build > failure. I guess we could do an sa-update && sa-compile in "emerge > --config", but IMO that's more esoteric than sa-update and sa-compile > themselves. I think you have it about right in the ebuild: the einfo is clear that sa-update must be run initially, and it recommends doing it regularly with cron (this is what I failed to do). There's maybe a case for making it more than a recommendation (in the einfo language, or even defaulting to IUSE=+cron) as I never had any awareness that it might need to be run after an upgrade. (Indeed, if sa-compile was what actually made the difference here, a point I'm still not clear on, then this ought to be mentioned as I've never run it before in >6 years of this install). (In reply to Robin Bankhead from comment #9) > I had just (during the same world upgrade) migrated from the libmysqlclient > bundled in dev-db/mysql to dev-db/mysql-connector-c - perhaps that's > related? From my experience and looking at my emerge logs, I think it is not related. I suspect that sa-compile (and/or sa-update before that) might have to be rerun each time after upgrading but before (re)starting the service, because there might be binary incompatibility between the binaries compiled by the old version of sa-compile and the new version of the spamd service which loads them. (In reply to Robin Bankhead from comment #9) > (In reply to Michael Orlitzky from comment #6) > > Are either of you able to reproduce the crash? SpamAssassin simply won't > > work until you've run sa-update once, but spamd shouldn't segfault under any > > circumstances. (Does it really segfault, or just exit?) > > > The segfault I mentioned was by sa-compile (during sa-update && sa-compile). > I have this in the log: > > Oct 21 22:24:31 hazel kernel: sa-compile[10942]: segfault at d9c876fb98 ip > 00007f1f04af2a71 sp 00007ffccd6e26b0 error 4 in > libmysqlclient.so.18.4.0[7f1f04ab4000+34c000] > Oct 21 22:24:31 hazel kernel: Code: 00 e8 fb 1b ff ff 48 8b bb 20 04 00 00 > e8 ef 1b ff ff 48 8b bb 28 04 00 00 e8 e3 1b ff ff 48 8b 83 88 04 00 00 48 > 85 c0 74 2c <48> 8b b8 a8 00 00 00 e8 cb 1b ff ff 48 8b 83 88 04 00 00 48 8b > 78 > > I had just (during the same world upgrade) migrated from the libmysqlclient > bundled in dev-db/mysql to dev-db/mysql-connector-c - perhaps that's > related? (I haven't seen any other issues with packages that use > libmysqlclient, and SA is using mysql fine now). Hi, did you rebuild libmysql linked packages? There were message after installing connector: Due to ABI changes when switching between different client libraries, revdep-rebuild must find and rebuild all packages linking to libmysqlclient. Please run: revdep-rebuild --library libmysqlclient.so.18
> Hi,
> did you rebuild libmysql linked packages? There were message after
> installing connector:
> Due to ABI changes when switching between different client libraries,
> revdep-rebuild must find and rebuild all packages linking to libmysqlclient.
> Please run: revdep-rebuild --library libmysqlclient.so.18
Sorry, I missed that. There are some rebuilds needed including dev-perl/DBD-MySQL which I guess is probably what caused the segfault. I'll do these shortly when the machine is free, but certainly it looks like this is INVALID.
(In reply to Robin Bankhead from comment #12) > Sorry, I missed that. There are some rebuilds needed including > dev-perl/DBD-MySQL which I guess is probably what caused the segfault. I'll > do these shortly when the machine is free, but certainly it looks like this > is INVALID. I disagree. For me, this issue happened on a VM which is updated very often (including @preserved-rebuild and even revdep-rebuild) about every 1-3 days, and restarted every 8-20 days or so. The VM was restarted on Oct 15, and spamd worker properly after startup. Looking at emerge.log, only some unrelated dev-qt/*, net-irc/* and www-apps/* packages were upgraded after the restart. Nothing else. Nothing from @preserved-rebuild or revdep-rebuild. Then on Oct 21, spamassassin was upgraded from 3.4.1-r21 to 3.4.2-r2, and immediately restarted afterwards, leading to this failure. So the most reasonable explanation seems to be that spamassassin 3.4.2-r2 is not compatible with sa-update/sa-compile generated by spamassassin 3.4.1-r21. (In reply to Jaak Ristioja from comment #13) > Then on Oct 21, spamassassin was > upgraded from 3.4.1-r21 to 3.4.2-r2, and immediately restarted afterwards, > leading to this failure. > > So the most reasonable explanation seems to be that spamassassin 3.4.2-r2 is > not compatible with sa-update/sa-compile generated by spamassassin 3.4.1-r21. SpamAssassin v3.4.2 uses an entirely different "rules" directory than v3.4.1. If you don't run the v3.4.2 sa-update before starting v3.4.2, it will just crash because it doesn't see any rules. I think there are probably two separate problems that are reported here: 1. The mysql-connector thingy required a rebuild, which made spamd segfault until the rebuild happened (nice catch Marcin) 2. New versions of SpamAssassin don't work anyway until you've run sa-update *after* upgrading. We have an elog message for the second problem, and while that kinda sucks for an out-of-the-box experience, I don't have a better idea. is spamd seqfaults i solved it with perl-cleaner --reallyall sa-update and sa-compile is not here rellevant is --reallyall needed on new glibc unsure, but i see logs fails on libnss_db.so Presumably no one has had any more problems after revdep-rebuild and perl-cleaner --reallyall? If so, we can't do anything else within spamassassin to address the problem. The rebuild of DBD-MariaDB should happen automatically next time, because slot-operator dependencies were added: RDEPEND=" >=dev-perl/DBI-1.608.0 virtual/perl-XSLoader mysql? ( dev-db/mysql-connector-c:0= ) mariadb? ( dev-db/mariadb-connector-c:0= ) " And the perl-cleaner thing is just... something you have to live with, with perl. Nothing we can do about it. Please reopen if you still have problems. Kind of repeating some of the above comments, I had this happen a few times when I was working on v3.4.3 because the rules had been removed/become invalid. spamd just kind of silently fails when launched from the init script from what I can tell, but running it manually # sudo /usr/sbin/spamd --pidfile=/run/spamd.pid --username=spamd --groupname=spamd --nicelevel 0 (...or similar based on if you run as root) outputs the reason. (To which I facepalm, run the sa-update cron job, and then everything's fine.) |