Your message dated Wed, 02 Aug 2006 03:48:47 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#376603: fixed in fetchmail 6.3.4-4
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: fetchmail
Version: 6.3.4-1
Severity: important

$ echo >/home/pryzbyj/.fetchmail.pid
$ fetchmail; echo $?
0
$

|execve("/usr/bin/fetchmail", ["fetchmail"], [/* 27 vars */]) = 0
[...]

Start of real stuff:
|stat64("/home/pryzbyj/.fetchmailrc", {st_mode=S_IFREG|0600, st_size=434, ...}) 
= 0
|lstat64("/home/pryzbyj/.fetchmailrc", {st_mode=S_IFREG|0600, st_size=434, 
...}) = 0
|geteuid32()                             = 1000

It notices that there's an rc file:
|open("/home/pryzbyj/.fetchmailrc", O_RDONLY) = 4

WTF?
|ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xafa04e58) = -1 ENOTTY (Inappropriate 
ioctl for device)

[...]

Notices there's a PID file:
|lstat64("/home/pryzbyj/.fetchids", 0xafa0539c) = -1 ENOENT (No such file or 
directory)
|lstat64("/home/pryzbyj/.fetchids", 0xafa0518c) = -1 ENOENT (No such file or 
directory)
|open("/home/pryzbyj/.fetchids", O_RDONLY) = -1 ENOENT (No such file or 
directory)
|getuid32()                              = 1000
|setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = 0
|open("/home/pryzbyj/.netrc", O_RDONLY)  = 4
|fstat64(4, {st_mode=S_IFREG|0600, st_size=269, ...}) = 0
|mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xa7eee000
|read(4, "machine jupiter2\nlogin pryzju01\n"..., 4096) = 269
|read(4, "", 4096)                       = 0
|close(4)                                = 0
|munmap(0xa7eee000, 4096)                = 0
|open("/home/pryzbyj/.fetchmail.pid", O_RDONLY) = 4

Which lacks a PID:
|fstat64(4, {st_mode=S_IFREG|0644, st_size=1, ...}) = 0
|mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xa7eee000
|read(4, "\n", 4096)                     = 1
|read(4, "", 4096)                       = 0

Huh?  Yes, we are a process..
|kill(0, SIG_0)                          = 0
|close(4)                                = 0

Well, it seems to have decided that since there was a pidfile, even
though it found no pid (bug), to fork:

|munmap(0xa7eee000, 4096)                = 0
|rt_sigaction(SIGCHLD, {0x80588b0, [], SA_RESTART|SA_NOCLDSTOP}, {SIG_DFL}, 8) 
= 0
|rt_sigaction(SIGPWR, {0x80588b0, [], SA_RESTART|SA_NOCLDSTOP}, NULL, 8) = 0
|getppid()                               = 20097
|rt_sigaction(SIGTTOU, {SIG_IGN}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGTTIN, {SIG_IGN}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGTSTP, {SIG_IGN}, {SIG_DFL}, 8) = 0
|clone(Process 20099 attached
|child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xa7bd3708) = 20099
|[pid 20098] exit_group(0)               = ?
|Process 20098 detached
|setsid()                                = 20099
|close(19)                               = -1 EBADF (Bad file descriptor)
|close(18)                               = -1 EBADF (Bad file descriptor)
|close(17)                               = -1 EBADF (Bad file descriptor)
|close(16)                               = -1 EBADF (Bad file descriptor)
|close(15)                               = -1 EBADF (Bad file descriptor)
|close(14)                               = -1 EBADF (Bad file descriptor)
|close(13)                               = -1 EBADF (Bad file descriptor)
|close(12)                               = -1 EBADF (Bad file descriptor)
|close(11)                               = -1 EBADF (Bad file descriptor)
|close(10)                               = -1 EBADF (Bad file descriptor)
|close(9)                                = -1 EBADF (Bad file descriptor)
|close(8)                                = -1 EBADF (Bad file descriptor)
|close(7)                                = -1 EBADF (Bad file descriptor)
|close(6)                                = -1 EBADF (Bad file descriptor)
|close(5)                                = 0
|close(4)                                = -1 EBADF (Bad file descriptor)
|close(3)                                = 0

This explains why it fails silently:
|close(2)                                = 0
|close(1)                                = 0
|close(0)                                = 0
|open("/dev/null", O_RDWR)               = 0
|dup(0)                                  = 1
|dup(0)                                  = 2

It *tries* to tell me something:
|umask(022)                              = 077
|rt_sigaction(SIGCHLD, {0x80588b0, [], SA_RESTART|SA_NOCLDSTOP}, {0x80588b0, 
[], SA_RESTART|SA_NOCLDSTOP}, 8) = 0
|rt_sigaction(SIGPWR, {0x80588b0, [], SA_RESTART|SA_NOCLDSTOP}, NULL, 8) = 0
|fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
|ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xafd9d1b4) = -1 ENOTTY (Inappropriate 
ioctl for device)
|mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xa7f89000
|write(1, "fetchmail: starting fetchmail 6."..., 44) = 44
|rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_DFL}, 8) = 0
|getuid32()                              = 1000
|uname({sys="Linux", node="andromeda", ...}) = 0
|umask(077)                              = 022
|rt_sigaction(SIGABRT, {0x8051e30, [], SA_RESTART}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGINT, {0x8051e30, [], SA_RESTART}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGTERM, {0x8051e30, [], SA_RESTART}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGALRM, {0x8051e30, [], 0}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGPIPE, {0x8051e30, [], SA_RESTART}, {SIG_DFL}, 8) = 0
|rt_sigaction(SIGQUIT, {0x8051e30, [], SA_RESTART}, {SIG_DFL}, 8) = 0

Here, it assumes the file doesn't exist
|open("/home/pryzbyj/.fetchmail.pid", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 
EEXIST (File exists)
|dup(2)                                  = 3
|fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
|fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
|ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xafd9d290) = -1 ENOTTY (Inappropriate 
ioctl for device)
|mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xa7f88000
|_llseek(3, 0, [0], SEEK_CUR)            = 0

And again *tries* to say something:
|write(3, "/home/pryzbyj/.fetchmail.pid: Fi"..., 42) = 42
|close(3)                                = 0
|munmap(0xa7f88000, 4096)                = 0
|write(2, "fetchmail: lock creation failed."..., 33) = 33
|munmap(0xa7f89000, 4096)                = 0
|exit_group(8)                           = ?
|Process 20056 detached

So the second bug is that it tries but fails to report an error to me,
when it has already inhibited its own ability to do so.  It either
needs to not do that, or open("/dev/console") or "/dev/tty", or
"/dev/tty0" or some such in order to write to it, or to use some
syslog/msg foo (which shouldn't be necessary).


--- End Message ---
--- Begin Message ---
Source: fetchmail
Source-Version: 6.3.4-4

We believe that the bug you reported is fixed in the latest version of
fetchmail, which is due to be installed in the Debian FTP archive:

fetchmail_6.3.4-4.diff.gz
  to pool/main/f/fetchmail/fetchmail_6.3.4-4.diff.gz
fetchmail_6.3.4-4.dsc
  to pool/main/f/fetchmail/fetchmail_6.3.4-4.dsc
fetchmail_6.3.4-4_i386.deb
  to pool/main/f/fetchmail/fetchmail_6.3.4-4_i386.deb
fetchmailconf_6.3.4-4_all.deb
  to pool/main/f/fetchmail/fetchmailconf_6.3.4-4_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Hector Garcia <[EMAIL PROTECTED]> (supplier of updated fetchmail package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue,  1 Aug 2006 10:44:26 +0200
Source: fetchmail
Binary: fetchmailconf fetchmail
Architecture: source i386 all
Version: 6.3.4-4
Distribution: unstable
Urgency: low
Maintainer: Fetchmail Maintainers <[EMAIL PROTECTED]>
Changed-By: Hector Garcia <[EMAIL PROTECTED]>
Description: 
 fetchmail  - SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 fetchmailconf - fetchmail configurator
Closes: 376603 380459 380794
Changes: 
 fetchmail (6.3.4-4) unstable; urgency=low
 .
   [ Nico Golde ]
   * Fixed awakening bug in init script (Closes: #380459).
   * Fixed EOF handling, patch can be removed after fetchmail 6.3.5
     release (Closes: #376603).
   * Bumped Standards-Version.
 .
   [ Piotr Ozarowski ]
   * Updated for the new python policy (Closes: #380794).
   * Replaced /usr/bin/fetchmailconf shell script with symlink
       and thus removed 01.fetchmailconf patch.
 .
   [ Hector Garcia ]
   * Added bison to build-depends.
Files: 
 9771952c15be79c1154d9fc7a038012e 817 mail optional fetchmail_6.3.4-4.dsc
 93edd74363781d5f6457747077893f15 43060 mail optional fetchmail_6.3.4-4.diff.gz
 2231fcf8d1e22dd3639b89e331e4b926 59264 mail optional 
fetchmailconf_6.3.4-4_all.deb
 f7a836dd2b7917ab332bb4058c64c521 592898 mail optional 
fetchmail_6.3.4-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE0GgsMwsDi2xjdG0RAsx3AKD3a6xKnGaWllZk4V3jIley/9cVOwCg8JI1
bexFtBnXfXhyaz++klPsaBw=
=xG2V
-----END PGP SIGNATURE-----


--- End Message ---

Reply via email to