Hercules lack of Linux "suspend/resume" support (i.e. Ctrl+z, fg, etc) causes problems with e.g. tmux

[wyan]

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.

[ivan-w]

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

[ivan-w]

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

[Fish-Git]

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.

[marXtevens]

What OS is running in Hercules?
Do you have a [tn|pw|x]3270 session open to that OS?

[marXtevens]

In the mean time, please try the following.

1. Hercules is running
2. Press Ctrl-Z
3. Enter fg & press Enter
4. Press the ESC key to verify you have Hercules attention. It displays something, even though garbled.
5. Press Ctrl-D
6. Execute the command that you used to start Hercules.
7. You might be back where you have the console available again.

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.

[wyan]

@marXtevens I don't get your solution... Ctrl-D kills Hercules, which is what I want to avoid in the first place.

[marXtevens]

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.

[wyan]

Just did. It just re-IPLs the system...

[marXtevens]

What OS is running in Hercules?
Do you have a [tn|pw|x]3270 session open to that OS?

[marXtevens]

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?

[marXtevens]

Fish,

Does Hercules expect an xterm/VT-100 compatible terminal to display its information in?

[Fish-Git]

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.

[Fish-Git]

I did some Googling and found:

• https://unix.stackexchange.com/questions/218815/tmux-force-resize-window
• https://unix.stackexchange.com/questions/209981/tmux-doesnt-resize-with-terminal-window
• https://stackoverflow.com/questions/44829622/tmux-how-to-adjust-the-tmux-sessions-width-to-fit-in-the-terminal-panel

In all honesty, this sounds like a tmux issue, not a Hercules issue.

[marXtevens]

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.

[Fish-Git]

I can get the problem to occur in gnome-terminal (GNOME desktop), and Konsole (KDE desktop) as well.

I know nothing about either. How can I tell what terminal/desktop I have? (As I said, I'm not a Linux person!)

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.

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.

Who is the panel coder for Hercules?

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 panel.c as well as hconsole.c. But really, why do you ask? Who gives a crap who wrote it? The only important thing is identifying what (if anything at all!) is wrong with our existing code and getting it fixed (if it indeed is broken, which I am personally not convinced that it is).

[marXtevens]

Fish,

I know nothing about either. How can I tell what terminal/desktop I have?
(As I said, I'm not a Linux person!)

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.

echo $XDG_CURRENT_DESKTOP

Clicking on the About button for the active terminal session will tell you which terminal application you are using.

then simply review who the author of each commit was to both panel.c as well as
hconsole.c. But really, why do you ask?

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.

The only important thing is identifying what (if anything at all!) is wrong with our
existing code and getting it fixed (if it indeed is broken, which I am personally not
convinced that it is).

Yes, the burden is on me to provide proof, and a fix, if I can. To reproduce wyan's problem:

1. Hercules is running.
2. Press Ctrl-Z. This puts hercules in the background and paused.
3. Enter fg & press Enter. This brings hercules to the forground and makes it active again.
4. Press the ESC key to verify you have Hercules' attention. Does it display something, even though garbled?
5. Resize your terminal session. Does that make the display readable?
6. Does press the ESC key toggle between the hardware management console and the OS console?

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.

[marXtevens]

wyan,

As Ivan stated earlier:

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.

Depending on your Linux/BSD/... OS you can disable Ctrl-Z with:

stty -isig

Then start hercules. You can re-enable it with:

stty isig

When you are done with hercules.

Optional - before SETTING indicates negation.

[-]isig
enable interrupt, quit, and suspend special characters

See man stty for more information.

[Fish-Git]

I will try my KDE Neon 5.24 and CentOS 6.10 systems next and will let you know the results.

Everything works perfectly for me.

[Fish-Git]

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.

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?

[Fish-Git]

To reproduce wyan's problem:

1. Hercules is running.
2. Press Ctrl-Z. This puts hercules in the background and paused.

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?

3. Enter fg & press Enter. This brings hercules to the forground and makes it active again.

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 fg command?! Help!   :(

4. Press the ESC key to verify you have Hercules' attention. Does it display something, even though garbled?
5. Resize your terminal session. Does that make the display readable?
6. Does press the ESC key toggle between the hardware management console and the OS console?

I will gladly try the above once:

1. I learn how to do it properly, and
2. Learn why one would need/want to do it? (and maybe I should also add):
3. Learn what happens, from Hercules's point of view, when this pausing/bg -> fg/unpausing sequence occurs. Does it cause a signal to be received by (sent to) Hercules? (That Hercules must then properly react to?)

Thanks for any help/insight!

[Fish-Git]

Thanks for bearing with me.

Thanks for bearing with ME!!   :)

[Fish-Git]

Use the following command in a terminal session to determine your desktop manager. If nothing is displayed, then you are not using a GUI.

echo $XDG_CURRENT_DESKTOP

Clicking on the About button for the active terminal session will tell you which terminal application you are using.

fish@kubuntu2110-vm:~$ echo $XDG_CURRENT_DESKTOP
KDE
fish@kubuntu2110-vm:~$ osversion
Ubuntu 21.10
fish@kubuntu2110-vm:~$ 

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

[wrljet]

Ctrl+z, fg, goofs it all up for me, too. Just tried it running Debian 10 with Mate desktop using Mate Terminal.

Resizing the terminal doesn't fix it.

(can't really say I'm too surprised, though)

Bill

[Fish-Git]

Ctrl+z, fg, goofs it all up for me, too.

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!

[marXtevens]

Fish,

I am assuming too much. Sorry.

You are using Ubuntu, and KDE. If you click on the About button for the window your terminal session and hercules are running in, a window should open which should tell you which one of the terminal applications you are using.

I will gladly try the above once:
I learn how to do it properly, and

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 Ctrl-Z, when the focus is on the terminal session where hercules is running.

When you do this, your command prompt displays. This is often, though not always:

[yourusername@yourhost currentdirectory]$

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 fg at the command prompt, you bring hercules back to the foreground, where it belongs, it begins running again (you can see this by checking your 3270 session) and at this point you should see whatever panel was last displayed in your terminal session which is running hercules, displayed again, but incomplete/garbled. Resizing your terminal session will allow the panel to display properly.

Learn why one would need/want to do it?

It is not something you want to do, but Ctrl-Z is often the undo keypress in Windows applications. If you use both Windows and Linux, (as I do) this habit can be annoying to you. The work around Ivan proposed earlier, and I expanded on, tells you how to disable Ctrl-Z, as well as Ctrl-C and Ctrl-D, and then enable it.

(and maybe I should also add):
Learn what happens, from Hercules's point of view, when this pausing/bg ->
fg/unpausing sequence occurs.
Does it cause a signal to be received by (sent to)
Hercules? (That Hercules must then properly react to?)

The Ctrl-Z is used to suspend a process by sending it the signal SIGTSTP , which is like a sleep signal, that can be undone and the process can be resumed. Generally, *nix applications just continue from where they left off, without a hiccough. The applications are usually written to process the signals sent, or to at least ignore them (not recommended). Now there's a whole bunch of gotchas when dealing with signals, better left to better C/Unix programmers than I am.

In my humble opinion, yes, hercules should process those signals in the *nix environment,. It appears hercules code does not handle Ctrl-Z well, or at all, and we get the garbled panels. Other opinions are most welcome.

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 man signal will give you an overview of the use and challenges associated using signals.

I REALLY Hope This Helps

[wrljet]

Hi Fish,

What marXtevens wrote.   :-)

The purpose of Ctrl+z is so you can take long running tasks, say a tar or zip, or even a build, and move it to the background. It's called, I believe, "job control", in Unix. bg will release it to run in the background. fg will bring it back to the current foreground.

Description to the facility here.

I suspect that the various TTY "commands / system calls" issued by Hercules are being reset by the Ctrl+z, and then lost when it comes back to the foreground.

For my money, if you are apt to be typing Ctrl+z by mistake, then the stty -isig / stty isig commands can be used as a wrapper to whatever you use to invoke Hercules.

Bill

[wrljet]

Ctrl+z, fg, goofs it all up for me, too.

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!

After starting Hercules, sitting at its prompt in a terminal window, just type Ctrl+z, and it will be stopped by job control.

[Fish-Git]

You are using Ubuntu, and KDE.

I am using Kubuntu. Specifically, version 21.10. I presume the "K" in "Kubuntu" means KDE based.

If you click on the About button for the window your terminal session and hercules are running in, a window should open which should tell you which one of the terminal applications you are using.

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?

I will gladly try the above once:
I learn how to do it properly, and

Let me try again. I hope this will be clearer.   ...

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?

...
A look at man signal will give you an overview of the use and challenges associated using signals.

I REALLY Hope This Helps

Yes and no. I now know how to suspend/resume a terminal session (I think; after entering fg. the string herc is then displayed (which is the name of the bash script I use to start Hercules with), which I think is the point at which I need to press the enter key. But even then, the escape key didn't do anything. I forget what I had to do, but after some fiddling, I eventually got my device list panel to display, but of course I could never get back to my main Hercules command line panel. I had to forcibly kill my Hercules session to get my terminal session back.

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 SIGTSTP or SIGCONT signals. (And to be honest, I'm not convinced it should!)

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

[wrljet]

If we're voting, I'm with you, Fish. "Enhancement" for later.
Adding the stty -isig / stty isig commands to your Hercules wrapper script will protect you in the mean time.

Bill

[Fish-Git]

If we're voting, I'm with you, Fish. "Enhancement" for later.

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 tmux, but rather has simply to do with our lack of support for Linux "suspend/resume" (i.e. Ctrl+z, etc).

Alice? (@wyan) Mark? (@marXtevens) Does this sound okay to you?

[marXtevens]

I have no problem with the work around, the new title, nor the classification as an Enhancement.

Thank you.