I found a fairly simple example of using a lock file that was simpler than using a pid file, so went with that.
Rick On Sat, Dec 1, 2018 at 10:48 AM Erich Steinböck <erich.steinbo...@gmail.com> wrote: > This question seems to exactly cover our situation: > > https://stackoverflow.com/questions/30742508/linux-local-communication-sockets-why-is-bind-not-failing-as-expected > > The solution seems to better than what I proposed > > On Sat, Dec 1, 2018 at 4:13 PM Erich Steinböck <erich.steinbo...@gmail.com> > wrote: > >> try this again after commenting out the call to the method that performs >>> the unlink(). >>> >> If I comment out the call to checkServiceName, the bind fails (and with >> it rxapi) even the "first" time, unless I manually remove the >> $XDG_RUNTIME_DIR/.ooRexx-5.0.0-64.service special file >> >> kill the first instance and try launching rxapi again to see if >>> successfully binds. >>> >> If rxapi is started successfully, and I kill it, the special file still >> exists, and as such starting any further instances of rxapi fail, until I >> manually remove the special file again. >> >> We probably need rxapi to open a second, standard file (in the same >> XDG_RUNTIME_DIR location) that it opens, and any further rxapi instances >> would only proceed if they could successfully unlink this file, which would >> be the case if the initial rxapi instance has ended or was killed. (Well, >> yes, that's probably exactly what you describe as "still a need for a .pid >> file") >> >> On Sat, Dec 1, 2018 at 3:21 PM Rick McGuire <object.r...@gmail.com> >> wrote: >> >>> Erich, >>> >>> One more experiment. Since there is some automatic cleanup involved with >>> that file because of its location, could you try this again after >>> commenting out the call to the method that performs the unlink(). From what >>> I've read, the second bind should fail, which will cause the second >>> instance to close. >>> >>> However, there's another scenario I'm worried about. If the first >>> experiment works, kill the first instance and try launching rxapi again to >>> see if successfully binds. >>> >>> Rick >>> >>> On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck < >>> erich.steinbo...@gmail.com> wrote: >>> >>>> One thing that needs to be checked out is what happens if a second >>>>> version of rxapi gets launched. >>>>> .. there's also some code to unlink() the file before the bind >>>>> operation that I'm hoping will fail if the socket is still in use. >>>> >>>> >>>> On Linux, rxapi can be started a second time, with both of them >>>> continuing to listenForConnections() >>>> The reason is, as you suspected, with unlink, which returns 0 although >>>> the first rxapi still has this socket open. The docs seem to confirm >>>> this. https://linux.die.net/man/2/unlink "If the name referred to a >>>> socket, fifo or device the name for it is removed but processes which have >>>> the object open may continue to use it." >>>> >>> _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
