On Mon, Aug 8, 2016 at 11:59 PM, Ben Pfaff <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev