That could work, but I don’t know that a second file would be needed, couldn’t the PID file contain both PID and port? I’m also assuming that you would determine PID by matching effective user ID’s of both ooRexx client and rxapi. Also going forward this would be a solution for V5, I don’t see this being applied to V4.2.
For that matter, the PID file could contain, PID, port, bit-ness, version. Those are all the things that I know of that could cause a ooRexx client program to not work with rxapi. Bruce > On Jul 6, 2016, at 3:18 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > > > On 05.07.2016 22:43, CVBruce wrote: >> Although this gets around the pid file problem, it doesn’t get around the >> port problem, you can still only run one rxapi process per computer. For >> example you can’t run both 32bit and 64bit rxapi concurrently on the same >> box, even if your have different pid files. You can’t run ooRexx V4.2 and >> V5.0 concurrently on the same computer. >> >> Moving the PID file will only allow one user to run ooRexx in a shared >> environment. > > Is it the case that only the registered port number 10010 gets used? What > happens, if it cannot be used, because another process uses it already at the > time rxapi starts up? > > --- > > I always have thought that there is a fallback solution in asking the > operating system to supply a free port (if the ooRexx assigned port was in > use and hence opening it would fail) by requesting the port number 0 (then > the system assigns a free port instead, which can be retrieved from the > returned socket) and then "somehow" communicating it to the clients. > > Knowing the PID of the rxapi process would allow identify the port that > process has opened and its state. On the commandline you could do something > like: > get the PID number from the PID file (e.g. "cat ooRexx.pid") > get the tcp port opened from the process with the found PID number (e.g. > "netstat -ano | grep PID-number" or something like that) and analyze the > result for the port > So in the case that we have a rxapi daemon running (probably using the > official ooRexx port) it should still be possible to run local instances of > rxapi if they use different ports, once a fallback solution was agreed upon. > How about creating an "ooRexx.port" text file in the same place where the > "ooRexx.pid" file gets created and stored? > ---rony > > >> >>> On Jul 5, 2016, at 10:39 AM, Michael Lueck <mlu...@lueckdatasystems.com> >>> <mailto:mlu...@lueckdatasystems.com> wrote: >>> >>> Greetings Chip, >>> >>> Chip Davis wrote: >>>> Would you care to describe your magic incantation? >>> >>> >>> Most of the documentation is in that RFE... >>> >>> >>> "#542 Support non-root interpreter installation and execution on Unix-like >>> systems" >>> https://sourceforge.net/p/oorexx/feature-requests/542/ >>> >>> >>> Specifically changing on of the ooRexx source files: >>> >>> rexxapi\server\platform\unix\APIService.cpp >>> >>> // For testing purposes comment out the following line to force RXAPI to >>> // run as a foreground process. >>> #undef RUN_AS_DAEMON >>> >>> #ifdef RUN_AS_DAEMON >>> #define OOREXX_PIDFILE " >>> <https://sourceforge.net/p/oorexx/feature-requests/542/SpecificallychangingonoftheooRexxsourcefiles:rexxapi/server/platform/unix/APIService.cpp//FortestingpurposescommentoutthefollowinglinetoforceRXAPIto//runasaforegroundprocess.#undefRUN_AS_DAEMON#ifdefRUN_AS_DAEMON#defineOOREXX_PIDFILE>/var/run/ooRexx.pid" >>> bool run_as_daemon = true; >>> #else >>> #define OOREXX_PIDFILE >>> "/kunden/homepages/35/d157794216/htdocs/opt/oorexx/var/run/ooRexx.pid" >>> bool run_as_daemon = true; >>> #endif >>> >>> >>> Then building and installing from the patched source. >>> >>> My organization standard was to in my home directory build an opt/ >>> directory, then package names as the next level... and to consider that >>> directory as the virtual root. Thus .../var/run/ right where >>> ooRexx wanted to place its PID file in the first place. >>> >>> I am thankful, >>> >>> -- >>> Michael Lueck >>> Lueck Data Systems >>> http://www.lueckdatasystems.com/ <http://www.lueckdatasystems.com/> > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape_______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
