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.
Advertising
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
