If I run ./script.sh &, where script is the following:

#!/bin/bash
echo "hello"
sleep 30
echo "hello again"
sleep 30
touch /root/foo.txt

Then I use ps au, to identify the "sleep" call process id, which I subsequently terminate, via kill -HUP . The program then finishes still. Will the child "sleep" notify its parent? However, if I run echo "hello" && sleep 30 && echo "hello again" && sleep 30 && touch /root/testFILE.txt &, and repeat the process, the program does not finish. Why is this? It does in fact "touch" the file, if, during the last "sleep", I disconnect (as I am connected via ssh to an ec2 instance, running amazon linux 2, over ssh). The disconnect should send a HUP signal to the sleep command (I think), which should have the same results as in the above paragraph but, lo and behold, upon my return the file is there.... (note: if I manually, via kill -HUP , send the the hup signal during this last "sleep", the file isn't created either...) What is going on? Is there any chance it is related to it being an ec2 instance or is this solely explainable by the unix os?

I am surprised that at least from Bash 4.4.19, Interactive Bash runs commands in a separate session, see following process list after I run sleep 8888:

PGID    PID       PPID
3150071 3150071  252603     -bash
3194323 3194323 3150071       sleep 8888

You can see the PGID of sleep does not equal to the bash, while its PPID does. The test is done on Ubuntu Bionic. Is there any documentation about this behavior change? or it has been acting this way since the beginning? Running commands in a separate session means that the SIGHUP effects does not happen at all when bash exits, maybe this is why https://www.sobyte.net/post/2022-04/linux-nohup-setsid-disown/#about- says > In fact, on newer versions of bash, bash does not send SIGHUP commands to background programs. That means that any process running in the background ending with & will not be exited by the SIGHUP signal for terminal exit. EDIT: I should use the term "process group" instead of "session".

Scenario:

$ cat t0.txt
t1.txt

$ cat t1.txt
xxx

$ sed -n 1p t0.txt | xargs less
# OK

$ sed -n 1p t0.txt | xargs nano
Received SIGHUP or SIGTERM

dvl-linux64 $ nano --version
 GNU nano, version 2.5.3

How to open file in nano? If not xargs, then what? UPD. On Cywgin:

$ sed -n 1p t0.txt | xargs less
# OK

$ sed -n 1p t0.txt | xargs nano
Too many errors from stdin

$ sed -n 1p t0.txt | nano
Too many errors from stdin

Buffer written to nano.save

$ nano --version
 GNU nano, version 4.9

In a bash shell in a terminal emulator window of lxterminal, I run $ trap "echo hello" SIGHUP $ kill -s HUP $$ hello $ and then I close the terminal emulator window. Does closing the terminal emulator window only cause SIGHUP sent to the controlling process i.e. the bash process? Since the SIGHUP trap doesn't terminate the bash process, I expect the bash process isn't terminated, but why is the bash process actually terminated? Same thing happen if I change the trap to "" (ignore). Terminal emulator matters. In bash running in a xterm window, setting trap to "" will make a xterm window not closable, while setting trap to echo hello can still close a xterm window. Thanks.

The [Advanced Programming in the UNIX Environment](http://www.apuebook.com/) book ("APUE") says > Consider a process that forks a child and then terminates. Although this is nothing abnormal (it happens all the time), what happens if the child is stopped (using job control) when the parent terminates? How will the child ever be continued, and does the child know that it has been orphaned? > ... > If the process group is not orphaned, there is a chance that one of those parents in a different process group but in the same session will restart a stopped process in the process group that is not orphaned. > ... > Since the process group is orphaned when the parent terminates, and the process group contains a stopped process, POSIX.1 requires that every process in the newly orphaned process group be sent the hang-up signal (SIGHUP) followed by the continue signal (SIGCONT). If the concern is only that a stopped process won't have a chance to be waken up after its process group becomes orphaned, why doesn't the kernel just send SIGCONT when its process group becomes orphaned, and why need to send SIGHUP too?

I found only this question of this subject: https://unix.stackexchange.com/questions/283620/received-sighup-or-sigterm-nano-cannot-edit-empty-file I'm configuring my web server. There wasn't any problems earlier and I would like to know exactly what is causing this error? I've installed samba and php. I tried strace and auditd as adviced in earlier comment but this didn't open up this problem for me. @unity:/var/www/html $ sudo nano info.php Received SIGHUP or SIGTERM @unity:/var/www/html $ sudo rm index.html @unity:/var/www/html $ sudo nano info.php Received SIGHUP or SIGTERM

Bash manual says > If the huponexit shell option has been set with shopt (see Section 4.3.2 [The Shopt Builtin], page 62), Bash sends a SIGHUP to all jobs when an interactive login shell exits. Why does huponexit not work in the following? In one interactive shell $ shopt -s huponexit $ sleep 4321 & 13816 $ exit Then in the other shell $ ps -j 13816 PID PGID SID TTY STAT TIME COMMAND 13816 13816 13728 ? S 0:00 sleep 4321 Thanks.

APUE says > Since the process group is orphaned when the parent terminates, and the process group contains a stopped process, POSIX.1 requires that every process in the newly orphaned process group be sent the hang-up signal (SIGHUP) **followed by** the continue signal (SIGCONT). The kernel sends SIGCONT after SIGHUP, but the process is waken up by SIGCONT before acting on SIGHUP. So why doesn't the Linux kernel send SIGCONT before SIGHUP? Thanks. Related to but not answered by https://unix.stackexchange.com/questions/490792/does-the-default-action-of-sigcont-resume-the-execution-of-a-stopped-process-bef ------------ I did not answer my question.

In bash, when running ( sleep 123 &), the sleep 123 process will continue running, when the subshell exits. How can I stop the sleep 123 process before its parent subshell exits? I'm trying to see if the sleep 123 process will be terminated, because of receiving SIGHUP and SIGCONT. I am looking for an example for https://unix.stackexchange.com/questions/484344/is-sighup-sent-to-this-orphaned-process-and-why-doesnt-it-terminate and https://unix.stackexchange.com/questions/490494/does-sending-sighup-to-a-process-group-that-becomes-orphaned-and-contains-a-stop

In The Linux Programming Interface > To see why orphaned process groups are important, we need to view > things from the perspective of shell job control. Consider the > following scenario based on Figure 34-3: > > 1. Before the parent process exits, the child was stopped (perhaps because the parent sent it a stop signal). > > 2. When the parent process exits, the shell removes the parent’s process group from its list of jobs. The child is adopted by init and > becomes a background process for the terminal. The process group > containing the child is orphaned. > > 3. At this point, there is no process that monitors the state of the stopped child via wait(). > > Since the shell did not create the child process, it is not aware of > the child’s existence or that the child is part of the same process > group as the deceased parent. Furthermore, the init process checks > only for a terminated child, and then reaps the resulting zombie > process. Consequently, the stopped child might languish forever, since > no other process knows to send it a SIGCONT signal in order to cause > it to resume execution. > > Even if a stopped process in an orphaned process group has a > still-living parent in a different session, that parent is not > guaranteed to be able to send SIGCONT to the stopped child. A > process may send SIGCONT to any other process in the same session, > but if the child is in a different session, the normal rules for > sending signals apply (Section 20.5), so the parent may not be able to > send a signal to the child if the child is a privileged process that > has changed its credentials. > > To prevent scenarios such as the one described above, SUSv3 specifies > that **if** a process group becomes orphaned and has any stopped members, > **then** all members of the group are sent a SIGHUP signal, to inform > them that they have become disconnected from their session, followed > by a SIGCONT signal, to ensure that they resume execution. If the > orphaned process group doesn’t have any stopped members, no signals > are sent. The default action to SIGHUP is termination. So does kernel implicitly sending SIGHUP to a process group that becomes orphaned and contains a stopped process mean that - those processes in the group and without their own SIGHUP dispositions will be terminated? Will any stopped process in the group be first resumed by SIGCONT and terminated by SIGHUP? - to make the processes in the group survive, they need to have their own SIGHUP dispositions or ignore SIGHUP? Thanks.

In *The Linux Programming Interface*: > SIGHUP is generated when a process group becomes orphaned. In an interactive bash process, $ ( sleep 123 &) will first forks a subshell, and the subshell then forks to execute sleep 123 &. The subshell exits immediately without waiting sleep 123 to finish because of &. At that time, - is the sleep process orphaned? (I think yes, [Figure 34.3](https://books.google.com/books?id=2SAQAQAAQBAJ&lpg=PA726&ots=qRt089CDsy&dq=In%20Figure%2034-3%2C%20the%20process%20group%20containingthe%20child%20is%20orphaned%20because%20the%20child%20is%20in%20a%20process%20group%20on%20its%20own%20and%20its%20par-ent%20(init)%20is%20in%20a%20different%20session&pg=PA726#v=onepage&q&f=false)) - is SIGHUP sent to the sleep process because it becomes orphaned? (I guess it is, by the quote) - why doesn't the sleep process terminate because SIGHUP is sent to it? (I am not sure) Thanks. ---------- I also have similar question when create a daemon process by first forking a child process and then the child process forking a grandchild and exiting immediately. The grandchild becomes orphaned and isn't SIGHUP sent to it, making it terminate?

nohup is an external program. How can it change the action of SIGHUP by a child process of a shell process to be "ignore"? (in terms of some arguments when the child process invokes fork() and/or execve() on the program which follows nohup?) Does nohup apply only to a child process of a shell process, but not to a child process of a non-shell process? Thanks.

When a terminal is disconnected, the OS kernel sends SIGHUP to the controlling process of the terminal. When a terminal emulator terminates, who sends SIGHUP to the controlling process of the pseudoterminal underlying the terminal emulator: the OS kernel or the terminal emulator? Thanks.

I see for syslog logging, kill -HUP is used. /var/log/cron /var/log/maillog /var/log/messages /var/log/secure /var/log/spooler { sharedscripts postrotate /bin/kill -HUP cat /var/run/syslogd.pid 2> /dev/null 2> /dev/null || true endscript } I understood that -HUP is used because daemons like syslog, when they catch the SIGHUP, will try to restart itself and thus all the openfiles will be refreshed. I do not understand why they need to be refreshed. If syslog does only appending new log to the log files, the open files would be in write mode. If that is the case, when the log switching happens and at some point when the old log file entry in the filesystem is removed, won't it be creating a new file automatically when it needs to append a new log line (as afterall syslog service is running as root)? I think the difference is more in the understanding of w and u modes. I am unable to come to a quick conclusion on it. Also, why use only kill -HUP, why not restarting the service. Will there be any difference?

I have this bash script: https://gist.github.com/ORESoftware/06dbb26a48d2ddf48a5a2166834e0836 when I call ql_acquire_lock in a shell, if I can call mkdir on a directory, then I acquire that lock. When I call ql_release_lock, it removes that directory, simple stuff. Now, when ql_acquire_lock is called, it calls: trap ql_on_trap EXIT trap ql_on_trap SIGHUP trap ql_on_trap 0 if any of those signals are received, in theory, then ql_release_lock will get called: the **problem I have** is when I close a terminal window, my script does NOT capture the SIGHUP or 0 signal. When the user issues SIGINT, my trap is invoked, most certainly by EXIT. But when the user closes the terminal window (I believe that should send a SIGHUP) my script's trap does not capture the signal. Anyone know why that would be?