Instead of using os.fork (not supported on Windows),
subprocess.Popen is used and os.pipe was replaced
with Windows pipes.
To be able to identify the child process, an extra
parameter was added to daemon process '--pipe-handle'.
This parameter contains the parent Windows pipe handle
which is used by the child to notify the parent about
the startup.
The PID file is created directly on Windows, without
using a temporary file because the symbolic link does
not inherit the file lok set on the temporary file.
Signed-off-by: Paul-Daniel Boca <pboca@cloudbasesolutions.com>
Signed-off-by: Alin Balutoiu <abalutoiu@cloudbasesolutions.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions>
Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions>
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
This patch fixes just the Python 3 problems found by running:
python3 setup.py install
There are still many other issues to be fixed, but this is a start.
Signed-off-by: Terry Wilson <twilson@redhat.com>
[russell@ovn.org resolved conflicts with current master]
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
This patch resolves the following warnings from flake8:
E111 indentation is not a multiple of four
E112 expected an indented block
E113 unexpected indentation
It's critical to have correct indentation in Python code, so it seemed
worth enabling these warnings.
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Fix the following pep8 errors:
E201 whitespace after '('
E203 whitespace before ','
E222 multiple spaces after operator
E225 missing whitespace around operator
E226 missing whitespace around arithmetic operator
E231 missing whitespace after ':'
E241 multiple spaces after ':'
E251 unexpected spaces around keyword / parameter equals
E261 at least two spaces before inline comment
E262 inline comment should start with '# '
E265 block comment should start with '# '
E271 multiple spaces after keyword
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Some functions are unused and some functions can be
declared as static.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
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>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
On one machine, "/etc/init.d/openvswitch-switch start" failed to start
with:
ovs-vswitchd: fork child failed to signal startup (Success)
Starting ovs-vswitchd ... failed!
"strace" revealed that the fork child was actually segfaulting, but the
message output didn't indicate that in any way. This commit fixes the
log message (but not the segfault itself).
Reported-by: Michael Hu <mhu@nicira.com>
Bug #8457.
Commit 591c20651f "daemon.py: Don't shadow built-in 'file' variable"
changed most instances of "file" to "file_handle" but missed this one.
I'm not certain that this solves a real problem, but it still seems wrong.
Bug #7533.
The --pidfile option is supposed to work like this:
* Without --pidfile, you don't get a pidfile.
* With --pidfile, you get the default pidfile.
* With --pidfile=FILE, you get FILE as your pidfile.
However, it actually worked like this:
* Without --pidfile, you got the default pidfile.
* With --pidfile, you got no pidfile at all.
* With --pidfile=FILE, you got FILE as your pidfile.
This is because of the semantics of "default" in argparse. It is
documented as:
The default keyword argument of add_argument(), whose value defaults to
None, specifies what value should be used if the command-line argument
is not present. For optional arguments, the default value is used when
the option string was not present at the command line.
We actually want "const", which is documented under the description of
nargs="?" as:
If no command-line argument is present, the value from default will be
produced. Note that for optional arguments, there is an additional
case - the option string is present but not followed by a command-line
argument. In this case the value from const will be produced.
Bug #7533.
Pychecker complains about __read_pidfile() having too may returns.
I personally think the function is fine, but it's easy enough to
reduce them.
python/ovs/daemon.py:395: Function (__read_pidfile) has too many
returns (12)
This leaves one use of __dict__ used for iterating through attributes.
I could use dir() instead, but I was put off by this note in its
documentation in the Python Library Reference:
Because dir() is supplied primarily as a convenience for use at an
interactive prompt, it tries to supply an interesting set of names more
than it tries to supply a rigorously or consistently defined set of names,
and its detailed behavior may change across releases. For example,
metaclass attributes are not in the result list when the argument is a
class.
Suggested-by: Reid Price <reid@nicira.com>
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.
Until now, it has been the responsibility of an individual daemon to call
die_if_already_running() at an appropriate time. A long time ago, this
had to happen *before* daemonizing, because once the process daemonized
itself there was no way to report failure to the process that originally
started the daemon. With the introduction of daemonize_start(), this is
now possible, but we haven't been taking advantage of it.
Therefore, this commit integrates the die_if_already_running() call into
daemonize_start() and deletes the calls to it from individual daemons.
The init script starts monitor-external-ids with --monitor when
configured to do so. Also made changes to guarantee that --monitor
actually restarts ovs-external-ids.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Opening a file descriptor and then closing it always discards any locks
held on the underlying file, even if the file is still open as another file
descriptor. This meant that calling read_pidfile() on the process's own
pidfile would discard the lock and make other OVS processes think that the
process had died. This commit fixes the problem.
These initial bindings pass a few hundred of the corresponding tests
for C implementations of various bits of the Open vSwitch library API.
The poorest part of them is actually the Python IDL interface in
ovs.db.idl, which has not received enough attention yet. It appears
to work, but it doesn't yet support writes (transactions) and it is
difficult to use. I hope to improve it as it becomes clear what
semantics Python applications actually want from an IDL.
