On Tue, Mar 25, 2014 at 09:58:31PM +0100, Pablo Neira Ayuso wrote: > On Tue, Mar 11, 2014 at 06:31:13PM -0700, Ansis Atteka wrote: > > Before this patch, if conntrackd died in an abrupt manner (either > > by SIGKILL, SIGSEGV or abrupt shutdown), then it would have left > > a stale lock file that would have prevented any new conntrackd > > instances from running. > > SIGKILL and SIGSEGV need a closer look from the admin, since things > are not going right. Sudden (abrupt) shutdown is indeed a problem. > > > Contrary to abrupt termination, this same bug was not present when > > conntrackd was terminated with a graceful signal (e.g. SIGTERM). > > This was because then the lock file would have been removed from > > the signal handler as expected. > > > > This patch fixes this bug by using POSIX File Locking API instead > > of opening file in O_EXCL mode. File Locking API ensures that file > > lock will be released once the process holding it terminates (either > > gracefully or abruptly). > > > > One side effect of this patch is that daemonization has to happen > > before the lock file is locked (due to the fact that child processes > > do not inherit file locks from the parent process). This means that > > some error messages have to be logged in log file instead of STDOUT. > > Can you rework this to avoid converting all those message from stdout > to the log file? I like that this daemon bails out to stdout if early > problems are found, I find it quite annoying when you launch things > and then you have to check ps and log file to see the reason for an > early configuration problem. And I don't find a good reason why we > need an early daemonization that this patch introduces. Now I noticed after reading my own words, this can be problematic if someone just types 'conntrackd' by mistake instead of 'conntrackd -e' to dump the external cache. What about using two locks? I mean, one that is grabbed when the process is in non-daemon stage, then another one once one it enters daemon stage. I think that should help to workaround the posix file locking limitation which doesn't allow us to inherit lock file? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
