Community
Participate
Working Groups
When a remote shell has been started to execute some program, and that program is no longer repsonding, it's necessary to send a signal to the program. DStoreHostShell is working around this by defining a synthetic command "#break" that can be sent. But this synthetic command is not documented as API and therefore not implemented in any other shell implementation. A mechanism for sending signals should be exposed as API of IHostShell officially. For agent-based implementations such as dstore, it could be implemented on the remote side; for SSH, it can be implemented by calling JSch's public API Channel#sendSignal(String) I have not yet checked what kinds of signals the SSH protocol supports, and how the various signal types could be defined in a platform-neutral manner. An interrupt signal such as "#break" does now for dstore should be the very minimum that we should support.
Not sure if a truly platform independent manner is needed or if "classes" would be good enough. Classes could be: -Posix -Windows -... That way an application still could write code for a variety of systems it may support (like all Unixoids via Posix).
We'll need concrete use-cases for this before we can define any API.
We need to signal a server process to reconfigure and cleanly shutdown. We use the unix SIGUSR1 and SIGUSR2 signals to do that. We use the SSH connection type.
Is your server process actually started through RSE IHostShell? Then this is the right bug for you. Otherwise, you'll want to execute kill -SIGUSR1 <pid> in a shell, and this bug doesn't apply to you because it's about signaling to the process executed through the shell.
Yes, in the scenario where I want to send the signal the server process is started with RSE IHostShell. Currently we have a workaround where we get the PID of the process and execute another IHostShell to run the kill command you mentioned. But we'd rather do it without those hacks.
By looking at bug 153275, I just noticed that having an API for sending signals won't help us if we also do some implementation: * On dstore, signals cannot be sent to the remote process because the Open Source Miner has no PTY support. The attachment on bug 196337 might help here. * On SSH, signals cannot be sent to OpenSSH daemons at least, because they do not implement the relevant RFC -- so having the corresponding API in JSch and/or IHostShell doesn't buy us much immediately. https://bugzilla.mindrot.org/show_bug.cgi?id=1424 I'm thus deferring this request. The workaround for SSH to send break is to send a literal Ctrl+C character, which is interpreted by the remote PTY. The same should work on Telnet. For other signals, a separate channel must be opened to send a "kill" command.
I still think that RSE wants to provide the API If it uses a separate channel to send a "kill" command behind the scenes, that's OK with me. To make it clear. The fact that RSE provides this API does by no means need the underlying connection must to be able to "support" that feature. As long as RSE has a way to implement the feature we should NOT force ALL users of RSE to implement the same workarounds for an API that is clearly needed.
