Skip to content
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

Shell gets killed by the kernel #20

Open
Bodanor opened this issue Jun 7, 2022 · 4 comments
Open

Shell gets killed by the kernel #20

Bodanor opened this issue Jun 7, 2022 · 4 comments

Comments

@Bodanor
Copy link

Bodanor commented Jun 7, 2022

Hi,

If you run the command bash -ic <some_command> the shell gets stopped. Not sure why though, I'm running in the same issue with mine ;(

@brenns10
Copy link
Owner

brenns10 commented Jun 7, 2022

Yep, that's... well maybe expected is the wrong term. But it makes sense that it's happening. Here's my transcript:

stephen at envy in ~/repos/lsh (master)
$ ./lsh
> bash -ic date
Tue Jun  7 01:22:38 PM PDT 2022
> 
[1]+  Stopped                 ./lsh

stephen at envy in ~/repos/lsh (master)
$ fg 1
./lsh
help
Stephen Brennan's LSH
Type program names and arguments, and hit enter.
The following are built in:
  cd
  help
  exit
Use the man command for information on other programs.
> exit

Notice that I was able to use the bash command fg 1 to resume my lsh session after it was stopped.

This has to do with job control. Normally shells create a "process group" and execute their children within those groups. They also send signals to their child tasks to stop them and resume them. I'd recommend doing some googling about "job control" and "process groups" related to linux/unix shells.

@Bodanor
Copy link
Author

Bodanor commented Jun 7, 2022

Well first of all, I'm glad you are recognizing this behavior as expected ! Because I've create a stackoverflow post about this issue and nearly every one got confused. Except one comment that said :

"When a background process reads from the terminal it gets a SIGTTIN signal. Normally, that will stop it, the job control shell notices and tells the user, who can say fg to continue this background process as a foreground process, and then this process can read from the terminal."

This was the precise moment I knew I was in trouble and I won't be able to continue if I don't understand this part... We have to play with pipes, dup2 function, etc.. Now, I'm not exactly sure why it behaves like that and sure enough it has to do with job control. But since I'm looking for a concrete answer and I've spend my whole day trying to understand the issue, you seems to be the only guy who can explain this to me like a little child.

A little update on this subject on your blog would help many people out here :)

@FrankRay78
Copy link

Interestingly, the echo command doesn't cause the job to be stopped:

frankray@frank-ubuntu-virtual-machine:~/Repos/lsh$ ./lsh
> bash -ic echo

> help
Stephen Brennan's LSH
Type program names and arguments, and hit enter.
The following are built in:
  cd
  help
  exit
Use the man command for information on other programs.
> exit
frankray@frank-ubuntu-virtual-machine:~/Repos/lsh$ 

I thought maybe it was a built-in command, but it's not: /usr/bin/echo

I'm none the wiser why date behaves one way, echo the other.

@FrankRay78
Copy link

I've create a stackoverflow post about this issue

Out of interest, what's the link @Bodanor ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants