2009-07-08 13:19:16 -07:00
|
|
|
|
/*
|
2013-06-19 13:07:35 -07:00
|
|
|
|
* Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013 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"
|
2014-04-23 14:22:38 -07:00
|
|
|
|
#include "daemon-private.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"
|
2013-06-19 13:07:35 -07:00
|
|
|
|
#include "ovs-thread.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"
|
2014-12-15 14:10:38 +01:00
|
|
|
|
#include "openvswitch/vlog.h"
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
2014-04-23 09:03:38 -07:00
|
|
|
|
VLOG_DEFINE_THIS_MODULE(daemon_unix);
|
2010-07-16 11:02:49 -07:00
|
|
|
|
|
2010-08-22 23:13:35 -07:00
|
|
|
|
/* --detach: Should we run in the background? */
|
2014-04-23 14:22:38 -07:00
|
|
|
|
bool detach; /* Was --detach specified? */
|
2012-05-21 11:08:59 -07:00
|
|
|
|
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). */
|
2014-04-23 14:22:38 -07:00
|
|
|
|
char *pidfile;
|
2009-07-08 13:19:16 -07:00
|
|
|
|
|
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;
|
|
|
|
|
|
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);
|
2014-01-10 08:33:15 -08:00
|
|
|
|
static pid_t fork_and_clean_up(void);
|
|
|
|
|
static void daemonize_post_detach(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
|
|
|
|
|
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. */
|
2014-04-23 14:22:38 -07:00
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
|
2009-08-04 22:41:46 -07:00
|
|
|
|
/* Sets that we do not chdir to "/". */
|
|
|
|
|
void
|
|
|
|
|
set_no_chdir(void)
|
|
|
|
|
{
|
|
|
|
|
chdir_ = false;
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("%s: create failed (%s)", tmpfile, ovs_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
|
|
|
|
}
|
|
|
|
|
|
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. */
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("%s: fcntl(F_SETLK) failed (%s)", tmpfile,
|
|
|
|
|
ovs_strerror(error));
|
2012-11-14 18:34:14 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("%s: fstat failed (%s)", tmpfile, ovs_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
|
|
|
|
}
|
|
|
|
|
|
2012-11-14 18:34:14 -08:00
|
|
|
|
if (ftruncate(fileno(file), 0) == -1) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("%s: truncate failed (%s)", tmpfile, ovs_strerror(errno));
|
2012-11-14 18:34:14 -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
|
|
|
|
fprintf(file, "%ld\n", pid);
|
|
|
|
|
if (fflush(file) == EOF) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("%s: write failed (%s)", tmpfile, ovs_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
|
|
|
|
}
|
|
|
|
|
|
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)",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
tmpfile, pidfile, ovs_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
|
|
|
|
}
|
|
|
|
|
|
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. */
|
2014-01-10 08:33:15 -08:00
|
|
|
|
static pid_t
|
2012-05-21 11:08:13 -07:00
|
|
|
|
fork_and_clean_up(void)
|
|
|
|
|
{
|
2013-06-19 13:07:35 -07:00
|
|
|
|
pid_t pid = xfork();
|
2012-05-21 11:08:13 -07:00
|
|
|
|
if (pid > 0) {
|
|
|
|
|
/* Running in parent process. */
|
|
|
|
|
fatal_signal_fork();
|
|
|
|
|
} else if (!pid) {
|
|
|
|
|
/* Running in child process. */
|
|
|
|
|
lockfile_postfork();
|
|
|
|
|
}
|
|
|
|
|
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
|
2014-07-07 17:11:39 -07:00
|
|
|
|
* startup sequence. Then stores -1 in '*fdp' and returns the child's
|
|
|
|
|
* pid in '*child_pid' argument.
|
2012-05-14 14:21:18 -07:00
|
|
|
|
*
|
2014-07-07 17:11:39 -07:00
|
|
|
|
* - In the child, stores a fd in '*fdp' and returns 0 through '*child_pid'
|
|
|
|
|
* argument. The caller should pass the fd to fork_notify_startup() after
|
|
|
|
|
* it finishes its startup sequence.
|
2012-05-14 14:21:18 -07:00
|
|
|
|
*
|
2014-07-07 17:11:39 -07:00
|
|
|
|
* Returns 0 on success. If something goes wrong and child process was not
|
|
|
|
|
* able to signal its readiness by calling fork_notify_startup(), then this
|
|
|
|
|
* function returns -1. However, even in case of failure it still sets child
|
|
|
|
|
* process id in '*child_pid'. */
|
|
|
|
|
static int
|
|
|
|
|
fork_and_wait_for_startup(int *fdp, pid_t *child_pid)
|
2010-01-15 15:29:52 -08:00
|
|
|
|
{
|
|
|
|
|
int fds[2];
|
|
|
|
|
pid_t pid;
|
2014-07-07 17:11:39 -07:00
|
|
|
|
int ret = 0;
|
2010-01-15 15:29:52 -08:00
|
|
|
|
|
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);
|
2014-07-07 17:11:39 -07:00
|
|
|
|
VLOG_ERR("fork child died before signaling startup (%s)",
|
|
|
|
|
status_msg);
|
|
|
|
|
ret = -1;
|
2011-11-23 12:15:42 -08:00
|
|
|
|
}
|
|
|
|
|
} else if (retval < 0) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("waitpid failed (%s)", ovs_strerror(errno));
|
2011-11-23 12:15:42 -08:00
|
|
|
|
} else {
|
2013-12-17 10:32:12 -08:00
|
|
|
|
OVS_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];
|
|
|
|
|
}
|
2014-07-07 17:11:39 -07:00
|
|
|
|
*child_pid = pid;
|
|
|
|
|
return ret;
|
2010-01-15 15:29:52 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_FATAL("pipe write failed (%s)", ovs_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[] = {
|
2013-10-11 16:52:50 -07:00
|
|
|
|
/* This list of signals is documented in daemon.man. If you
|
|
|
|
|
* change the list, update the documentation too. */
|
2010-01-15 12:13:46 -08:00
|
|
|
|
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;
|
2014-07-07 17:11:39 -07:00
|
|
|
|
bool child_ready = true;
|
2010-01-15 12:13:46 -08:00
|
|
|
|
|
2013-07-12 14:18:01 -07:00
|
|
|
|
set_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
|
|
|
|
|
2014-07-07 17:11:39 -07:00
|
|
|
|
if (child_ready) {
|
|
|
|
|
do {
|
|
|
|
|
retval = waitpid(daemon_pid, &status, 0);
|
|
|
|
|
} while (retval == -1 && errno == EINTR);
|
|
|
|
|
if (retval == -1) {
|
|
|
|
|
VLOG_FATAL("waitpid failed (%s)", ovs_strerror(errno));
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-01-15 12:13:46 -08:00
|
|
|
|
|
2014-07-07 17:11:39 -07:00
|
|
|
|
if (!child_ready || 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",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
ovs_strerror(errno));
|
2010-05-11 10:56:10 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
2014-03-21 09:20:42 -07:00
|
|
|
|
xsleep(wakeup - now);
|
2010-05-12 10:02:23 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
last_restart = time(NULL);
|
|
|
|
|
|
2010-01-19 15:00:56 -08:00
|
|
|
|
VLOG_ERR("%s, restarting", status_msg);
|
2014-07-07 17:11:39 -07:00
|
|
|
|
child_ready = !fork_and_wait_for_startup(&daemonize_fd,
|
|
|
|
|
&daemon_pid);
|
|
|
|
|
if (child_ready && !daemon_pid) {
|
|
|
|
|
/* Child process needs to break out of monitoring
|
|
|
|
|
* loop. */
|
2010-01-15 12:13:46 -08:00
|
|
|
|
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();
|
2013-07-12 14:18:01 -07:00
|
|
|
|
set_subprogram_name("");
|
2010-01-15 12:13:46 -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
|
|
|
|
{
|
2013-06-19 13:07:35 -07:00
|
|
|
|
assert_single_threaded();
|
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) {
|
2014-07-07 17:11:39 -07:00
|
|
|
|
pid_t pid;
|
|
|
|
|
|
|
|
|
|
if (fork_and_wait_for_startup(&daemonize_fd, &pid)) {
|
|
|
|
|
VLOG_FATAL("could not detach from foreground session");
|
|
|
|
|
}
|
|
|
|
|
if (pid > 0) {
|
2009-12-17 10:56:01 -08:00
|
|
|
|
/* Running in parent process. */
|
2009-07-08 13:19:16 -07:00
|
|
|
|
exit(0);
|
|
|
|
|
}
|
daemon: Start monitor process, not daemon process, in new session.
To keep control+C and other signals in the initiating session from killing
the monitor process, we need to put the monitor process into its own
session. However, until this point, we've only done that for the daemon
processes that the monitor started, which means that control+C would kill
the monitor but not the daemons that it launched.
I don't know of a benefit to putting the monitor and daemon processes in
different sessions, as opposed to one new session for both of them, so
this change does the latter.
daemonize_post_detach() is called from one additional context where we'd
want to be in a new session, the worker_start() function, but that function
is documented as to be called after daemonize_start(), in which case we
will (after this commit) already have called setsid(), so no additional
change is required there.
Bug #14280.
Reported-by: Gordon Good <ggood@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-12-13 14:01:23 -08:00
|
|
|
|
|
2010-01-15 12:13:46 -08:00
|
|
|
|
/* Running in daemon or monitor process. */
|
daemon: Start monitor process, not daemon process, in new session.
To keep control+C and other signals in the initiating session from killing
the monitor process, we need to put the monitor process into its own
session. However, until this point, we've only done that for the daemon
processes that the monitor started, which means that control+C would kill
the monitor but not the daemons that it launched.
I don't know of a benefit to putting the monitor and daemon processes in
different sessions, as opposed to one new session for both of them, so
this change does the latter.
daemonize_post_detach() is called from one additional context where we'd
want to be in a new session, the worker_start() function, but that function
is documented as to be called after daemonize_start(), in which case we
will (after this commit) already have called setsid(), so no additional
change is required there.
Bug #14280.
Reported-by: Gordon Good <ggood@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
2012-12-13 14:01:23 -08:00
|
|
|
|
setsid();
|
2010-01-15 12:13:46 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (monitor) {
|
|
|
|
|
int saved_daemonize_fd = daemonize_fd;
|
|
|
|
|
pid_t daemon_pid;
|
|
|
|
|
|
2014-07-07 17:11:39 -07:00
|
|
|
|
if (fork_and_wait_for_startup(&daemonize_fd, &daemon_pid)) {
|
|
|
|
|
VLOG_FATAL("could not initiate process monitoring");
|
|
|
|
|
}
|
2010-01-15 12:13:46 -08:00
|
|
|
|
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
|
|
|
|
|
2013-04-25 15:03:27 -07:00
|
|
|
|
forbid_forking("running in daemon process");
|
|
|
|
|
|
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)
|
|
|
|
|
{
|
2013-04-28 19:25:55 -07:00
|
|
|
|
if (pidfile) {
|
|
|
|
|
free(pidfile);
|
|
|
|
|
pidfile = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
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(). */
|
2014-01-10 08:33:15 -08:00
|
|
|
|
static void
|
2012-05-21 11:08:59 -07:00
|
|
|
|
daemonize_post_detach(void)
|
|
|
|
|
{
|
2010-01-15 15:29:52 -08:00
|
|
|
|
if (detach) {
|
2009-12-17 10:56:01 -08:00
|
|
|
|
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;
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_WARN("%s: open: %s", pidfile, ovs_strerror(error));
|
2009-07-08 13:19:16 -07:00
|
|
|
|
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) {
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_WARN("%s: fcntl: %s", pidfile, ovs_strerror(error));
|
2009-07-08 13:19:16 -07:00
|
|
|
|
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)",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
pidfile, ovs_strerror(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
|
|
|
|
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;
|
2013-06-24 10:54:49 -07:00
|
|
|
|
VLOG_WARN("%s: read: %s", pidfile, ovs_strerror(error));
|
2009-07-08 13:19:16 -07:00
|
|
|
|
} 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",
|
2013-06-24 10:54:49 -07:00
|
|
|
|
pidfile, ovs_strerror(-pid));
|
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
|
|
|
|
}
|
2011-03-29 09:44:55 -07:00
|
|
|
|
}
|
2014-01-16 16:16:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* stub functions for non-windows platform. */
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
service_start(int *argc OVS_UNUSED, char **argv[] OVS_UNUSED)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
service_stop(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
should_service_stop(void)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|