Re: [Oorexx-devel] Time for the *ix users to pitch in.

On Thu, Dec 27, 2018 at 2:22 PM Erich Steinböck wrote: > go ahead and make the changes and commit > > Committed revision 11649 (for Unix-like systems only) > This now uses the username in the service/lock file path. > Uses XDG_RUNTIME_DIR or /tmp, but never ~ > rxapi now prints to the stdout > >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> > go ahead and make the changes and commit Committed revision 11649 (for Unix-like systems only) This now uses the username in the service/lock file path. Uses XDG_RUNTIME_DIR or /tmp, but never ~ rxapi now prints to the stdout There's one thing about rxapi: I don't see what we try to achieve

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Since it runs in a different process in normal operation, we could probably just unconditionally put out some messages indicating the source of the problem. Then if someone appears to be having issues, we can just ask them to start it from the command line and report the errors. But yes, go ahead

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> > Have you done anything else with these changes? > Not yet. I can do the change to use getpwuid() and commit, if you agree. What do you think regarding finding out whether rxapi runs or why it couldn't start? Maybe add an option to the rxapi command? This would help (us) with support

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Have you done anything else with these changes? Rick On Mon, Dec 24, 2018 at 6:40 PM Erich Steinböck wrote: > With a few typos fixed, this seems to work as expected, also in the > discussed sudo scenario. > > also includes the login name in the file names >> > getuid() returns the id, not the

Re: [Oorexx-devel] Time for the *ix users to pitch in.

This is what is a bit weird: I deleted the old ooRexx installation (from /opt or /uer/local) on the 4th of december, at 22:00 sometime (I checked the garbage bin), hence there was no ooRexx installation available on the user „po“ on that machine at the 8.12. entering „rexx“ on the command line

Re: [Oorexx-devel] Time for the *ix users to pitch in.

You probably ran ooRexx back on December 8th, which is when they were created. You can delete them, but the files will get recreated the next time you run ooRexx. Rick On Tue, Dec 25, 2018 at 6:25 AM P.O. Jonsson wrote: > I have no recollection of having made a build on that userID for quite >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

I have no recollection of having made a build on that userID for quite some time, hence the question,, it is Erich that uses the „Jenkins“ account on the same machine to make the automated builds, hence the question. Here are the further details of these files -rw-rw-rw- 1 postaff 0

Re: [Oorexx-devel] Time for the *ix users to pitch in.

If the build was running under your userid, that file got created when rxapi was launched during the build process. That's the file that is used to ensure that only one copy of rxapi runs per user. Rick On Tue, Dec 25, 2018 at 5:09 AM P.O. Jonsson wrote: > Dear Erich, > > I was going into my

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Dear Erich, I was going into my user account on the Mac Mini Jenkins slave today and noticed a hidden file ".ooRexx-5.0.0-64.lock“ in my home directory (Users/po) Is this something that is coming out of the Jenkins build? How can the lock file be in my account? I have no ooRexx installation in

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Using getpwuid() would be better. Based on the code that was there before, I was assuming getuid() actually returned the username...guess I should have looked it up first. Rick On Mon, Dec 24, 2018 at 6:40 PM Erich Steinböck wrote: > With a few typos fixed, this seems to work as expected, also

Re: [Oorexx-devel] Time for the *ix users to pitch in.

With a few typos fixed, this seems to work as expected, also in the discussed sudo scenario. also includes the login name in the file names > getuid() returns the id, not the name, so I had changed the %s to %d in the snprintf's I assume getting the name will require getpwuid() - if we want the

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Ok, from what Bob Martin posted, it sounds like the www-data login does not have XDG variables set and also does not have write access to the home directory. As others have said, using the home directory is probably a bad idea because it could be network-mounted and using it would lock out users

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Greetings ooRexx'ers, Moritz Hoffmann wrote: I would not advocate storing the socket in the home directory. At work, my home directory is on NFS and that would break ooRexx on all but one machine. From my experience this is a common setup. I agree with Moritz's statement that it seems common

Re: [Oorexx-devel] Time for the *ix users to pitch in.

That's interesting! I'm able to reproduce the described behavior on Debian stretch. The su command is only supposed to be used for changing the user ID but will preserve the environment as is. The sudo command will update the environment and clears the XDG_* variables because it's not a login

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Any linux/BSD/Apple user knows that sudo and su are prone to create unpredictable results I would not waste time researching a solution for a murky situation I would mark it as a permanent restriction / producing unpredictable results I just created a test user and found that The $HOME var

Re: [Oorexx-devel] Time for the *ix users to pitch in.

I am not sure what will happen for MAC (being *NIX) users;l with the current default placement of ooRexx into ~Applications/ooRexx5.0.0 (in my case /Users/po/Applications/ooRexx5.0.0) the ooRexx installation is per user and not, as in version 4 or as in the BSF4ooRexx generic and available for

Re: [Oorexx-devel] Time for the *ix users to pitch in.

No, not yet. Should we wait for Moritz' feedback, as he was the the one who suggested using XDG_RUNTIME_DIR? On Sat, Dec 22, 2018 at 2:56 PM Rick McGuire wrote: > Sounds like a reasonable solution...have you tried it yet? > > Rick > > On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck < >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Sounds like a reasonable solution...have you tried it yet? Rick On Sat, Dec 22, 2018 at 8:53 AM Erich Steinböck wrote: > With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running > into an issue if a Unix user switches users with the "su other-user" > command. > The existing

Re: [Oorexx-devel] Time for the *ix users to pitch in.

With the new rxapi using $XDG_RUNTIME_DIR for its socket, we are running into an issue if a Unix user switches users with the "su other-user" command. The existing environment is mainly kept intact, and $XDG_RUNTIME_DIR now points to a location that other-user has no access to. At this point any

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Fresh build, trying to compile until: [ 76%] Building CXX object CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o /home/rony/dev/oorexx-code-0/sandbox/rick/rxapi/rexxapi/server/platform/unix/linux/APIService.cpp: In function ´int acquireLock(const char*)`:

Re: [Oorexx-devel] Time for the *ix users to pitch in.

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 wrote: > This question seems to exactly cover our situation: > >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

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 wrote: > try this again after

Re: [Oorexx-devel] Time for the *ix users to pitch in.

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

Re: [Oorexx-devel] Time for the *ix users to pitch in.

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

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Rats. Looks like there is still a need for a .pid file. Fortunately, we can store it in the same location, so there are still no privileges required. The code can pretty much be copied from the old version. Rick On Sat, Dec 1, 2018 at 8:54 AM Erich Steinböck wrote: > One thing that needs to be

Re: [Oorexx-devel] Time for the *ix users to pitch in.

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

Re: [Oorexx-devel] Time for the *ix users to pitch in.

And here is the backtrace for the same situations My script [enrico@enrico-imac zz]$lldb -- rexx unxmit file206.xmi (lldb) target create "rexx" Current executable set to 'rexx' (x86_64). (lldb) settings set -- target.run-args "unxmit" "file206.xmi" (lldb) r Process 4908 launched:

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Me, no...but perhaps someone else does. Rick On Wed, Nov 28, 2018 at 5:23 PM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > First attempt with a script I wrote > > > [enrico@enrico-imac zz]$lldb -- rexx unxmit FILE206.xmi > (lldb) target create "rexx" >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

First attempt with a script I wrote [enrico@enrico-imac zz]$lldb -- rexx unxmit FILE206.xmi (lldb) target create "rexx" Current executable set to 'rexx' (x86_64). (lldb) settings set -- target.run-args "unxmit" "FILE206.xmi" (lldb) run Process 4488 launched: '/Users/enrico/rxapi/bin/rexx'

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Dear Enrico, You could try to make a debug build and then use Valgrind I think you can get it via Homebrew. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 28.11.2018 um 22:10 schrieb Rick McGuire : > > Well, I'm not familiar with the debuggers on a

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Well, I'm not familiar with the debuggers on a Mac, but use one to find out the location of the exception and get a stack trace would be a good starting point. Rick On Wed, Nov 28, 2018 at 4:06 PM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > Apple High

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Apple High Sierra The build was successful Started the test suite , but [enrico@enrico-imac ooRexx.tests.svn]$rexx testOORexx.rex -s -X native_api Searching for test containers... Executing automated test suite Executing tests from .../enrico/ooRexx.tests.svn/ooRexx/SimpleTests.testGroup

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Wow, really? I have to admit that was somewhat unexpected! One thing that needs to be checked out is what happens if a second version of rxapi gets launched. You can test this by just issuing the rxapi command and checking the return code. I was a little uncertain on what the expected result would

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> > I checked it on my machine and it does indeed point to a user-specific > directory where the user id is one segment of the path. Same here on Ubuntu. $XDG_RUNTIME_DIR resolves to /run/user/1000 which is a directory with the required 0700 access permission.

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> > The link error and Rony's compile errors should be resolved now. > With the latest commit, this builds without error and successfully runs all tests on Ubuntu 16.04 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net

Re: [Oorexx-devel] Time for the *ix users to pitch in.

I checked it on my machine and it does indeed point to a user-specific directory where the user id is one segment of the path. Moritz On Wed, Nov 28, 2018 at 9:31 PM Rick McGuire wrote: > > I'm hoping all of those MUST items are the responsibility of the OS and not > the application using that

Re: [Oorexx-devel] Time for the *ix users to pitch in.

I'm hoping all of those MUST items are the responsibility of the OS and not the application using that directory. Am I correct in understanding that $XDG_RUNTIME_DIR is the user-specific directory, so all I need to do is place the socket file there? Rick On Wed, Nov 28, 2018 at 1:20 PM Moritz

Re: [Oorexx-devel] Time for the *ix users to pitch in.

The link error and Rony's compile errors should be resolved now. Rick On Wed, Nov 28, 2018 at 12:36 PM Erich Steinböck wrote: > Should compile without error with latest commit. > There's still a link error that needs to be resolved. I checked the > rexxapi libray definition in CMakeLists.txt,

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Further down it specifies that "it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between." I would argue that as long as the daemon is running in the background the user is not fully logged out. At least this is how

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Forgot to mention: I always wipe out the working directory such that no old artefacts remain and such that the CMake files get created from scratch. ---rony On 28.11.2018 18:48, Rony G. Flatscher wrote: > > rev 11537, Ubuntu: > > [ 0%] Generating rxsubcom.1.gz > [ 0%] Built target

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Same on apple High Sierra > On 28 Nov 2018, at 18:35, Erich Steinböck wrote: > > Should compile without error with latest commit. > There's still a link error that needs to be resolved. I checked the rexxapi > libray definition in CMakeLists.txt, but couldn't figure out what's wrong. > ~~~

Re: [Oorexx-devel] Time for the *ix users to pitch in.

rev 11537, Ubuntu: [ 0%] Generating rxsubcom.1.gz [ 0%] Built target rxsubcom_man [ 7%] Built target rexxapi [ 71%] Built target rexx [ 72%] Building CXX object CMakeFiles/rxapi.dir/rexxapi/server/platform/unix/linux/APIService.cpp.o

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Should compile without error with latest commit. There's still a link error that needs to be resolved. I checked the rexxapi libray definition in CMakeLists.txt, but couldn't figure out what's wrong. ~~~ bin/librexxapi.so.5.0.0: undefined reference to

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Great! Looking at the changes I noticed the socket is created in $HOME. I think we should use HOME only as a fall-back if the proper location is not available. The proper location is specified by the XDG spec [1] to be $XDG_RUNTIME_DIR. That way the socket cannot leak to other users because

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Hi Enrico, thanks, I did not know that. Before I attempt it, I will setup a job on our build Jenkins that builds the sandbox. best regards, René. > On 28 Nov 2018, at 11:47, Enrico Sorichetti via Oorexx-devel > wrote: > > > >> On 28 Nov 2018, at 16:32, Rick McGuire >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

On Wed, Nov 28, 2018 at 10:48 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 28 Nov 2018, at 16:32, Rick McGuire wrote: > > Also not going to happen. I'm not a Linux user, I don't like the tooling > on the system (editors, debuggers, etc.) If this is

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> On 28 Nov 2018, at 16:32, Rick McGuire wrote: > > Also not going to happen. I'm not a Linux user, I don't like the tooling on > the system (editors, debuggers, etc.) If this is going to be done, it will be > because the community of people who do run on those systems help to make it >

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Revision 11535l, Ubuntu: [ 0%] Generating rxsubcom.1.gz [ 0%] Built target rxsubcom_man [ 0%] Building CXX object CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Also not going to happen. I'm not a Linux user, I don't like the tooling on the system (editors, debuggers, etc.) If this is going to be done, it will be because the community of people who do run on those systems help to make it happen, not because I am expected to do all of the work. Rick On

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Another alternative would be a Docker image on your local windows box; I can set up a development image for your sandbox in half an hour or so. René. > On 28 Nov 2018, at 09:48, Rick McGuire wrote: > > Nope, I don't do remote access for debugging. > > Rick > > On Wed, Nov 28, 2018 at 8:47

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Here from Ubuntu, rev 11534: [ 0%] Generating rxsubcom.1.gz [ 0%] Built target rxsubcom_man [ 0%] Building CXX object CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Thanks, most of these should be fixed but a couple of the errors puzzled me. Let's see if they go away. Rick ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Time for the *ix users to pitch in.

closesocket -> close [ 0%] Generating rxsubcom.1.gz [ 0%] Built target rxsubcom_man [ 0%] Building CXX object CMakeFiles/rexxapi.dir/rexxapi/common/platform/unix/SysCSStream.cpp.o /home/moritz/dev/repos/oorexx/rxapi/rexxapi/common/platform/unix/SysCSStream.cpp: In member function ‘virtual bool

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Hmmm, I was able to fix a couple of the errors here, but the bulk of them are quite puzzling. The types in question are all defined in SysCSStream.hpp, which is included in the .cpp file. Even more puzzling, there are references to types defined in CSStream.hpp, which is NOT included in the .cpp

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Nope, I don't do remote access for debugging. Rick On Wed, Nov 28, 2018 at 8:47 AM Erich Steinböck wrote: > I don't have access to any linux systems now >> > Rick, if you'd like so, I can give you access to an Ubuntu VM that is used > for ooRexx Jenkins builds, > It's already fully set up for

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> On 28 Nov 2018, at 13:42, Rick McGuire wrote: > > Thanks, fixes checked in. > > Rick > > On Wed, Nov 28, 2018 at 7:32 AM Enrico Sorichetti via Oorexx-devel > > wrote: SysCSSStream.cpp and CSSStream naming mismatch Used the right name but got

Re: [Oorexx-devel] Time for the *ix users to pitch in.

Thanks, fixes checked in. Rick On Wed, Nov 28, 2018 at 7:32 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > > > On 28 Nov 2018, at 13:23, Rick McGuire wrote: > > https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi > > > > Just tried it , got > > [

Re: [Oorexx-devel] Time for the *ix users to pitch in.

> On 28 Nov 2018, at 13:23, Rick McGuire wrote: > > https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi > Just tried it , got [ 6%] Building CXX object

[Oorexx-devel] Time for the *ix users to pitch in.

I think the *ix version of this code rework is ready for somebody to try compiling it (I expect there probably will be a few errors). The code is located at: https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/rxapi I also took a crack at removing the rxapi daemon installation from the deb and