What is happening after kill -CONT ?How to suspend and resume processesHow to suspend and resume processes...
Question in discrete mathematics about group permutations
Have 1.5% of all nuclear reactors ever built melted down?
Efficient Algorithm for the boundary of a set of tiles
How to let other coworkers know that I don't share my coworker's political views?
What is a fully qualified name?
Ethical issue - how can I better document what is happening?
Could a 19.25mm revolver actually exist?
Popcorn is the only acceptable snack to consume while watching a movie
Are black holes spherical during merger?
Why does Mjolnir fall down in Age of Ultron but not in Endgame?
Can I connect my older mathematica front-end to the free wolfram engine?
Why most published works in medical imaging try reducing false positives?
Ingress filtering on edge routers and performance concerns
Do I need full recovery mode when I have multiple daily backup?
Is the field of q-series 'dead'?
Why did Jon Snow do this immoral act if he is so honorable?
Why did Theresa May offer a vote on a second Brexit referendum?
Why did the person in charge of a principality not just declare themself king?
Construct a word ladder
What was the idiom for something that we take without a doubt?
Pirate democracy at its finest
Best material to absorb as much light as possible
How to attach cable mounting points to a bicycle frame?
Need to understand my home electrical meter to see why bill is so high and/or if neighbor is on same meter
What is happening after kill -CONT ?
How to suspend and resume processesHow to suspend and resume processes like bash doesGraceful way to kill process`ps | grep | kill` aborts my script prematurelykill all process of executables in a folderGetting pid of bash script from itselfPID of a bash process not captured by $!killing parent process doesn't kill childDifference Between bg and kill -CONTSuspend and then resume a process in python scrip - Linux
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I have suspend a process through kill -TSTP <pid>. Then tried to continue it with kill -CONT <pid>. But After completion of process, control is not returning to bash. Why this is happening? And what to do to overcome this problem?
I started the process (a shell script) from one bash (say bash-1) with ./name.sh. Then suspended that process with the command kill -TSTP <pid> through bash-2. Finally tried to resume it with kill -CONT <pid> through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
command-line process kill
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
bumped to the homepage by Community♦ 51 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I have suspend a process through kill -TSTP <pid>. Then tried to continue it with kill -CONT <pid>. But After completion of process, control is not returning to bash. Why this is happening? And what to do to overcome this problem?
I started the process (a shell script) from one bash (say bash-1) with ./name.sh. Then suspended that process with the command kill -TSTP <pid> through bash-2. Finally tried to resume it with kill -CONT <pid> through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
command-line process kill
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
bumped to the homepage by Community♦ 51 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
1
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's thepsoutput? Is the process gone? If not, what's its state? Is maybe just echo disabled? Trystty echo+ enter.
– orion
Apr 7 '16 at 9:43
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41
add a comment |
I have suspend a process through kill -TSTP <pid>. Then tried to continue it with kill -CONT <pid>. But After completion of process, control is not returning to bash. Why this is happening? And what to do to overcome this problem?
I started the process (a shell script) from one bash (say bash-1) with ./name.sh. Then suspended that process with the command kill -TSTP <pid> through bash-2. Finally tried to resume it with kill -CONT <pid> through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
command-line process kill
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
I have suspend a process through kill -TSTP <pid>. Then tried to continue it with kill -CONT <pid>. But After completion of process, control is not returning to bash. Why this is happening? And what to do to overcome this problem?
I started the process (a shell script) from one bash (say bash-1) with ./name.sh. Then suspended that process with the command kill -TSTP <pid> through bash-2. Finally tried to resume it with kill -CONT <pid> through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
command-line process kill
command-line process kill
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
edited Apr 7 '16 at 22:18
Gilles
555k13411391649
555k13411391649
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
asked Apr 7 '16 at 9:21
Shamindra ParuiShamindra Parui
112
112
bumped to the homepage by Community♦ 51 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 51 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
1
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's thepsoutput? Is the process gone? If not, what's its state? Is maybe just echo disabled? Trystty echo+ enter.
– orion
Apr 7 '16 at 9:43
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41
add a comment |
1
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's thepsoutput? Is the process gone? If not, what's its state? Is maybe just echo disabled? Trystty echo+ enter.
– orion
Apr 7 '16 at 9:43
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41
1
1
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's the
ps output? Is the process gone? If not, what's its state? Is maybe just echo disabled? Try stty echo + enter.– orion
Apr 7 '16 at 9:43
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's the
ps output? Is the process gone? If not, what's its state? Is maybe just echo disabled? Try stty echo + enter.– orion
Apr 7 '16 at 9:43
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41
add a comment |
3 Answers
3
active
oldest
votes
Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.
If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
add a comment |
You should have stopped your process with kill -STOP, not kill -TSTP.
The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.
The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
add a comment |
kill -CONT is something that is not understood by the shell.
For this reason, it just continues the process without any effect to the shell.
This results in something similar to a background process.
If you like to continue a process, better call fg or if this
is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.
Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.
If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f274860%2fwhat-is-happening-after-kill-cont-pid%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.
If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
add a comment |
Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.
If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
add a comment |
Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.
If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
Process started from a shell have a controlling TTY associated with them that they inherit from the shell and also belong to a process group. When running multiple processes in a pipe with | or using subshell notation with ()'s, all those processes are started with the same process group. When the user hit's the suspend keystroke, normally Ctrl-Z from the keyboard, the TTY layer sends the SIGTSTP signal to all processes in the current foreground process group and the parent shell wakes up with a SIGCHLD (or returns from it's call to wait()) to handle the TTY again. The shell is responsible for controlling which process group is in the foreground for it's controlling TTY and the shell itself resides in it's own process group.
If a process is not part of the current, foreground process group for the TTY, it will be stopped automatically by the TTY layer with a SIGTTIN if it tries to read from the terminal. For example, sending SIGCONT to an interactive text editor like vim will resume it, but it will immediately get a SIGTTIN as soon as it call's read() to get the next keypress from the keyboard. The shell must be notified with the fg job control directive that it should move vim to the foreground process group before resuming it thereby removing the shell from being in the foreground.
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
answered Sep 8 '17 at 17:03
penguin359penguin359
9,04423242
9,04423242
add a comment |
add a comment |
You should have stopped your process with kill -STOP, not kill -TSTP.
The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.
The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
add a comment |
You should have stopped your process with kill -STOP, not kill -TSTP.
The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.
The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
add a comment |
You should have stopped your process with kill -STOP, not kill -TSTP.
The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.
The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
You should have stopped your process with kill -STOP, not kill -TSTP.
The former is designed to support suspending/resuming a process just with signals so kill -CONT would have produced the expected result while the latter (SIGTSTP) is more designed to support job control.
The interactive shell that launched your stopped script is able to revive it through the fg command. fg does extra things before eventually resuming the process with SIGCONT. Sending the signal alone isn't enough.
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
edited Apr 7 '16 at 23:18
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
answered Apr 7 '16 at 22:40
jlliagrejlliagre
48.4k786138
48.4k786138
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
add a comment |
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
Both of your basic claims are wrong. The only difference between STOP and TSTP is that TSTP is automatically generated by the tty driver in some cases. Every process with the same credentials is permitted to resume a process.
– schily
Apr 7 '16 at 22:50
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
@schily Thanks for your downvote and constructive comments. Every process with the required privileges is indeed permitted to resume a stopped process, that's the reason why the OP didn't ask any question in the first place.
– jlliagre
Apr 7 '16 at 23:17
add a comment |
kill -CONT is something that is not understood by the shell.
For this reason, it just continues the process without any effect to the shell.
This results in something similar to a background process.
If you like to continue a process, better call fg or if this
is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.
Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.
If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
add a comment |
kill -CONT is something that is not understood by the shell.
For this reason, it just continues the process without any effect to the shell.
This results in something similar to a background process.
If you like to continue a process, better call fg or if this
is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.
Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.
If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
add a comment |
kill -CONT is something that is not understood by the shell.
For this reason, it just continues the process without any effect to the shell.
This results in something similar to a background process.
If you like to continue a process, better call fg or if this
is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.
Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.
If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
kill -CONT is something that is not understood by the shell.
For this reason, it just continues the process without any effect to the shell.
This results in something similar to a background process.
If you like to continue a process, better call fg or if this
is not the "current job", use jobs to list all current jobs and then call e.g. fg %3 if the job in question is job #3.
Note that the difference between calling kill -CONT and fg from the launching shell is that with fg, the shell in addition to sending the SIGCONT signal sets the tty process group to the process group of the resumed process. The setting of the tty process group controls the automated delivery of the signals TSTP, TTIN and TTOU. Later the shell starts to wait for the command.
If you however called kill -CONT from a different shell/tty than the one where the process in question runs, then it should be really obvious that you just continue a foreign process. The shell that fired the kill -CONT will just return to it's prompt, but you see this.
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
edited Apr 8 '16 at 15:13
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
answered Apr 7 '16 at 9:43
schilyschily
11.1k31844
11.1k31844
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f274860%2fwhat-is-happening-after-kill-cont-pid%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
We need more information here. Are you starting the process from bash? Are you backgrounding the process or running straight in the foreground? Does the process indeed complete successfully? Some processes are sensitive to stopping (when timeouts and such are involved). Is the process still waiting on something? What's the
psoutput? Is the process gone? If not, what's its state? Is maybe just echo disabled? Trystty echo+ enter.– orion
Apr 7 '16 at 9:43
Yes, started the process (a shell script) from one bash (say bash-1) with "./name.sh". Then suspended that process with the command "kill -TSTP <pid>" through bash-2. Finally tried to resume it with "kill -CONT <pid>" through bash-2. But after completion of shell script, control is not returning, it just staying there forever.
– Shamindra Parui
Apr 7 '16 at 11:41