I have one terminal open with a java server running. I can easily get the process-ID (PID) of this JAR process. From another terminal, I want to signal this process to stop and restart in that same terminal where is is currently running. Is this possible using bash? Is there any signal i can send to the PID to make it stop and start again?
From another terminal, I want to signal this process to stop and restart in that same terminal where is is currently running. Is this possible using bash?
You can send signals to a process via the kill command. You may need to either be a privileged user or have the same UID as the process you're signaling.
But read on ...
Is there any signal i can send to the PID to make it stop and start again?
If you mean "stop" as in terminate and "[re]start" as in run from the beginning as if a new process, then there is no signal for which that is the default handling. A process could provide such behavior in response to a signal of its choice, but you cannot evoke it from an arbitrary process.
On the other hand, if you want to "stop" in the sense of temporarily suspending operations, and to "start" in the sense of resuming from such a stop, then there are SIGSTOP and SIGCONT, for which the default handling should suffice. Be aware, however, that stopping a process in this sense probably will not take it out of the foreground (if it is in the foreground), and that processes can block, ignore, or provide their own handling for those signals.
You can send signals with kill.
kill -s <SIGNAL> <PID>
will send the signal <SIGNAL> to the process with pid <PID>.
To stop and continue, you can use SIGSTOP and SIGCONT, which acts basically like hitting Ctrl-Z to pause a program on the terminal.
Related
I've read the chapter about the job control in the glibc manual, but I'm wondering what to do with the remaining jobs when the shell is terminated.
I suppose the following steps (following the convention of posix to handle orphaned process groups the first two steps seems obvious):
send an HUP signal to the jobs with the shell's sid
send a CONTINUE signal to the stopped jobs with the shell's sid
free up the resource allocated for the job's data structures
My problem is what if the jobs survive?
I thought that a chance would be changing their session id to free up the sid and disassociate the process group from the terminal (not sure if that makes sense)
Should I do ioctl(STDIN_FILENO, TIOCSCTTY) to make the session processes lose the controlling terminal and send the signals?
What to do with the tty? Should I launch a login and set it as a new controlling terminal process group of the tty?
I'm still confused and a clue would be appreciated.
send an HUP signal to the jobs with the shell's sid
No need for that. The kernel will send a HUP signal itself when the shell (the session leader) terminates.
send a CONT signal to the stopped jobs with the shell's sid
No need for that. The kernel will send it for you, too ;-)
free up the resource allocated for the job's data structures
No need for that, either. All resources used by a process will be freed up by the kernel when the process terminates.
My problem is what if the jobs survive?
I guess you can SIGKILL them, if that's really a problem. In unix, they're supposed to survive, if they handle SIGHUP.
The "modern" systemd takes a different approach, completely against that spirit, but I would not enter into that ;-)
Notes:
In linux, it's the kill_orphaned_pgrp() from kernel/exit.c which is responsible for sending the HUP+CONT to all stopped jobs from the session, and tty_signal_session_leader() from drivers/tty/tty_jobctl.c, called via tty_vhangup_session() and __tty_hangup() which is resposible for sending the HUP to the processes from the foreground process group.
Should I launch a login and set it as a new controlling terminal process group of the tty?
I read up and I think the answer should be no.
For a character based terminal, the root process (initd/systemd/launchd etc) forks and execs getty for the preconfigured terminals or at a specific event.
Getty opens the terminal files for read/write and associates the std file descriptors to the terminal, sets a simple environment from a configuration file and prompts for a username, then execs login for that username.
Login changes the ownership and permission rights for the terminal, changes the persona of the process (effective and real uid, gid, supplement groups), and execs a login shell
When a shell terminates, its parent process get notified by a sigchd, and relaunches getty...
So the tty initialization/destruction is not a task for the shell..
Yet not sure on how to treat the survived process groups..
I am testing a code which respond to SIGINT. I am using Mac, is Ctrl-C to send the SIGINT? I tried, it seems no response.
You can use Activity Monitor to send signals to processes. Select the process in the process list and then choose View > Send Signal to Process. In the resulting sheet, select SIGINT from the pop-up menu and hit the Send button.
First, find the name of the process. So, if you think it is called something like "monkey", try this in Terminal:
pgrep -i monkey
and see if that tells you some process ids. If it does, you can then do:
pkill -SIGINT -i monkey
If I kill -QUIT the master resource manager process, it restarts and then runs normally. But if I kill -ABRT the master resource manager process, it restarts but processes on HAWQ restart. So how does HAWQ handle different kill signals?
There are multiple processes started by postmaster
1. Resource Manager
2. master logger process
3. stats collector process
4. writer process
5. checkpoint process
6. seqserver process
7. WAL Send Server process
8. DFS Metadata Cache Process.
For the SIGNAL response, different processes have different handling.
master logger process is independent with other processes, other process restart will not influence it, and its restart will not influence other processes too. For SIGQUIT, it will ignore. For SIGABORT and SIGKILL, it will restart.
stats collector process doesn't influence other processes, but will be influenced by other process's restart. For signal SIGQUIT, SIGABORT, or SIGKILL, it will restart itself.
Resource Manager process, For signal SIGQUIT, it will restart itself, for signal SIGABORT and SIGKILL, will restart all other sub-processes.
The other 5 processes, for signal SIGQUIT, SIGABORT, or SIGKILL, will restart itself and all other sub-processes except master logger process.
HAWQ Resource Manager catches the signal SIGQUIT, and registers a function named quitResManager to handle the signal. The process will quit peaceably. But for the signal SIGABRT, the Resource manager will generate coredump according to the definition of SIGABORT.
Since the Resource manager process is forked by postmaster, the postmaster process keeps an eye on watching its subprocess, and will restart the sub-process itself if finding subprocess normally quits, but will restart all the sub-processes if finding error in subprocess.
So you can see the Resource Manager process itself is restarted after you send kill -QUIT, but see all the processes on the HAWQ master restarted after you send kill -ABORT.
I wonder if hawq resource manager process is killed by SIGKILL, whether parent postmaster process will also exit?
#huan, parent postmaster will not restart itself if any sub-processes meets error. But if itself meets error, it will not restart anyone, all the sub-processes will be killed.
Our group has long running processes which run daily. The processes are typically started at 9pm on any given day and run until 7pm the next day. Thus they typically run 22hrs/day. They are started by scheduled tasks on servers under a particular generic user ID, and they start and run regardless of whether or not that user ID is logged on. Thus, they are windowless console executables.
The tasks orchestrate computations running on a large server farm. Generally these controlling tasks run uninterrupted for the full 22hrs/day. However, we often have a need to stop and restart these processes. Because they control a multitude of tasks running on our server farm, it is important that they be shut down cleanly, so that they can stop and shut down all the server farm processes. Which brings me to our problem.
The controlling process has been programmed to respond to ctrl-C and ctrl-break signals. This works fine when the process is manually started in a console where we have access to the console and can "type" ctrl-c or ctrl-break in the console window. However, as mentioned, the processes typically run as windowless scheduled tasks. Hence we cannot "type" anything into a non-existent console window. Because they are console processes that execute without a logon process, the also must be able to execute in a completely windowless environment. So, how do we set up the process to listen for a shut-down signal?
While the process does indeed listen for a ctrl-C and ctrl-break signal, I can see no way to send that signal to a process. This seems to be a fundamental problem in Windows, or am I wrong? I am aware of SendSignal.exe, but so far have been unable to get it to work. It fails as follows:
>SendSignal 26320
Sending signal to process 26320...
CreateRemoteThread failed with 0x00000005.
StartRemoteThread failed with 0x00000005.
0x00000005 == Access is denied.
Trying "taskkill" without -F results in:
>taskkill /PID 24840
ERROR: The process with PID 24840 could not be terminated.
Reason: This process can only be terminated forcefully (with /F option).
All other "kill" functions kill the process immediately rather than sending a signal.
One possible solution would be a file-watch based solution: create a watch for some modification of a specific file. But this is a hack and we would prefer to do it with appropriate signaling. Has anyone solved this issue? It seems to be so very basic a functionality, and it is certainly trivial to do it in a Unix environment. Surely Microsoft has provided SOME mechanism to allow clean shut down of a windowless executable?
I am aware of the thread below, whose question is virtually identical (save for the specification of why the answer is necessary, i.e. why one needs to be able to do this for a windowless, console-less process), but there is no answer there excpet for "use SendSignal", which, as I said, does not work for us:
Can I send a ctrl-C (SIGINT) to an application on Windows?
There are other similar questions, but no answers as yet.
Any help appreciated.
[Upgrading #Anon's comment to an answer for visibility]
windows-kill worked perfectly and managed to resolve access denial issues faced with SendSignal. A privileged user would have to run it as well of course.
windows-kill also supports both ctrl-c and ctrl-break signals.
I have a windows C++ application (app.exe). When the app is closed, I need to perform some cleanup tasks specific to my application. What happens when this process (app.exe) is killed through the Task Manager. Assuming that the application is still responsive, can I somehow handle this situation in my app.exe?
I am looking for something similar to how kill <pid> in Linux will send the SIGTERM signal to the process indicated by pid. I could then register my own signal handler for SIGTERM and perform the cleanup.
There are two ways to kill application in Task Manager.
Killing through Applications tab would roughly be equivalent of SIGTERM. Application may intercept it and do more processing, since it's basically sending a "close window" message. Message to catch is WM_CLOSE.
Killing through Processes tab would roughly be equivalent of SIGKILL. There is nothing you can do to intercept that, short of monitoring user's actions in Task Manager's listbox and End Process button, or having a watchdog process that will see when the first one is killed.
Alternatively, design the application in a way that does not require cleanup, or in a way that it will perform cleanup at startup.
I think you will need another PID that is monitoring the PID of your app.exe and does the necessary work at the time.
That depends, if the user chooses to "End Task" your application you will be notified and you can handle it see this.
but if the user chooses to end the process, you have no way to handle it in your application. the easiest way would be a second process or you can inject into process manager and hook the TerminateProcess API.