2009-07-08 13:19:16 -07:00
|
|
|
/*
|
2012-05-02 15:21:36 -07:00
|
|
|
* Copyright (c) 2008, 2009, 2010, 2011, 2012 Nicira, Inc.
|
2009-07-08 13:19:16 -07:00
|
|
|
*
|
2009-06-15 15:11:30 -07:00
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at:
|
2009-07-08 13:19:16 -07:00
|
|
|
*
|
2009-06-15 15:11:30 -07:00
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
2009-07-08 13:19:16 -07:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
#include "daemon.h"
|
2012-01-27 09:53:17 -08:00
|
|
|
#include <assert.h>
|
2009-07-08 13:19:16 -07:00
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
2010-05-26 10:37:39 -07:00
|
|
|
#include <signal.h>
|
2009-07-08 13:19:16 -07:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2010-05-26 10:37:39 -07:00
|
|
|
#include <sys/resource.h>
|
2009-12-17 10:56:01 -08:00
|
|
|
#include <sys/wait.h>
|
2010-10-14 22:59:11 +00:00
|
|
|
#include <sys/stat.h>
|
2009-07-08 13:19:16 -07:00
|
|
|
#include <unistd.h>
|
2010-01-19 15:00:56 -08:00
|
|
|
#include "command-line.h"
|
2009-07-08 13:19:16 -07:00
|
|
|
#include "fatal-signal.h"
|
|
|
|
#include "dirs.h"
|
2009-10-14 16:52:04 -07:00
|
|
|
#include "lockfile.h"
|
2010-01-15 12:13:46 -08:00
|
|
|
#include "process.h"
|
2009-12-18 13:46:33 -08:00
|
|
|
#include "socket-util.h"
|
2009-10-15 10:39:10 -07:00
|
|
|
#include "timeval.h"
|
2009-07-08 13:19:16 -07:00
|
|
|
#include "util.h"
|
|
|
|
#include "vlog.h"
|
|
|
|
|
2010-10-19 14:47:01 -07:00
|
|
|
VLOG_DEFINE_THIS_MODULE(daemon);
|
2010-07-16 11:02:49 -07:00
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
/* --detach: Should we run in the background? */
|
2012-05-21 11:08:59 -07:00
|
|
|
static bool detach; /* Was --detach specified? */
|
|
|
|
static bool detached; /* Have we already detached? */
|
2009-07-08 13:19:16 -07:00
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
/* --pidfile: Name of pidfile (null if none). */
|
2009-07-08 13:19:16 -07:00
|
|
|
static char *pidfile;
|
|
|
|
|
2010-09-23 09:39:47 -07:00
|
|
|
/* Device and inode of pidfile, so we can avoid reopening it. */
|
|
|
|
static dev_t pidfile_dev;
|
|
|
|
static ino_t pidfile_ino;
|
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
/* --overwrite-pidfile: Create pidfile even if one already exists and is
|
|
|
|
locked? */
|
2009-08-05 14:20:24 -07:00
|
|
|
static bool overwrite_pidfile;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
/* --no-chdir: Should we chdir to "/"? */
|
2009-08-04 22:41:46 -07:00
|
|
|
static bool chdir_ = true;
|
|
|
|
|
2010-01-15 15:29:52 -08:00
|
|
|
/* File descriptor used by daemonize_start() and daemonize_complete(). */
|
|
|
|
static int daemonize_fd = -1;
|
2009-12-17 10:56:01 -08:00
|
|
|
|
2010-01-15 12:13:46 -08:00
|
|
|
/* --monitor: Should a supervisory process monitor the daemon and restart it if
|
|
|
|
* it dies due to an error signal? */
|
|
|
|
static bool monitor;
|
|
|
|
|
2012-01-27 09:53:17 -08:00
|
|
|
/* For each of the standard file descriptors, whether to replace it by
|
|
|
|
* /dev/null (if false) or keep it for the daemon to use (if true). */
|
|
|
|
static bool save_fds[3];
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
static void check_already_running(void);
|
|
|
|
static int lock_pidfile(FILE *, int command);
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
/* Returns the file name that would be used for a pidfile if 'name' were
|
|
|
|
* provided to set_pidfile(). The caller must free the returned string. */
|
|
|
|
char *
|
2010-08-30 00:24:53 -07:00
|
|
|
make_pidfile_name(const char *name)
|
2009-07-08 13:19:16 -07:00
|
|
|
{
|
2010-03-16 15:06:11 -07:00
|
|
|
return (!name
|
2010-11-29 12:28:26 -08:00
|
|
|
? xasprintf("%s/%s.pid", ovs_rundir(), program_name)
|
|
|
|
: abs_file_name(ovs_rundir(), name));
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Sets up a following call to daemonize() to create a pidfile named 'name'.
|
|
|
|
* If 'name' begins with '/', then it is treated as an absolute path.
|
|
|
|
* Otherwise, it is taken relative to RUNDIR, which is $(prefix)/var/run by
|
|
|
|
* default.
|
|
|
|
*
|
|
|
|
* If 'name' is null, then program_name followed by ".pid" is used. */
|
|
|
|
void
|
|
|
|
set_pidfile(const char *name)
|
|
|
|
{
|
|
|
|
free(pidfile);
|
|
|
|
pidfile = make_pidfile_name(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Returns an absolute path to the configured pidfile, or a null pointer if no
|
|
|
|
* pidfile is configured. The caller must not modify or free the returned
|
|
|
|
* string. */
|
|
|
|
const char *
|
|
|
|
get_pidfile(void)
|
|
|
|
{
|
|
|
|
return pidfile;
|
|
|
|
}
|
|
|
|
|
2009-08-04 22:41:46 -07:00
|
|
|
/* Sets that we do not chdir to "/". */
|
|
|
|
void
|
|
|
|
set_no_chdir(void)
|
|
|
|
{
|
|
|
|
chdir_ = false;
|
|
|
|
}
|
|
|
|
|
2009-11-16 15:09:50 -08:00
|
|
|
/* Will we chdir to "/" as part of daemonizing? */
|
|
|
|
bool
|
|
|
|
is_chdir_enabled(void)
|
|
|
|
{
|
|
|
|
return chdir_;
|
|
|
|
}
|
|
|
|
|
2011-03-31 09:44:30 -07:00
|
|
|
/* Normally, daemonize() or damonize_start() will terminate the program with a
|
|
|
|
* message if a locked pidfile already exists. If this function is called, an
|
|
|
|
* existing pidfile will be replaced, with a warning. */
|
2009-07-08 13:19:16 -07:00
|
|
|
void
|
|
|
|
ignore_existing_pidfile(void)
|
|
|
|
{
|
2009-08-05 14:20:24 -07:00
|
|
|
overwrite_pidfile = true;
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Sets up a following call to daemonize() to detach from the foreground
|
|
|
|
* session, running this process in the background. */
|
|
|
|
void
|
|
|
|
set_detach(void)
|
|
|
|
{
|
|
|
|
detach = true;
|
|
|
|
}
|
|
|
|
|
2009-11-16 15:09:50 -08:00
|
|
|
/* Will daemonize() really detach? */
|
|
|
|
bool
|
|
|
|
get_detach(void)
|
|
|
|
{
|
|
|
|
return detach;
|
|
|
|
}
|
|
|
|
|
2010-01-15 12:13:46 -08:00
|
|
|
/* Sets up a following call to daemonize() to fork a supervisory process to
|
|
|
|
* monitor the daemon and restart it if it dies due to an error signal. */
|
|
|
|
void
|
|
|
|
daemon_set_monitor(void)
|
|
|
|
{
|
|
|
|
monitor = true;
|
|
|
|
}
|
|
|
|
|
2012-01-27 09:53:17 -08:00
|
|
|
/* A daemon doesn't normally have any use for the file descriptors for stdin,
|
|
|
|
* stdout, and stderr after it detaches. To keep these file descriptors from
|
|
|
|
* e.g. holding an SSH session open, by default detaching replaces each of
|
|
|
|
* these file descriptors by /dev/null. But a few daemons expect the user to
|
|
|
|
* redirect stdout or stderr to a file, in which case it is desirable to keep
|
|
|
|
* these file descriptors. This function, therefore, disables replacing 'fd'
|
|
|
|
* by /dev/null when the daemon detaches. */
|
|
|
|
void
|
|
|
|
daemon_save_fd(int fd)
|
|
|
|
{
|
|
|
|
assert(fd == STDIN_FILENO || fd == STDOUT_FILENO || fd == STDERR_FILENO);
|
|
|
|
save_fds[fd] = true;
|
|
|
|
}
|
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
/* If a pidfile has been configured, creates it and stores the running
|
|
|
|
* process's pid in it. Ensures that the pidfile will be deleted when the
|
|
|
|
* process exits. */
|
2009-07-08 13:19:16 -07:00
|
|
|
static void
|
|
|
|
make_pidfile(void)
|
|
|
|
{
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
long int pid = getpid();
|
|
|
|
struct stat s;
|
|
|
|
char *tmpfile;
|
|
|
|
FILE *file;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/* Create a temporary pidfile. */
|
2012-11-14 18:34:14 -08:00
|
|
|
if (overwrite_pidfile) {
|
|
|
|
tmpfile = xasprintf("%s.tmp%ld", pidfile, pid);
|
|
|
|
fatal_signal_add_file_to_unlink(tmpfile);
|
|
|
|
} else {
|
|
|
|
/* Everyone shares the same file which will be treated as a lock. To
|
|
|
|
* avoid some uncomfortable race conditions, we can't set up the fatal
|
|
|
|
* signal unlink until we've acquired it. */
|
|
|
|
tmpfile = xasprintf("%s.tmp", pidfile);
|
|
|
|
}
|
|
|
|
|
|
|
|
file = fopen(tmpfile, "a+");
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
if (!file) {
|
|
|
|
VLOG_FATAL("%s: create failed (%s)", tmpfile, strerror(errno));
|
|
|
|
}
|
|
|
|
|
2012-11-14 18:34:14 -08:00
|
|
|
error = lock_pidfile(file, F_SETLK);
|
|
|
|
if (error) {
|
|
|
|
/* Looks like we failed to acquire the lock. Note that, if we failed
|
|
|
|
* for some other reason (and '!overwrite_pidfile'), we will have
|
|
|
|
* left 'tmpfile' as garbage in the file system. */
|
|
|
|
VLOG_FATAL("%s: fcntl(F_SETLK) failed (%s)", tmpfile, strerror(error));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!overwrite_pidfile) {
|
|
|
|
/* We acquired the lock. Make sure to clean up on exit, and verify
|
|
|
|
* that we're allowed to create the actual pidfile. */
|
|
|
|
fatal_signal_add_file_to_unlink(tmpfile);
|
|
|
|
check_already_running();
|
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
if (fstat(fileno(file), &s) == -1) {
|
|
|
|
VLOG_FATAL("%s: fstat failed (%s)", tmpfile, strerror(errno));
|
|
|
|
}
|
|
|
|
|
2012-11-14 18:34:14 -08:00
|
|
|
if (ftruncate(fileno(file), 0) == -1) {
|
|
|
|
VLOG_FATAL("%s: truncate failed (%s)", tmpfile, strerror(errno));
|
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
fprintf(file, "%ld\n", pid);
|
|
|
|
if (fflush(file) == EOF) {
|
|
|
|
VLOG_FATAL("%s: write failed (%s)", tmpfile, strerror(errno));
|
|
|
|
}
|
|
|
|
|
2012-11-14 18:34:14 -08:00
|
|
|
error = rename(tmpfile, pidfile);
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
|
2012-11-14 18:34:14 -08:00
|
|
|
/* Due to a race, 'tmpfile' may be owned by a different process, so we
|
|
|
|
* shouldn't delete it on exit. */
|
|
|
|
fatal_signal_remove_file_to_unlink(tmpfile);
|
|
|
|
|
|
|
|
if (error < 0) {
|
|
|
|
VLOG_FATAL("failed to rename \"%s\" to \"%s\" (%s)",
|
|
|
|
tmpfile, pidfile, strerror(errno));
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Ensure that the pidfile will get deleted on exit. */
|
|
|
|
fatal_signal_add_file_to_unlink(pidfile);
|
|
|
|
|
|
|
|
/* Clean up.
|
|
|
|
*
|
|
|
|
* We don't close 'file' because its file descriptor must remain open to
|
|
|
|
* hold the lock. */
|
|
|
|
pidfile_dev = s.st_dev;
|
|
|
|
pidfile_ino = s.st_ino;
|
|
|
|
free(tmpfile);
|
2009-07-08 13:19:16 -07:00
|
|
|
free(pidfile);
|
|
|
|
pidfile = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If configured with set_pidfile() or set_detach(), creates the pid file and
|
|
|
|
* detaches from the foreground session. */
|
|
|
|
void
|
|
|
|
daemonize(void)
|
2009-12-17 10:56:01 -08:00
|
|
|
{
|
|
|
|
daemonize_start();
|
|
|
|
daemonize_complete();
|
|
|
|
}
|
|
|
|
|
2012-05-21 11:08:13 -07:00
|
|
|
/* Calls fork() and on success returns its return value. On failure, logs an
|
|
|
|
* error and exits unsuccessfully.
|
|
|
|
*
|
|
|
|
* Post-fork, but before returning, this function calls a few other functions
|
|
|
|
* that are generally useful if the child isn't planning to exec a new
|
|
|
|
* process. */
|
|
|
|
pid_t
|
|
|
|
fork_and_clean_up(void)
|
|
|
|
{
|
|
|
|
pid_t pid;
|
|
|
|
|
|
|
|
pid = fork();
|
|
|
|
if (pid > 0) {
|
|
|
|
/* Running in parent process. */
|
|
|
|
fatal_signal_fork();
|
|
|
|
} else if (!pid) {
|
|
|
|
/* Running in child process. */
|
|
|
|
time_postfork();
|
|
|
|
lockfile_postfork();
|
|
|
|
} else {
|
|
|
|
VLOG_FATAL("fork failed (%s)", strerror(errno));
|
|
|
|
}
|
|
|
|
|
|
|
|
return pid;
|
|
|
|
}
|
|
|
|
|
2012-05-14 14:21:18 -07:00
|
|
|
/* Forks, then:
|
|
|
|
*
|
|
|
|
* - In the parent, waits for the child to signal that it has completed its
|
|
|
|
* startup sequence. Then stores -1 in '*fdp' and returns the child's pid.
|
|
|
|
*
|
|
|
|
* - In the child, stores a fd in '*fdp' and returns 0. The caller should
|
|
|
|
* pass the fd to fork_notify_startup() after it finishes its startup
|
|
|
|
* sequence.
|
|
|
|
*
|
|
|
|
* If something goes wrong with the fork, logs a critical error and aborts the
|
|
|
|
* process. */
|
2010-01-15 15:29:52 -08:00
|
|
|
static pid_t
|
|
|
|
fork_and_wait_for_startup(int *fdp)
|
|
|
|
{
|
|
|
|
int fds[2];
|
|
|
|
pid_t pid;
|
|
|
|
|
2011-03-31 16:23:50 -07:00
|
|
|
xpipe(fds);
|
2010-01-15 15:29:52 -08:00
|
|
|
|
2012-05-21 11:08:13 -07:00
|
|
|
pid = fork_and_clean_up();
|
2010-01-15 15:29:52 -08:00
|
|
|
if (pid > 0) {
|
|
|
|
/* Running in parent process. */
|
2011-03-31 09:36:10 -07:00
|
|
|
size_t bytes_read;
|
2010-01-15 15:29:52 -08:00
|
|
|
char c;
|
|
|
|
|
|
|
|
close(fds[1]);
|
2011-03-31 09:36:10 -07:00
|
|
|
if (read_fully(fds[0], &c, 1, &bytes_read) != 0) {
|
2010-01-15 15:29:52 -08:00
|
|
|
int retval;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
do {
|
|
|
|
retval = waitpid(pid, &status, 0);
|
|
|
|
} while (retval == -1 && errno == EINTR);
|
|
|
|
|
2011-11-23 12:15:42 -08:00
|
|
|
if (retval == pid) {
|
|
|
|
if (WIFEXITED(status) && WEXITSTATUS(status)) {
|
|
|
|
/* Child exited with an error. Convey the same error
|
|
|
|
* to our parent process as a courtesy. */
|
|
|
|
exit(WEXITSTATUS(status));
|
|
|
|
} else {
|
|
|
|
char *status_msg = process_status_msg(status);
|
|
|
|
VLOG_FATAL("fork child died before signaling startup (%s)",
|
|
|
|
status_msg);
|
|
|
|
}
|
|
|
|
} else if (retval < 0) {
|
|
|
|
VLOG_FATAL("waitpid failed (%s)", strerror(errno));
|
|
|
|
} else {
|
|
|
|
NOT_REACHED();
|
2010-01-15 15:29:52 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
close(fds[0]);
|
|
|
|
*fdp = -1;
|
|
|
|
} else if (!pid) {
|
|
|
|
/* Running in child process. */
|
|
|
|
close(fds[0]);
|
|
|
|
*fdp = fds[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
return pid;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
fork_notify_startup(int fd)
|
|
|
|
{
|
|
|
|
if (fd != -1) {
|
|
|
|
size_t bytes_written;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = write_fully(fd, "", 1, &bytes_written);
|
|
|
|
if (error) {
|
2011-03-31 16:23:50 -07:00
|
|
|
VLOG_FATAL("pipe write failed (%s)", strerror(error));
|
2010-01-15 15:29:52 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-15 12:13:46 -08:00
|
|
|
static bool
|
|
|
|
should_restart(int status)
|
|
|
|
{
|
|
|
|
if (WIFSIGNALED(status)) {
|
|
|
|
static const int error_signals[] = {
|
|
|
|
SIGABRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV,
|
|
|
|
SIGXCPU, SIGXFSZ
|
|
|
|
};
|
|
|
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(error_signals); i++) {
|
|
|
|
if (error_signals[i] == WTERMSIG(status)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
monitor_daemon(pid_t daemon_pid)
|
|
|
|
{
|
|
|
|
/* XXX Should log daemon's stderr output at startup time. */
|
2010-05-12 10:02:23 -07:00
|
|
|
time_t last_restart;
|
2010-01-19 15:00:56 -08:00
|
|
|
char *status_msg;
|
2010-09-21 14:27:02 -07:00
|
|
|
int crashes;
|
2010-01-15 12:13:46 -08:00
|
|
|
|
2012-07-18 10:30:47 -07:00
|
|
|
subprogram_name = "monitor";
|
2010-01-19 15:00:56 -08:00
|
|
|
status_msg = xstrdup("healthy");
|
2010-05-12 10:02:23 -07:00
|
|
|
last_restart = TIME_MIN;
|
2010-09-21 14:27:02 -07:00
|
|
|
crashes = 0;
|
2010-01-15 12:13:46 -08:00
|
|
|
for (;;) {
|
|
|
|
int retval;
|
|
|
|
int status;
|
|
|
|
|
2012-10-11 20:49:38 +00:00
|
|
|
proctitle_set("monitoring pid %lu (%s)",
|
|
|
|
(unsigned long int) daemon_pid, status_msg);
|
2010-01-19 15:00:56 -08:00
|
|
|
|
2010-01-15 12:13:46 -08:00
|
|
|
do {
|
|
|
|
retval = waitpid(daemon_pid, &status, 0);
|
|
|
|
} while (retval == -1 && errno == EINTR);
|
|
|
|
|
|
|
|
if (retval == -1) {
|
2011-03-31 16:23:50 -07:00
|
|
|
VLOG_FATAL("waitpid failed (%s)", strerror(errno));
|
2010-01-15 12:13:46 -08:00
|
|
|
} else if (retval == daemon_pid) {
|
2010-01-19 15:00:56 -08:00
|
|
|
char *s = process_status_msg(status);
|
|
|
|
if (should_restart(status)) {
|
2010-10-27 09:29:08 -07:00
|
|
|
free(status_msg);
|
|
|
|
status_msg = xasprintf("%d crashes: pid %lu died, %s",
|
|
|
|
++crashes,
|
|
|
|
(unsigned long int) daemon_pid, s);
|
|
|
|
free(s);
|
|
|
|
|
2010-05-11 10:56:10 -07:00
|
|
|
if (WCOREDUMP(status)) {
|
|
|
|
/* Disable further core dumps to save disk space. */
|
|
|
|
struct rlimit r;
|
|
|
|
|
|
|
|
r.rlim_cur = 0;
|
|
|
|
r.rlim_max = 0;
|
|
|
|
if (setrlimit(RLIMIT_CORE, &r) == -1) {
|
|
|
|
VLOG_WARN("failed to disable core dumps: %s",
|
|
|
|
strerror(errno));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-12 10:02:23 -07:00
|
|
|
/* Throttle restarts to no more than once every 10 seconds. */
|
|
|
|
if (time(NULL) < last_restart + 10) {
|
|
|
|
VLOG_WARN("%s, waiting until 10 seconds since last "
|
|
|
|
"restart", status_msg);
|
|
|
|
for (;;) {
|
|
|
|
time_t now = time(NULL);
|
|
|
|
time_t wakeup = last_restart + 10;
|
|
|
|
if (now >= wakeup) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
sleep(wakeup - now);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
last_restart = time(NULL);
|
|
|
|
|
2010-01-19 15:00:56 -08:00
|
|
|
VLOG_ERR("%s, restarting", status_msg);
|
2010-01-15 12:13:46 -08:00
|
|
|
daemon_pid = fork_and_wait_for_startup(&daemonize_fd);
|
|
|
|
if (!daemon_pid) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} else {
|
2010-10-27 09:29:08 -07:00
|
|
|
VLOG_INFO("pid %lu died, %s, exiting",
|
|
|
|
(unsigned long int) daemon_pid, s);
|
|
|
|
free(s);
|
2010-01-15 12:13:46 -08:00
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-02-02 14:36:19 -08:00
|
|
|
free(status_msg);
|
2010-01-15 12:13:46 -08:00
|
|
|
|
|
|
|
/* Running in new daemon process. */
|
2010-01-19 15:00:56 -08:00
|
|
|
proctitle_restore();
|
2012-07-18 10:30:47 -07:00
|
|
|
subprogram_name = "";
|
2010-01-15 12:13:46 -08:00
|
|
|
}
|
|
|
|
|
2012-01-27 09:53:17 -08:00
|
|
|
/* Close standard file descriptors (except any that the client has requested we
|
|
|
|
* leave open by calling daemon_save_fd()). If we're started from e.g. an SSH
|
|
|
|
* session, then this keeps us from holding that session open artificially. */
|
2010-01-15 15:29:52 -08:00
|
|
|
static void
|
|
|
|
close_standard_fds(void)
|
|
|
|
{
|
|
|
|
int null_fd = get_null_fd();
|
|
|
|
if (null_fd >= 0) {
|
2012-01-27 09:53:17 -08:00
|
|
|
int fd;
|
|
|
|
|
|
|
|
for (fd = 0; fd < 3; fd++) {
|
|
|
|
if (!save_fds[fd]) {
|
|
|
|
dup2(null_fd, fd);
|
|
|
|
}
|
|
|
|
}
|
2010-01-15 15:29:52 -08:00
|
|
|
}
|
2011-06-14 16:08:59 -07:00
|
|
|
|
|
|
|
/* Disable logging to stderr to avoid wasting CPU time. */
|
2011-07-28 10:19:42 -07:00
|
|
|
vlog_set_levels(NULL, VLF_CONSOLE, VLL_OFF);
|
2010-01-15 15:29:52 -08:00
|
|
|
}
|
|
|
|
|
2009-12-17 10:56:01 -08:00
|
|
|
/* If daemonization is configured, then starts daemonization, by forking and
|
|
|
|
* returning in the child process. The parent process hangs around until the
|
|
|
|
* child lets it know either that it completed startup successfully (by calling
|
|
|
|
* daemon_complete()) or that it failed to start up (by exiting with a nonzero
|
|
|
|
* exit code). */
|
|
|
|
void
|
|
|
|
daemonize_start(void)
|
2009-07-08 13:19:16 -07:00
|
|
|
{
|
2010-01-15 15:29:52 -08:00
|
|
|
daemonize_fd = -1;
|
2009-12-17 10:56:01 -08:00
|
|
|
|
2010-01-15 15:29:52 -08:00
|
|
|
if (detach) {
|
|
|
|
if (fork_and_wait_for_startup(&daemonize_fd) > 0) {
|
2009-12-17 10:56:01 -08:00
|
|
|
/* Running in parent process. */
|
2009-07-08 13:19:16 -07:00
|
|
|
exit(0);
|
|
|
|
}
|
2010-01-15 12:13:46 -08:00
|
|
|
/* Running in daemon or monitor process. */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (monitor) {
|
|
|
|
int saved_daemonize_fd = daemonize_fd;
|
|
|
|
pid_t daemon_pid;
|
|
|
|
|
|
|
|
daemon_pid = fork_and_wait_for_startup(&daemonize_fd);
|
|
|
|
if (daemon_pid > 0) {
|
|
|
|
/* Running in monitor process. */
|
|
|
|
fork_notify_startup(saved_daemonize_fd);
|
|
|
|
close_standard_fds();
|
|
|
|
monitor_daemon(daemon_pid);
|
|
|
|
}
|
2010-01-15 15:29:52 -08:00
|
|
|
/* Running in daemon process. */
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
2010-01-15 15:29:52 -08:00
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
if (pidfile) {
|
|
|
|
make_pidfile();
|
|
|
|
}
|
2010-08-12 09:47:33 -07:00
|
|
|
|
|
|
|
/* Make sure that the unixctl commands for vlog get registered in a
|
|
|
|
* daemon, even before the first log message. */
|
|
|
|
vlog_init();
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
|
|
|
|
2009-12-17 10:56:01 -08:00
|
|
|
/* If daemonization is configured, then this function notifies the parent
|
2012-05-21 11:08:59 -07:00
|
|
|
* process that the child process has completed startup successfully. It also
|
|
|
|
* call daemonize_post_detach().
|
2011-01-28 12:44:00 -08:00
|
|
|
*
|
|
|
|
* Calling this function more than once has no additional effect. */
|
2009-12-17 10:56:01 -08:00
|
|
|
void
|
|
|
|
daemonize_complete(void)
|
|
|
|
{
|
2012-05-21 11:08:59 -07:00
|
|
|
if (!detached) {
|
|
|
|
detached = true;
|
|
|
|
|
|
|
|
fork_notify_startup(daemonize_fd);
|
|
|
|
daemonize_fd = -1;
|
|
|
|
daemonize_post_detach();
|
|
|
|
}
|
|
|
|
}
|
2009-12-17 10:56:01 -08:00
|
|
|
|
2012-05-21 11:08:59 -07:00
|
|
|
/* If daemonization is configured, then this function does traditional Unix
|
|
|
|
* daemonization behavior: join a new session, chdir to the root (if not
|
|
|
|
* disabled), and close the standard file descriptors.
|
|
|
|
*
|
|
|
|
* It only makes sense to call this function as part of an implementation of a
|
|
|
|
* special daemon subprocess. A normal daemon should just call
|
|
|
|
* daemonize_complete(). */
|
|
|
|
void
|
|
|
|
daemonize_post_detach(void)
|
|
|
|
{
|
2010-01-15 15:29:52 -08:00
|
|
|
if (detach) {
|
2009-12-17 10:56:01 -08:00
|
|
|
setsid();
|
|
|
|
if (chdir_) {
|
|
|
|
ignore(chdir("/"));
|
|
|
|
}
|
2010-01-15 15:29:52 -08:00
|
|
|
close_standard_fds();
|
2009-12-17 10:56:01 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-08 13:19:16 -07:00
|
|
|
void
|
|
|
|
daemon_usage(void)
|
|
|
|
{
|
|
|
|
printf(
|
|
|
|
"\nDaemon options:\n"
|
2009-08-05 14:20:24 -07:00
|
|
|
" --detach run in background as daemon\n"
|
2009-08-04 22:41:46 -07:00
|
|
|
" --no-chdir do not chdir to '/'\n"
|
2009-08-05 14:20:24 -07:00
|
|
|
" --pidfile[=FILE] create pidfile (default: %s/%s.pid)\n"
|
|
|
|
" --overwrite-pidfile with --pidfile, start even if already "
|
|
|
|
"running\n",
|
2010-11-29 12:28:26 -08:00
|
|
|
ovs_rundir(), program_name);
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
static int
|
|
|
|
lock_pidfile__(FILE *file, int command, struct flock *lck)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
lck->l_type = F_WRLCK;
|
|
|
|
lck->l_whence = SEEK_SET;
|
|
|
|
lck->l_start = 0;
|
|
|
|
lck->l_len = 0;
|
|
|
|
lck->l_pid = 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
error = fcntl(fileno(file), command, lck) == -1 ? errno : 0;
|
|
|
|
} while (error == EINTR);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
lock_pidfile(FILE *file, int command)
|
|
|
|
{
|
|
|
|
struct flock lck;
|
|
|
|
|
|
|
|
return lock_pidfile__(file, command, &lck);
|
|
|
|
}
|
|
|
|
|
2011-03-29 09:44:55 -07:00
|
|
|
static pid_t
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
read_pidfile__(const char *pidfile, bool delete_if_stale)
|
2009-07-08 13:19:16 -07:00
|
|
|
{
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
struct stat s, s2;
|
2009-07-08 13:19:16 -07:00
|
|
|
struct flock lck;
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
char line[128];
|
2009-07-08 13:19:16 -07:00
|
|
|
FILE *file;
|
|
|
|
int error;
|
|
|
|
|
2010-09-23 09:39:47 -07:00
|
|
|
if ((pidfile_ino || pidfile_dev)
|
|
|
|
&& !stat(pidfile, &s)
|
|
|
|
&& s.st_ino == pidfile_ino && s.st_dev == pidfile_dev) {
|
|
|
|
/* It's our own pidfile. We can't afford to open it, because closing
|
|
|
|
* *any* fd for a file that a process has locked also releases all the
|
|
|
|
* locks on that file.
|
|
|
|
*
|
|
|
|
* Fortunately, we know the associated pid anyhow: */
|
|
|
|
return getpid();
|
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
file = fopen(pidfile, "r+");
|
2009-07-08 13:19:16 -07:00
|
|
|
if (!file) {
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
if (errno == ENOENT && delete_if_stale) {
|
2011-03-29 09:44:55 -07:00
|
|
|
return 0;
|
|
|
|
}
|
2009-07-08 13:19:16 -07:00
|
|
|
error = errno;
|
|
|
|
VLOG_WARN("%s: open: %s", pidfile, strerror(error));
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
error = lock_pidfile__(file, F_GETLK, &lck);
|
|
|
|
if (error) {
|
2009-07-08 13:19:16 -07:00
|
|
|
VLOG_WARN("%s: fcntl: %s", pidfile, strerror(error));
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (lck.l_type == F_UNLCK) {
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
/* pidfile exists but it isn't locked by anyone. We need to delete it
|
|
|
|
* so that a new pidfile can go in its place. But just calling
|
|
|
|
* unlink(pidfile) makes a nasty race: what if someone else unlinks it
|
|
|
|
* before we do and then replaces it by a valid pidfile? We'd unlink
|
|
|
|
* their valid pidfile. We do a little dance to avoid the race, by
|
|
|
|
* locking the invalid pidfile. Only one process can have the invalid
|
|
|
|
* pidfile locked, and only that process has the right to unlink it. */
|
|
|
|
if (!delete_if_stale) {
|
|
|
|
error = ESRCH;
|
2011-04-05 12:17:08 -07:00
|
|
|
VLOG_DBG("%s: pid file is stale", pidfile);
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the lock. */
|
|
|
|
error = lock_pidfile(file, F_SETLK);
|
|
|
|
if (error) {
|
|
|
|
/* We lost a race with someone else doing the same thing. */
|
|
|
|
VLOG_WARN("%s: lost race to lock pidfile", pidfile);
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Is the file we have locked still named 'pidfile'? */
|
|
|
|
if (stat(pidfile, &s) || fstat(fileno(file), &s2)
|
|
|
|
|| s.st_ino != s2.st_ino || s.st_dev != s2.st_dev) {
|
|
|
|
/* No. We lost a race with someone else who got the lock before
|
|
|
|
* us, deleted the pidfile, and closed it (releasing the lock). */
|
|
|
|
error = EALREADY;
|
|
|
|
VLOG_WARN("%s: lost race to delete pidfile", pidfile);
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We won the right to delete the stale pidfile. */
|
|
|
|
if (unlink(pidfile)) {
|
|
|
|
error = errno;
|
|
|
|
VLOG_WARN("%s: failed to delete stale pidfile (%s)",
|
|
|
|
pidfile, strerror(error));
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
VLOG_DBG("%s: deleted stale pidfile", pidfile);
|
|
|
|
fclose(file);
|
|
|
|
return 0;
|
2009-07-08 13:19:16 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!fgets(line, sizeof line, file)) {
|
|
|
|
if (ferror(file)) {
|
|
|
|
error = errno;
|
|
|
|
VLOG_WARN("%s: read: %s", pidfile, strerror(error));
|
|
|
|
} else {
|
|
|
|
error = ESRCH;
|
|
|
|
VLOG_WARN("%s: read: unexpected end of file", pidfile);
|
|
|
|
}
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (lck.l_pid != strtoul(line, NULL, 10)) {
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
/* The process that has the pidfile locked is not the process that
|
|
|
|
* created it. It must be stale, with the process that has it locked
|
|
|
|
* preparing to delete it. */
|
2009-07-08 13:19:16 -07:00
|
|
|
error = ESRCH;
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
VLOG_WARN("%s: stale pidfile for pid %s being deleted by pid %ld",
|
|
|
|
pidfile, line, (long int) lck.l_pid);
|
2009-07-08 13:19:16 -07:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
fclose(file);
|
|
|
|
return lck.l_pid;
|
|
|
|
|
|
|
|
error:
|
|
|
|
if (file) {
|
|
|
|
fclose(file);
|
|
|
|
}
|
|
|
|
return -error;
|
|
|
|
}
|
2011-03-29 09:44:55 -07:00
|
|
|
|
|
|
|
/* Opens and reads a PID from 'pidfile'. Returns the positive PID if
|
|
|
|
* successful, otherwise a negative errno value. */
|
|
|
|
pid_t
|
|
|
|
read_pidfile(const char *pidfile)
|
|
|
|
{
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
return read_pidfile__(pidfile, false);
|
2011-03-29 09:44:55 -07:00
|
|
|
}
|
|
|
|
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
/* Checks whether a process with the given 'pidfile' is already running and,
|
|
|
|
* if so, aborts. If 'pidfile' is stale, deletes it. */
|
|
|
|
static void
|
|
|
|
check_already_running(void)
|
2011-03-29 09:44:55 -07:00
|
|
|
{
|
daemon: Avoid races on pidfile creation.
Until now, if two copies of one OVS daemon started up at the same time,
then due to races in pidfile creation it was possible for both of them to
start successfully, instead of just one. This was made worse when a
previous copy of the daemon had died abruptly, leaving a stale pidfile.
This commit implements a new pidfile creation and removal protocol that I
believe closes these races. Now, a pidfile is asserted with "link" instead
of "rename", which prevents the race on creation, and a stale pidfile may
only be deleted by a process after it has taken a lock on it.
This may solve mysterious problems seen occasionally on vswitch restart.
I'm still puzzled by these problems, however, because I don't see anything
in our tests cases that would actually cause two copies of a daemon to
start at the same time, which as far as I can see is a necessary
precondition for the problem.
2011-04-04 10:59:19 -07:00
|
|
|
long int pid = read_pidfile__(pidfile, true);
|
|
|
|
if (pid > 0) {
|
|
|
|
VLOG_FATAL("%s: already running as pid %ld, aborting", pidfile, pid);
|
|
|
|
} else if (pid < 0) {
|
|
|
|
VLOG_FATAL("%s: pidfile check failed (%s), aborting",
|
|
|
|
pidfile, strerror(-pid));
|
|
|
|
}
|
2011-03-29 09:44:55 -07:00
|
|
|
}
|