diff options
| -rw-r--r-- | NEWS | 2 | ||||
| -rw-r--r-- | lock.c | 17 | ||||
| -rw-r--r-- | lock.h | 3 |
3 files changed, 20 insertions, 2 deletions
@@ -60,6 +60,8 @@ fetchmail 6.3.6 (not yet released): #9412, #9449. Stack backtrace provided by Neil Hoggarth - thanks. * Repair --logfile, broken in 6.3.5. BerliOS Bug #9059, reported by Brian Harring. +* Robustness: If a stale lockfile cannot be deleted, truncate it to avoid + trouble later if the PID is recycled by a non-fetchmail process. # TRANSLATIONS: * New en_GB (British English) translation by David Lodge. @@ -91,12 +91,27 @@ int fm_lock_state(void) fclose(lockfp); /* not checking should be safe, file mode was "r" */ if (args == EOF || args == 0 || kill(pid, 0) == -1) { + /* ^ could not read PID || process does not exist */ + /* => lockfile is stale, unlink it */ pid = 0; - fprintf(stderr,GT_("fetchmail: removing stale lockfile\n")); if (unlink(lockfile)) { if (errno != ENOENT) { perror(lockfile); + /* we complain but we don't exit; it might be + * writable for us, but in a directory we cannot + * write to. This means we can write the new PID to + * the file. Truncate to be safe in case the PID is + * recycled by another process later. + * \bug we should use fcntl() style locks or + * something else instead in a future release. */ + if (truncate(lockfile, (off_t)0)) { + /* but if we cannot truncate the file either, + * assume that we cannot write to it later, + * complain and quit. */ + perror(lockfile); + exit(PS_EXCLUDE); + } } } } @@ -22,7 +22,8 @@ void fm_lock_release(void); /** Check the state of the lock file. If there is an error opening or * reading the lockfile, exit with PS_EXCLUDE. If a stale lock file - * cannot be unlinked, complain, but continue. \return + * cannot be unlinked, complain and try to truncate it to 0 size. If + * truncation fails, complain and exit with PS_EXCLUDE. \return * - 0 if no lock is set * - >0 if a fetchmail is running, but not in daemon mode * - <0 if a fetchmail is running in daemon mode. |