This moves the burden of maintaining the socket file to the manager of the ptp4l process. However, maintaining a single instance of ptp4l is already the responsibility of the process manager. It's more straightforward for process managers to manage processes than to clean up files after a process exits.
I think a better approach would be to acquire a lockfile/pidfile on startup. If the lock fails, then exit immediately with a failure. Normal process managers would stay unchanged, and administrators won't be able to accidentally start a second copy of ptp4l by hand. People who intend to run more than one instance of ptp4l would either need to disable the lockfile or choose a different name for the file. Alternatively, we could make the lockfile disabled by default, enabled by configuration. On Thu, Aug 10, 2017 at 4:38 AM, Miroslav Lichvar <mlich...@redhat.com> wrote: > When a second instance of ptp4l using the same configuration was > (accidentally) started, it removed the Unix domain socket of the first > instance and prevented communication with it. > > Remove the unlink() call to let bind() of the second instance fail and > run with the UDS port in faulty state. > > If the socket is not removed on ptp4l exit (e.g. due to crash), the user > will have to remove it manually in order to get a working UDS port > again. > --- > uds.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/uds.c b/uds.c > index d5e8f50..a12d641 100644 > --- a/uds.c > +++ b/uds.c > @@ -69,8 +69,6 @@ static int uds_open(struct transport *t, const char *name, > struct fdarray *fda, > sa.sun_family = AF_LOCAL; > strncpy(sa.sun_path, name, sizeof(sa.sun_path) - 1); > > - unlink(name); > - > err = bind(fd, (struct sockaddr *) &sa, sizeof(sa)); > if (err < 0) { > pr_err("uds: bind failed: %m"); > -- > 2.9.3 > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel