Other csh bug?

[elgrande]

Is the following intended or a bug in csh()?

This code results in make() being canceled:

cd /src
make buildkernel & ; exit

Why?

 

[zirias@]

I'd say a C shell is a bug *scnr*

But seriously, this is expected behavior with any shell. & just runs something "in background", but doesn't do anything to detach it from the controlling terminal (like e.g. calling setsid(2)). So, when the controlling terminal exits, it will get a SIGHUP ("hangup" signal), which is the most likely cause for make to exit here. Of course, writing to stdout would also fail suddenly.

A workaround is offered by nohup(1) (which will also capture any further output to a file). Note this is IMHO still a bad idea, better use a tool like sysutils/tmux to run your build in some detachable terminal you can re-attach later.

 

[elgrande]

Then I do not understand why executing

cd /src
make buildkernel &
exit

sequentially keeps the make process[es] alive.

 

[cracauer@]

`cmd1 & ; cmd2` should be invalid syntax.

`cmd1 & cmd2` is correct.

Please don't say "is canceled". Copy and paste what happens.

 

[Flirek]

your make process will work until it tries to read or write to its terminal (which is gone after exit). use "nohup make ..... &" , and think if you want to save stdout/stderr to file if you later want to see what was happened.

 

[elgrande]

nohup make buildkernel & exit

also kills make() as seen by no make in ps -A
and why does

nohup make buildkernel > /dev/null & ; exit

keep make() alive, but

nohup make buildkernel & ; exit

kills make()?

 

[zirias@]

`cmd1 & ; cmd2` should be invalid syntax.

Only in a "strictly conforming" POSIX shell. Seems tcsh treats the ; as just an empty statement (like, uhm, in C ...). I just checked, zsh also accepts it although being bourne compatible.

But anyways, it's certainly superfluous.

why does

nohup make buildkernel > /dev/null & ; exit

keep make() alive, but

nohup make buildkernel & ; exit

kills make()?

This is really entering the area of guesswork. Maybe nohup fails to create its output file in both the current directory AND $HOME? It only attempts to do that if stdout is a terminal.

BTW, directing build output to /dev/null is a really bad idea.

What are you trying to accomplish here?

 

[elgrande]

Only in a "strictly conforming" POSIX shell. Seems tcsh treats the ; as just an empty statement (like, uhm, in C ...).

Yeah I agree it is maybe like in C.

I just checked, BTW, directing build output to /dev/null is a really bad idea.

Can you explain what is bad about redirecting to /dev/null please?

What are you trying to accomplish here?

I think about triggering a routine from https://www.unix.com/man-page/osx/8/launchd/# what may trigger something and logoff again.

 

[zirias@]

Can you explain what is bad about redirecting to /dev/null please?

Uhm, you will have no damn idea what went wrong if it doesn't complete successfully?

You'll even have a hard time to check whethere it did complete...

I think about triggering a routine from https://www.unix.com/man-page/osx/8/launchd/# what may trigger something and logoff again.

Sounds a bit weird. I think explaining the use case (or is it indeed a build of a kernel? then, why?) might help to think about some good solution...

 

[elgrande]

Uhm, you will have no damn idea what went wrong if it doesn't complete successfully?

You'll even have a hard time to check whethere it did complete...

I might just touch() a path as mark at the end and check it at the beginning.

Sounds a bit weird. I think explaining the use case (or is it indeed a build of a kernel? then, why?) might help to think about some good solution...

I plan a "contrib trip" to https://ravynos.com/ implementing something like a launchd based logic that triggers the setup of https://github.com/dotnet/orleans, plans the start of pods and logs off again.

 

[ralphbsz]

Please don't say "is canceled". Copy and paste what happens.

THIS. We can not debug vague generalities.

I think explaining the use case (or is it indeed a build of a kernel? then, why?) might help to think about some good solution...

And THIS. Classic example of an XY problem.

On the other hand, we can try to explain how & and nohup work.

To begin with: (t)csh has its own (builtin) version of nohup. In a nutshell, the main job of nohup is: to start the program with the HUP signal set to ignore. The default action for the HUP signal is for the process to abort. The problem with this is that a program (such as make) is free to reset the HUP signal to anything it likes, for example explicitly to abort again. But I suspect that when make aborts (in response to a HUP signal, if it does that), it will print a diagnostic message on stdout or stderr. And this is one of the reasons why redirecting output to /dev/null is insane: It prevents you (and us) from debugging!

Another thing the standalone version of nohup does: it redirects stdout and stderr. I don't know whether the csh builtin does. I don't like (t)csh, and I don't like shell builtins in general (they tend to be simplified), so let me use the standalone one in /usr/bin/nohup. Whether stdout is redirected will come in with the next issue ...

"nohup make buildkernel & exit" also kills make() as seen by no make in ps -A

and why does "nohup make buildkernel > /dev/null & ; exit" keep make() alive

To begin with, you are only redirecting stdout to /dev/null. Error messages still have to go somewhere. If you really wanted to redirect them too, I would instead suggest "make ... 2>&1 > /tmp/make.log" (and please check that I got the order of the two redirects correct).

But what may be happening here is the following. When make starts without the redirect, its stdout is connected to a terminal. Since you are probably running this in a window (ssh or xterm or ...), that is probably a virtual terminal. When exit happens, the window closes, and the virtual terminal device is closed. The next time make tries to write to stdout, it finds out that writing is no longer possible (you can't print to a closed terminal window), and that causes it to exit.

So in reality, here is what I would do to be safe, if you really want to run make in the background:

/usr/bin/nohup make < /dev/null > /tmp/make.log 2> /tmp/make.errors &
exit


 

[elgrande]

THIS. We can not debug vague generalities.


And THIS. Classic example of an XY problem.

On the other hand, we can try to explain how & and nohup work.

To begin with: (t)csh has its own (builtin) version of nohup. In a nutshell, the big task nohup does is to start the program with the HUP signal set to ignore. The default action for HUP is for the process to abort. The problem with this is that a program (such as make) is free to reset the HUP signal to anything it likes, for example explicitly to abort again. I suspect that when make aborts in response to a HUP signal (if it does that), it will print a diagnostic message on stdout or stderr. And this is one of the reasons why redirecting output to /dev/null is insane: It prevents you (and us) from debugging!

Another thing the standalone version of nohup does: it redirects stdout and stderr. I don't know whether the csh builtin does. I don't like (t)csh, and I don't like shell builtins in general (they tend to be simplified), so let me use the standalone one in /usr/bin/nohup. Whether stdout is redirected will come in ...


To begin with, you are only redirecting stdout to /dev/null. Error messages still have to go somewhere. If you really wanted to redirect them too, I would instead suggest "make ... 2>&1 > /tmp/make.log" (and please check that I got the order of the two redirects correct).

But what may be happening here is the following. When make starts without the redirect, its stdout is connected to a terminal. Since you are probably running this in a window (ssh or xterm or ...), that is probably a virtual terminal. When exit happens, the window closes, and the virtual terminal device is closed. The next time make tries to write to stdout, it finds out that writing is no longer possible (you can't print to a closed terminal window), and that causes it to exit.

So in reality, here is what I would do to be safe, if you really want to run make in the background:

/usr/bin/nohup make < /dev/null > /tmp/make.log 2> /tmp/make.errors &
exit


Wow I read that tomorrow ty.

 

[elgrande]

THIS. We can not debug vague generalities.

Case 1:

logon via ssh

cd / && git clone https://git.freebsd.org/src.git && echo $?

in case last line is returncode '0' all was successful due to logical &&.

Then:

make buildkernel > /tmp/buildlog & ; exit

leads to closing the ssh session as expected.

logon again via ssh

tail -f /tmp/buildlog

shows the build is running


Case 2:

logon via ssh
remove /src.

cd / && git clone https://git.freebsd.org/src.git && echo $?

in case last line is returncode '0' all was successful due to logical &&.

Then:

make buildkernel & ; exit

leads to closing the ssh session.
logon again via ssh

ps -Af

shows the no make() process is running.

And THIS. Classic example of an XY problem.

yes it indeed is a kernel build.




PS: FYI in shells/fish ai shell both variants unfortunately do not work.

 

[zirias@]

FYI in shells/fish ai shell both variants unfortunately do not work.

From what I understood so far, you want to contribute to some OS.

Then, the very first step would be stop using non-standard shells, use a POSIX/bourne shell, which should be available as /bin/sh on almost any POSIX-compliant system.

That said, I didn't fully understand what you want to do, but I have some doubts it's indeed a job for "launchd" (or any other init/rc system)....

 

[elgrande]

From what I understood so far, you want to contribute to some OS.

Primarily I would still love to contribute to FreeBSD only as I did sporadically in the last ~20 years.