Menu
▾
▴
#1621 RXAPI fails to start
I've installed ooRexx-5.0.0-11849.windows.x86_32 on W8.1 32-bit. I allowed the install to stop RXAPI and uninstall 4.2.0 first. Now RXAPI fails to load. I've rebooted. The actual service in Windows still says "RXAPI Service for Open Object Rexx version 4.2.0".
Related
Discussion
Anonymous
I have vaque memory of the same by switching to oorexx 4.2 and then switch back to oorexx 5 and then upgrade to a later oorexx 5 version, seems that oorexx 5 can't kill oorexx api 4.2.
I manually killed the oorexx api I found in task list and then it worked again.
Strange that the reboot didn't solved this.
oorexx 5.0.0 no longer has an rxapi service. The process is started on the first usage and runs as a background process, not a service.
Well, there's two bugs then. First that the uninstaller doesn't remove the service, and second that the RXAPI process doesn't get started.
Graham, what happens, if you run the following command from he command line (assuming you are running on Windows):
(If it works, then rxapi of ooREXX 5 is running successfully.)
Actually, no. That command does not require rxapi to work. However
rexx -e "push 123"
Will give an error is rxapi can't be started.
Rick
On Wed, Mar 27, 2019 at 6:03 AM Rony G. Flatscher orexx@users.sourceforge.net wrote:
Related
Bugs: #1621
So it's got what is presumably the correct RXAPI.EXE. Unfortunately there's really no indication what the problem is. If I run RXAPI from the command line, there's no messages appear.
(BTW, I'm a little concerned about starting RXAPI from a user process. What is going to happen if REXX in an elevated process wants to use it later? I'd test this if I could!)
If you installed over the old location and the installer had a problem
stopping rxapi, then you likely have an incomplete install. If you still
see the 4.2.0 service installed, then that is likely still the 4.2.0
version, which the 5.0.0 interpreter cannot interact with. If you use the
File Explorer to look at the file propery details, it will tell which
version this is. I suggest uninstalling everything then reinstall cleanly.
On Wed, Mar 27, 2019 at 8:54 AM Graham Norris norrisg@users.sourceforge.net
wrote:
Related
Bugs: #1621
I have done some experimentation with RXAPI in 5.0.0 and found that if you run ooRexx from an elevated process, it will create the RXAPI process sucessfully but ooRexx in a "normal" process will not be able to communicate with it (indicated by the long startup time of a rexx command). The elevated RXAPI process can only be "killed" from another elevated process, not a normal process.
You probably need to uninstall the RXAPI service using Windows tools in order to get rid of the "left over" part of 4.2.0.
Rick, as I posted earlier: "2019/03/23 12:17 134144 A---- C:\Program Files\ooRexx\rxapi.exe". It got replaced.
Gil, yes it looks like I'll need to do that, but the 5.0 installer needs to properly handle problems:
1) No stop request for RXAPI was issued. It doesn't look like that was the case here though.
2) RXAPI didn't stop when requested. It also doesn't look like that was the case here.
3) RXAPI executable was not removed. Possible: at this point I can't tell if it was been removed or overlaid.
4) RXAPI service was not removed. This was definitely the case here.
5) RXAPI doesn't work. This is definitely the case. It was started by HKLM\System\CurrentControlSet\Services\RXAPI, but the Services application in W8.1 does not see it as started (and can't stop it.) I assume this will be because it hasn't registered itself properly.
Killing the rogue RXAPI service (and disabling it until I remove it) does allow RXAPI to be started by "rexx -e "push 123"".
(I can answer my own question about using RXAPI in an elevated session when started from a non-elevated one: it works. I now hope it doesn't give rise to any possible priviledge escalation issues.)
Edit: I must now add a "however". When RXAPI is started by an elevated process, it won't work with a non-elevated one. I have REXX which runs, elevated, from the Task Scheduler. It runs before the user has logged on.
Last edit: Graham Norris 2019-03-27
These problems with RXAPI on Windows are due to feature request https://sourceforge.net/p/oorexx/feature-requests/724/ which led to commit https://sourceforge.net/p/oorexx/code-0/11560/.
Feature request 724 was primarily to fix problems which don't occur on Windows, but the commit doesn't just make changes for non-Windows, it makes a big and so far detrimental change for Windows for no reason which is particularly obvious. The Windows changes for commit 11560 need to be reverted so RXAPI on Windows returns to being a service, just as it was previously.
Hopefully this will be done before OORexx 5 is released. I really don't want to find myself forking it so I can use OORexx 5, not least because subsequent to 11560, someone has moved many source files' "{" braces to the following line, creating a multitude of changed files solely for that reformat: it makes figuring out what has really changed that much harder.
Seems to me that we have (at least) two issues conflated here:
Why is the process started by Task Scheduler used by a logged on user? I'm probably mis-reading FR 724 but it seems that the logged on user should start its own process. Yes? No?
Anyway perhaps we should split this into two, one for install, another for elevated/non process access.
The elevated permission problem was fixed by defect [#1641]
Related
Bugs:
#1641oorexx does not install, because it says that there is already rxapi running or another rexx running, and that is not the case.
Attached pdf with error image.
On Tue, 19 Mar 2024, at 00:31, noreply@sourceforge.net wrote:
I don't know how the installer works ... but that strongly implies to me
that ... "allowed the install to stop RXAPI and uninstall 4.2.0 first" did
not work.
After supposedly uninstalling 4.2.0 did you reboot (I don't know if
the uninstall would ask you to ... but I think I would have done so
anyway.) And then I'd look for evidence that the 4.2.0 version
really had been uninstalled.
Is it possible that - say - 4.2.0 was installed for "all users" but the
attempted uninstall was just for a single user?
--
Jeremy Nicoll - my opinions are my own.
Is that just a mis-quote, or did you not read what you've quoted?
On Tue, 19 Mar 2024, at 08:49, Graham Norris wrote:
Is that comment addressed to me?
If so ... of course I read what I quoted. But you yourself said that
after the supposed uninstall the 4.2.0 service was still there. I was
trying to find out whether YOU CHECKED that 4.2.0 had really been
uninstalled, or just hoped that the uninstall had happened as you
requested. You did not make that clear, & still haven't.
--
Jeremy Nicoll - my opinions are my own.
Jeremy, you appear to have difficulty with message threads. You replied to a message from "anonymous" posted within the last 24 hours, but quoted my original post from 5 years ago.
On Tue, 19 Mar 2024, at 20:42, Graham Norris wrote:
Ah... I see,
The message I replied to (by email, not by going to the SF website)
contained the text I quoted. I suppose SF's system thinks it's useful
to include the first post of a thread even when telling us what the
latest post is. I'd not noticed that before.
The layout of the email is so poor that - to be honest - I've always
assumed (since I normally only read plain text mails) that it was a
poorly generated plain text generated from a fancier html mail. But
looking at the "raw mail" I see there is no html in it.
I see that if I go to the Sourceforge website the whole discussion is
visible, and who posted what is much clearer.
The email doesn't say anything about who sent the first sentence,
just says the email is from: noreply@sourceforge.net ... which may
also have mislead me into thinking the only name shown was that
of the recent poster.
If the text had said something like "Anonymous posted at
I've no idea why I've not fallen down this hole before.
Sorry!
--
Jeremy Nicoll - my opinions are my own.
Apology accepted!
It does seem to me that since this problem continues to crop up, the issue with the installer has not been addressed in those five years.
Problems with rxapi are in fact why I continue to use OORexx 4, albeit it one I build myself with a number of fixes and improvements, plus a few back-ported changes from OORexx 5.