Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

On 21 Nov 2018, at 17:21, CV Bruce wrote:Enrico, I’m a little concerned that installing anything in ~/… will make it user specific, and not system wide.  Since only one copy of rxapi can run at a time, then only one user can use ooRexx.  In your explorations can you test for

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

could we, for the moment, just have an environment variable that overrides the default? Meaning that when it is not there, we write the PID to standard; when it is there, we write the PID where it indicates we want it to be. That should satisfy worries over changing this? René. > On 21 Nov

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

my understanding was that all instances connect to a running daemon and have separated user spaces in it. Running separate processes would be possible only when making the interpreter instances connect to different ports. When testing the s390x port at a an IBM (Marist) Linux VM that I could

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

I may not have been entirely accurate. I believe that two rxapi process can run at the same time as long as they have different PID files. The problem is that only one of them can bind the socket. Do we know if rxapi issues an error message if it can not bind the socket? If so where does it

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

I agree with this. What I’ve seen before is at install time the user is asked whether they want to install for just the user or for all users. Selecting all users then requests authentication for the install. Bruce > On Nov 21, 2018, at 8:39 AM, René Jansen wrote: > > User specific is

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

Greetings Rick, Rick McGuire wrote: It's not really that simple. I believe writing the pid file at that location is part of the requirements for running as a daemon on other unix-based systems. I wish David Ashley were still around, he did all of that work and would know the issues. Ah yes,

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

User specific is fine and is what will suffice for most users. It will be the default for a portable install. Multiuser installs should be an option and there is no issue in requiring admin for those, I’d rather they do. René. > On 21 Nov 2018, at 12:21, CV Bruce wrote: > > Enrico, > >

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

> On 21 Nov 2018, at 17:11, Rick McGuire wrote: > > It might not be true for the Mac, but I believe it is true for Linux, which > means just changing that line is not the correct behavior. As I said It was just a VERY quick and dirty test… The ooRexx.pid name/location could be a build

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

Enrico, I’m a little concerned that installing anything in ~/… will make it user specific, and not system wide. Since only one copy of rxapi can run at a time, then only one user can use ooRexx. In your explorations can you test for this? "The main difference [on Mac OS] is that an agent

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

It might not be true for the Mac, but I believe it is true for Linux, which means just changing that line is not the correct behavior. I just discovered that the source tree has a Mac version of APIServer.cpp that uses a tmp file, but the build is unconditionally using the Linux version. Not sure

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

> On 21 Nov 2018, at 15:23, Rick McGuire wrote: > > I believe writing the pid file at that location is part of the requirements > for running as a daemon on other unix-based systems. Does not seem true for Mac OS I have been running and ooRexx-ing for a while with /tmp/ooRexx.pid and

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

Noted, if we got it in all package managers we would be set. I thought that Suse is waiting for the green light (GA release). We did not have stellar results from previous attempts to get a certificate, but I agree we need it and will reatart the effort. best regards, René. > On 21 Nov 2018,

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

I’m more of a MacPorts kind of guy, and I’ve used fink in the past. It would be nice if we could support more of the Mac OS specific package managers. > On Nov 21, 2018, at 7:07 AM, René Jansen wrote: > > I agree. > > Want to add to the discussion: homebrew (brew) has a ‘brew services’

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

I agree. Want to add to the discussion: homebrew (brew) has a ‘brew services’ command that can install a service on macOS without requiring sudo. A portable ‘installer’ (drag an application icon from a .dmg to ~/Applications) would be a good thing. A ‘brew install oorexx’ would be a good thing

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

Well…. I agree with Enrico, mostly. Installation: Yes you need sudo privileges to write to /Library/LaunchDaemons. You also need sudo to write to /usr/local/… which is as far as I know, the current place to put system wide user programs. I could be wrong as I haven’t been keeping up.

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

It's not really that simple. I believe writing the pid file at that location is part of the requirements for running as a daemon on other unix-based systems. I wish David Ashley were still around, he did all of that work and would know the issues. Rick On Wed, Nov 21, 2018 at 9:14 AM Enrico

Re: [Oorexx-devel] Ad MacOSX and daemons (for rxapi)

The only reason for having sudo privileges is to install the plist into /Library/LaunchDaemons The only reason for having sudo privileges when starting by hand the rxapi thing is to write /var/run/ooRexx.pid I just run a VERY quick and dirty test changing

[Oorexx-devel] Ad MacOSX and daemons (for rxapi)

Rather discussing general programming questions in bugs where the discussion results evaporate once the item gets closed, I think it makes more sense to discuss them here in the developer list. In the past weeks/months P.O. has started and has been doing an immensive amount of work in learning