From: CVBruce <cv...@gm...> - 2017-05-30 19:05:08
|
I wish I could remember who suggested that KeepAlive be set to false. His premiss was that rxapi rarely fails, and I have to agree with him. If I open up the code again, I want to know ahead of time, how it should be done. Last time I used a lot of #ifdef to work around the code that was proving bothersome. I was told that wasn’t the way to do it. So what is the directional way to modify the code. Should I be creating a whole new rxapi for those systems that use launchd to start processes? Bruce > On May 30, 2017, at 1:41 AM, Rony G. Flatscher <Ron...@wu...> wrote: > > Indeed, the plist file originates from Bruce (thanks a lot again for it)! > > Bruce, if you happen to find your changes to rxapi to behave according to the MacOSX specifications, probably everyone in the community would appreciate it if you could make them available! It is quite disturbing that on MacOSX the launcher tries to restart the running rxapi daemon every ten seconds in vain (for stability reasons "keepalive" needs to be set IMHO). > ---rony > > > On 23.05.2017 16:14, CVBruce wrote: >> I think I originally wrote this plist file. In the old make process the ‘make install’ would tailor the file for the current install location (i think). >> >> There was some discussion around this file and the rxapi process on MacOS. The problem stems from the MacOS architecture for daemons doesn’t like daemons that fork and exec when starting. The launch daemon looses connection to them. With the KeepAlive attribute the launch daemon thinks that the process rxapi has stopped/failed, so every few seconds it tries to restart the rxapi process. You can see this in the system log. I had re-written the rxapi code with MacOS conditionals, and these changes were rejected, because the whole process was scheduled to be re-written. >> >> As a work around, one user suggested that since the rxapi process rarely ever fails, that the KeepAlive attribute is unnecessary, and can be set to false. >> >> Bruce >>> On May 23, 2017, at 5:37 AM, Rony G. Flatscher <Ron...@wu... <mailto:Ron...@wu...>> wrote: >>> >>> Enclosed you will find a MacOSX plist-file named "org.rexxla.oorexx.rxapid.plist" which I use for the BSF4ooRexx MacOSX installation. >>> >>> It turns out (by mistake) that ooRexx will run quite slowly, if rxapi is not running as a daemon, hence mentioning this here and enclosing a working plist file which has the following content: >>> F:\debug_oorexx\from_macosx>type org.rexxla.oorexx.rxapid.plist >>> <?xml version="1.0" encoding="UTF-8"?> >>> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" <http://www.apple.com/DTDs/PropertyList-1.0.dtd>> >>> <plist version="1.0"> >>> <dict> >>> <key>Disabled</key> >>> <false/> >>> <key>KeepAlive</key> >>> <true/> >>> <key>Label</key> >>> <string>org.rexxla.oorexx.rxapid</string> >>> <key>ProgramArguments</key> >>> <array> >>> <string>/usr/local/bin/rxapi</string> >>> </array> >>> <key>RunAtLoad</key> >>> <true/> >>> </dict> >>> </plist> >>> As you can see, the plist' path to rxapi has been adjusted to "/usr/local/bin/rxapi". >>> >>> To use it one needs to copy "org.rexxla.oorexx.rxapid.plist" to "/Library/LaunchDaemons". From my older notes I noticed that that plist-file should be owned by root and be in the administrator group ("wheel"). >>> >>> To start the rxapi daemon on MacOSX you then would use launchctl like this: >>> launchctl load -w /Library/LaunchDaemons/org.rexxla.oorexx.rxapid.plist >>> To unload the rxapi dameon on MacOSX you then would use launchtl like this: >>> launchctl unload -w /Library/LaunchDaemons/org.rexxla.oorexx.rxapid.plist >>> Maybe this proofs to be a little bit helpful while working on the CMake definitions for MacOSX. >>> >>> ---rony > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |