-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hercules lack of Linux "suspend/resume" support (i.e. Ctrl+z, fg
, etc) causes problems with e.g. tmux
#487
Comments
I am going to go out on a limb and saying that the effects of CTRL-Z (or rather receiving the SIGSTP signal) will probably trigger events in the shell that invoked the Hercules command, which may lead to the topmost shell in the process group to issue a certain number of adjustments to the controlling terminal in order to make it usable. Returning the original process to the foreground (usually fg - which sends the SIGCONT signal) may not reset everything to its original state. This is more probably an issue with the shell being used on your POSIX like system in itself rather than with Hercules. I am not certain that trapping SIGSTP is the proper way to do it. Other fullscreen applications (think vi/vim/etc..) seem to be able to handle it, so I need to check that out. I would not consider this a high priority issue (simple workaround answer would be: don't press CTL-Z!) - although it might be an issue if you are trying to send CTRL-Z to the integrated console. One possible option as an actual workaround is to re-assign the stty 'susp' to something else than CTRL-Z before invoking Hercules and then reset it back afterwards. --Ivan |
Update... I haven't tried this yet, but did anyone try to send CTRL-Z to the integrated console using CTRL-V+CTRL-Z? (I'll try it soon)... |
What's the word in this issue? Is it a bug in Hercules or not? Based on what Ivan has said, it sounds like it's something outside of Hercules's control, and therefore not a bug in Hercules. Being unfamiliar with Linux however, I cannot be sure. Should we close this issue as "Unknown"? Or keep it open? (and if so, should we label it as "Bug"?) Thanks. |
What OS is running in Hercules? |
In the mean time, please try the following.
I tried this several times and it seemed to work each time, giving me access to the OS (VM/370 CE) which was running in Hercules. I Hope This Helps. |
@marXtevens I don't get your solution... Ctrl-D kills Hercules, which is what I want to avoid in the first place. |
Entering Ctrl-Z cripples Hercules. Yes, Ctrl-D does kill it ... BUT ... restarting Hercules using the exact command you used the first time, starts Hercules, and it picks up where it left off when you press Ctrl-Z. I tried this four-five times, and it reattached to my VM/370 CE system every time, and I could continue working, without shutting down, or having to re-IPL the system Hercules was supporting. Try it. I think you'll like it. |
Just did. It just re-IPLs the system... |
|
wyan, I guess I misunderstood what you said originally. Sorry for that. So no Ctrl-D. If you resize your terminal, 80x24 to 43x80, or similar, does Hercules redraw correctly? If you press Escape after it redraws, do you go back to the console? |
Fish, Does Hercules expect an xterm/VT-100 compatible terminal to display its information in? |
I have no idea. I'm not a Linux person. You're asking the wrong person. But if I had to guess based on the code, I would say no. The only thing it appears to expect is support for ANSI escape codes. Anything beyond that I have no idea. Someone more familiar/experienced with both Linux and Hercules's existing "panel" code should answer that. Not me. I'm not qualified. |
I did some Googling and found:
In all honesty, this sounds like a tmux issue, not a Hercules issue. |
I can get the problem to occur in gnome-terminal (GNOME desktop), and Konsole (KDE desktop) as well. If I resize the terminal session, then the alternate semi-graphical "New Panel" display showing devices, registers etc. displays correctly, but pressing Escape will not return me to the hardware management console window. The Escape character (^[) displays, and display goes out of whack until I resize. Who is the panel coder for Hercules? What I'm seeing seems like the session is losing sensitivity to input, when brought back to the foreground, and not processing the Escape as it ought to. I have performed resets on the gnome-terminal and Konsole to return it to their normal xterm emulation, and this does not help, nor hinder. |
I know nothing about either. How can I tell what terminal/desktop I have? (As I said, I'm not a Linux person!)
Well I just tried it on my Ubuntu 21.10 system, and it worked just fine. I am not seeing the behavior you are. I will try my KDE Neon 5.25 and CentOS 6.10 systems next and will let you know the results.
Immaterial. Hercules is a collaborative effort with many, many different people contributing various bits and pieces of code over the years, so who wrote our existing panel code is wholly immaterial. I guess the correct answer would be both no one and everyone. If you want to know who contributed to our panel code, then simply review who the author of each commit was to both |
Fish,
Some of these questions are directed toward wyan, not you. Please don't take offense at my asking, as your tone is getting defensive, and I'm not here to poke a bear, but to help. I understand you are not a Linux guru. You are my guru for Hercules. And I understand you don't know everything, because of the multiple contributors. Ubuntu uses the GNOME desktop by default, as does CentOS. Neon, by your description is using KDE. Use the following command in a terminal session to determine your desktop manager. If nothing is displayed, then you are not using a GUI.
Clicking on the
So I could ask the author(s) about the code. But as you have mentioned it is immaterial, especially, now that I know the code to look at. Thank you for providing the names of the programs. I can go look at those and see what I can see.
Yes, the burden is on me to provide proof, and a fix, if I can. To reproduce wyan's problem:
If you are successful in toggling between the two panels, that is a good clue. If it does not toggle, as is the case for Konsole and GNOME terminal, then that is a good clue as well. Thanks for bearing with me. |
wyan, As Ivan stated earlier:
Depending on your Linux/BSD/... OS you can disable
Then start hercules. You can re-enable it with:
When you are done with hercules.
See |
Everything works perfectly for me. |
Eh? Defensive? I wasn't aware of that, and I sincerely apologize if that's the way I'm coming across to you. Was it my "Immaterial." response to your question regarding who the panel coder for Hercules was? If so, I wasn't trying to be defensive. I was simply trying to factually/accurately point out that the answer to such a question is completely immaterial with respect to getting to the bottom of what the heck is going on, that's all. Nothing defensive about it. Just trying to be accurate as well as trying to stay focused on the issue. It doesn't matter who wrote what. The only thing that matters is whether what we have is right or wrong and, if wrong, to get it fixed. Yes? |
From where? From the terminal session that's running Hercules? (i.e. from the HMC? i.e. from the Hercules command line?) I'm unfamiliar with how one pauses and moves a process/terminal session to the background and then brings it to the foreground and unpauses it again. I've never in my life ever found a need to do that. Why would you want to do that?
Again, from where?! From the desktop? From the Hercules terminal session?! I thought it was supposed to be paused?! From where do I enter this
I will gladly try the above once:
Thanks for any help/insight! |
Thanks for bearing with ME!! |
Help -> About displays KDE. And as I said, it works fine for me. (although I have not yet tried your "pause->background, etc" sequence yet. Maybe that's where the "problem" is?) |
Resizing the terminal doesn't fix it. (can't really say I'm too surprised, though) Bill |
Please read my earlier comment. How did you do it? I'd like to try it for myself too! But it's not clear to me how it's supposed to be done! Can you (or anyone!) help me to understand? Thanks! |
Fish, I am assuming too much. Sorry. You are using Ubuntu, and KDE. If you click on the
Let me try again. I hope this will be clearer.The problem with hercules occurs when the hercules program, running in a terminal session (tmux, Konsole, Mate Terminal, GNOME terminal) is sent to the background by pressing When you do this, your command prompt displays. This is often, though not always:
At this point the hercules program is 'sitting' in the background and not running. This can be verified by checking your 3270 session to the OS. Try pressing a PF key, or type in a command. Your session will lock. By typing
It is not something you want to do, but
The In my humble opinion, yes, hercules should process those signals in the *nix environment,. It appears hercules code does not handle I opened the two routines you mentioned previously and was astounded at how long they are, though I shouldn't have been. It's going to take me a while to chew and swallow those, to know what they are and are not doing. A look at I REALLY Hope This Helps |
Hi Fish, What marXtevens wrote. The purpose of Description to the facility here. I suspect that the various TTY "commands / system calls" issued by Hercules are being reset by the For my money, if you are apt to be typing Bill |
After starting Hercules, sitting at its prompt in a terminal window, just type |
I am using Kubuntu. Specifically, version 21.10. I presume the "K" in "Kubuntu" means KDE based.
Here is what Help --> About displays: So I PRESUME the terminal application I am using is "Konsole", yes? And I presume, just like "Kubuntu", the "K" in "Konsole" means KDE, yes?
Okay, I just tried it, and yes, things don't work properly. My terminal session is basically hosed. Not garbled, but definitely hosed (as in "not functioning properly" like it was before). So it's definitely the suspend/resume keystroke sequence that's the cause IMO. But is that really Hercules's fault though? Is the reason it's not working due to a bug in Hercules? (i.e. is it being caused by what/how Hercules is doing or not doing something?) Or is it simply because Hercules was not written with support for this suspend/resume feature in mind? Do you see where I'm coming from? At this point it sounds to me like Hercules is simply missing support for this particular feature of Linux. That is to say, Hercules is not necessarily doing anything wrong per se. It is simply missing support. So this GitHub Issue that Alice (@wyan) wrote, is not so much a bug report, but rather is in fact an Enhancement request. If I am understanding things correctly (i.e. if we presume that Hercules is not doing anything incorrectly, but rather is simply not doing something that needs to be done in order to support this particular feature), all we need to do is make the changes needed -- whatever those changes might be! -- so that this suspend/resume feature works correctly with Hercules. That is to say, this should actually be treated as a feature request, not a bug report. Yes? Would you agree with that?
Yes and no. I now know how to suspend/resume a terminal session (I think; after entering All I can say (and other Hercules developers might (as I'm sure you probably will) feel differently) is, "Don't do that!" If you accidentally press Ctrl+z, then you're going to have to live with having to manually kill your Hercules session and start it over again. Sorry! It doesn't seem like Hercules was written to support the CAN it be modified to support them? (such that suspend/resume then behaves properly?) Yes, I'm sure it can be. What's involved in doing so however, I don't know. As I've said, Linux is not my forte. Perhaps some other Hercules developer (or perhaps you! (?)) can manage to figure out what needs to be done. But until then (i.e. until more convincing evidence is provided to the contrary), I am of the opinion that this is not a bug, but rather a feature ("Enhancement") request. And a rather low priority one at that! Sorry! (Do any other of my fellow Hercules developers care to offer their own opinion/comments regarding this issue?) |
If we're voting, I'm with you, Fish. "Enhancement" for later. Bill |
Thanks, Bill. I will change this GitHub Issue to "Enhancement" and leave it open for eventual possible implementation. I think I'm going to change the Title as well to be descriptive of the actual problem. That is to say, I don't believe the issue has anything in particular to do with Alice? (@wyan) Mark? (@marXtevens) Does this sound okay to you? |
fg
, etc) causes problems with e.g. tmux
I have no problem with the work around, the new title, nor the classification as an Enhancement. Thank you. |
On Linux, running Hercules under tmux, accessed remotely via ssh.
If I accidentally press Ctrl-Z and the job gets suspended, when I bring it back to the foreground with
fg
the console stops working properly, ignoring some keypresses (especially PgUp/PgDown, arrows, etc). If I press Esc to go to the Hercules front panel in this state, the console scrambles even more, not displaying the full front panel, and becoming incapable of processing the Esc key (thus completely disabling the console at all).The only solution I've found to this is to kill Hercules (since it can't be quit anymore from this state), which doesn't allow for the guest OS to be shut down properly.
The text was updated successfully, but these errors were encountered: