Bug#376603: [pkg-fetchmail-maint] Bug#376603: fetchmail: empty pidfile in ~/ causes fetchmail to fail silently
Hi, * Justin Pryzby [EMAIL PROTECTED] [2006-07-19 01:24]: On Tue, Jul 04, 2006 at 09:16:52AM +0200, Nico Golde wrote: * Justin Pryzby [EMAIL PROTECTED] [2006-07-04 00:50]: Package: fetchmail Version: 6.3.4-1 Severity: important $ echo /home/pryzbyj/.fetchmail.pid $ fetchmail; echo $? 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). Thats very strange, I can not reproduce this: Indeed, my first attempt to do so failed, and now it works consistently.. The initial problem was out of disk space in /home, allowing the file to be overwritten/created, but not allowing any writes (which should also be an error, actually...). Yes fetchmail should warn about this. Did you ever reproduce this one? Nope, sorry. Matthias, can you please fix this in the next upstream version? Kind regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://nion.modprobe.de/blog/ Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpuW5Y2SP2CD.pgp Description: PGP signature
Bug#376603: [pkg-fetchmail-maint] Bug#376603: fetchmail: empty pidfile in ~/ causes fetchmail to fail silently
On Tue, Jul 04, 2006 at 11:57:13AM +0200, Matthias Andree wrote:
Justin Pryzby [EMAIL PROTECTED] writes:
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)
glibc at work, probably isatty() or equivalent to find out the default
buffer size (line vs. fully buffered).
Nice
Huh? Yes, we are a process..
|kill(0, SIG_0) = 0
|close(4)= 0
That's indeed a bug, and it's easy to fix (patch attached, description
below). The fscanf() in fm_lock_state() returns EOF; which isn't handled
in = 6.3.4.
I find the PID of 0 astonishing however. Is Debian's GCC different than
SUSE's?
What compiler {,version} and optimization level are you using?
In a test, gcc-3.4 -O0, gcc-4.0 -O3, and gcc-4.0 -O1 results in sscanf
setting integers to zero, even if no valid input was read.
IIRC buffer initialization also changes.
This may, in fact, be a deliberate but otherwise unnecessary change by
the toolchain folks to break in an obvious way things which rely on
unfounded assumptions, rather than allowing them to work with the
author's $cc, but fail obscurely with others'.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376603: [pkg-fetchmail-maint] Bug#376603: fetchmail: empty pidfile in ~/ causes fetchmail to fail silently
On Tue, Jul 04, 2006 at 09:16:52AM +0200, Nico Golde wrote: Hi * Justin Pryzby [EMAIL PROTECTED] [2006-07-04 00:50]: Package: fetchmail Version: 6.3.4-1 Severity: important $ echo /home/pryzbyj/.fetchmail.pid $ fetchmail; echo $? 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). Thats very strange, I can not reproduce this: Indeed, my first attempt to do so failed, and now it works consistently.. The initial problem was out of disk space in /home, allowing the file to be overwritten/created, but not allowing any writes (which should also be an error, actually...). Did you ever reproduce this one? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376603: [pkg-fetchmail-maint] Bug#376603: fetchmail: empty pidfile in ~/ causes fetchmail to fail silently
Hi * Justin Pryzby [EMAIL PROTECTED] [2006-07-04 00:50]: Package: fetchmail Version: 6.3.4-1 Severity: important $ echo /home/pryzbyj/.fetchmail.pid $ fetchmail; echo $? 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). Thats very strange, I can not reproduce this: fetchmail: Installed: 6.3.4-1 Candidate: 6.3.4-1 Version table: *** 6.3.4-1 0 [EMAIL PROTECTED] (~/) echo .fetchmail.pid [EMAIL PROTECTED] (~/) fetchmail; echo $? /home/nion/.fetchmail.pid: File exists fetchmail: lock creation failed. 8 What does fetchmail -v say? Kind regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpyM4eEaCKyl.pgp Description: PGP signature
Bug#376603: [pkg-fetchmail-maint] Bug#376603: fetchmail: empty pidfile in ~/ causes fetchmail to fail silently
Justin Pryzby [EMAIL PROTECTED] writes:
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)
glibc at work, probably isatty() or equivalent to find out the default
buffer size (line vs. fully buffered).
Huh? Yes, we are a process..
|kill(0, SIG_0) = 0
|close(4)= 0
That's indeed a bug, and it's easy to fix (patch attached, description
below). The fscanf() in fm_lock_state() returns EOF; which isn't handled
in = 6.3.4.
Nico, I suggest to demote the severity to normal or minor (your
decision), tag fixed-upstream,confirmed,patch and add the attached
patch since it'll take some time until 6.3.5, there are some nontrivial
fixes in the pipeline.
I find the PID of 0 astonishing however. Is Debian's GCC different than
SUSE's? The PID passed to kill is an uninitialized auto variable, and
that it's 0 on your AND Nico's computer leaves me at a loss (and this is
what causes the lockfile exists issue), it should contain garbage
(which would cause fetchmail to erase the lockfile in most of the
cases).
It *tries* to tell me something:
Please report logging issues separately. Merging two issues into one bug
report isn't particularly helpful. I'm cloning the bug.
Patch description (doesn't address logging): (1) fix lockfile bug, by
treating short lockfiles as stale. (2) close the lockfile stream before
attempting to delete the file, and report removing stale lockfile
before trying so. (Note that the fclose() before exit() is just
cosmetics and not fixing a leak, exit() is supposed to close all open
files anyways.)
--
Matthias Andree
Index: lock.c
===
--- lock.c (revision 4826)
+++ lock.c (working copy)
@@ -85,20 +85,21 @@
if (ferror(lockfp)) {
fprintf(stderr, GT_(fetchmail: error reading lockfile \%s\: %s\n),
lockfile, strerror(errno));
+ fclose(lockfp); /* not checking should be safe, file mode was r */
exit(PS_EXCLUDE);
}
+ fclose(lockfp); /* not checking should be safe, file mode was r */
- if (args == 0 || kill(pid, 0) == -1) {
+ if (args == EOF || args == 0 || kill(pid, 0) == -1) {
pid = 0;
+
+ fprintf(stderr,GT_(fetchmail: removing stale lockfile\n));
if (unlink(lockfile)) {
if (errno != ENOENT) {
perror(lockfile);
}
- } else {
- fprintf(stderr,GT_(fetchmail: removing stale lockfile\n));
}
}
- fclose(lockfp); /* not checking should be safe, file mode was r */
} else {
pid = 0;
if (errno != ENOENT) {
