Bug 6410 - "Use of uninitialized value $selerr" on SIGHUP to spamd
Summary: "Use of uninitialized value $selerr" on SIGHUP to spamd
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.3.1
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-15 11:59 UTC by Adam Stephens
Modified: 2013-06-21 16:20 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Stephens 2010-04-15 11:59:32 UTC
We have process in cron that update rules files and restart spamd with a SIGHUP.

Occasionally, this causes errors like this:

Apr 15 13:27:02 spam3 spamd[9506]: prefork: child states: BBBIBBBBBBBI
Apr 15 13:27:02 spam3 spamd[9506]: spamd: server hit by SIGHUP, restarting
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13467] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13485] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13484] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13466] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13453] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [12626] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:02 spam3 spamd[9506]: spamd: child [13447] killed successfully: interrupted, signal 2 (0002)
Apr 15 13:27:03 spam3 spamd[13483]: spamd: Tell: Setting local for exim:65534 in 1.0 seconds, 377880 bytes
Apr 15 13:28:06 spam3 spamd[9506]: Use of uninitialized value $selerr in concatenation (.) or string at /usr/local/share/perl/5.10.0/Mail/SpamAssassin/SpamdForkScaling.pm line 332.
Apr 15 13:28:06 spam3 spamd[9506]: prefork: select returned error on server filehandle:


Spamd does process some further messages but doesn't log any further prefork: messages. Shortly afterwards it dies completely:

Apr 15 13:35:53 spam3 spamd[13483]: spamd: connection from dirh.bris.ac.uk [137.222.10.22] at port 61660
Apr 15 13:35:54 spam3 spamd[13483]: spamd: Tell: Setting local for exim:65534 in 1.0 seconds, 3443 bytes
Apr 15 13:37:21 spam3 spamd[9506]: prefork: cannot ping 13483, file handle not defined, child likely to still be processing SIGCHLD handler after killing itself
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killing failed child 13483 fd=undefined at /usr/local/share/perl/5.10.0/Mail/SpamAssassin/SpamdForkScaling.pm line 172.
Apr 15 13:37:21 spam3 spamd[9506]: prefork: error closing socket: Bad file descriptor
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killed child 13483
Apr 15 13:37:21 spam3 spamd[9506]: prefork: cannot ping 13471, file handle not defined, child likely to still be processing SIGCHLD handler after killing itself
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killing failed child 13471 fd=undefined at /usr/local/share/perl/5.10.0/Mail/SpamAssassin/SpamdForkScaling.pm line 172.
Apr 15 13:37:21 spam3 spamd[9506]: prefork: error closing socket: Bad file descriptor
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killed child 13471
Apr 15 13:37:21 spam3 spamd[9506]: prefork: cannot ping 13472, file handle not defined, child likely to still be processing SIGCHLD handler after killing itself
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killing failed child 13472 fd=undefined at /usr/local/share/perl/5.10.0/Mail/SpamAssassin/SpamdForkScaling.pm line 172.
Apr 15 13:37:21 spam3 spamd[9506]: prefork: error closing socket: Bad file descriptor
Apr 15 13:37:21 spam3 spamd[9506]: prefork: killed child 13472

Spamd then stops processing or logging anything, until it next receives a SIGHUP - when it usually restarts successfully and gets back to work.
Comment 1 Kevin A. McGrail 2011-10-29 02:06:31 UTC
The use of uninitialized value isn't really the error.

Here's the code that's generating the error.

  # errors on the handle?
  # return them immediately, they may be from a SIGHUP restart signal
  if ($self->vec_all(\$eout, $self->{server_fileno})) {
    warn "prefork: select returned error on server filehandle: $selerr $!\n";
    return;
  }

So we are getting a filehandle error and neither $selerr nor $! appear to have useful information about why.

Are you still seeing this issue?  I don't use SIGHUP so we need to know if more people are seeing this issue.
Comment 2 Kevin A. McGrail 2013-06-21 16:20:33 UTC
Can't replicate