[ovs-dev] [RFC/PATCH v2] Make the PID part of socket path configurable

Christian Svensson christian at cmd.nu
Tue Aug 9 07:10:25 UTC 2016


On Mon, Aug 8, 2016 at 11:59 PM, Ben Pfaff <blp at ovn.org> wrote:
>
> Including the PID allows multiple daemons of a single type to run.

While technically true, in practice I would argue this doesn't hold and is
indeed one of the reason I made this change.

The documented way to connect to a daemon is "ovs-appctl -t my-daemon".
That reads the PID file "my-daemin.pid" and uses "my-daemon.$PID.ctl".
That requires my PID file given to the daemon to match the internal
"program_name" for the socket resolution code to work.
I.e., I cannot do --pidfile=my-daemon2.pid and then ovs-appctl -t
my-daemon2 will work.

In order to call the second one you would have to do:
ovs-appctl -t $PWD/my-daemon.$(<my-daemon2.pid).ctl
I do hope we can agree on that requiring the caller to know both the PID
name and the internal program name is far from perfect.

With this change daemons that do support setting unixctl would be really
able to run multiple instances.
my-daemon --unixctl=$RUNDIR/my-daemon.ctl
my-daemon --unixctl=$RUNDIR/my-daemon2.ctl

ovs-appctl -t my-daemon
ovs-appctl -t my-daemon2

would both work.

I also don't think you're solving a real problem, because reading a
> pidfile isn't difficult.
>
I don't understand why you want to change this so badly.  It's not hard
> to read a pidfile.


Just because it isn't difficult doesn't mean it's the right way to do
things.

I definitely don't want to fork OVS behavior here based on a
> configuration flag, as I already explained.
>
But you already do!
The configuration flag today is called WIN32. With this patch it's called
WITH_PID_SOCKET_PATH and defaults to YES/NO depending on the platform.
The code that is behind #ifdef $OS is much smaller, and the one behind
#ifdef $FEATURE is larger. That should make more code testable in both
platforms, making the total code aliveness higher.



More information about the dev mailing list