I'm connecting from my computer to a HP UX B.11.31 system and am running some very lengthy there commands using nohup so I can go to sleep and do something else for a few days while they complete. Example of such a command:

nohup rsync --rsync-path=/usr/local/bin/rsync -e ssh /data/src usr@target:/data/ >> /data/log/sync.out 2>&1 &

Note: the Rsync command's target is a different HP UX server. It'll run and run, until my computer somehow gets disconnected from the HP UX system (it's connected through SSH over a VPN over my home connection, and disconnections seem to happen once a day). If this has happened, I can tail /data/log/sync.out and I'll find:

Killed by signal 1.
rsync error: unexplained error (code 255) at rsync.c(549) [sender=3.0.8]

Someone suggested putting the command in a shell script and running that with nohup instead. So I did that (with a shebang for #!/usr/bin/bash), and then ran the command as nohup ./auto_rsync.sh > /data/log/sync.out 2>&1 &. The same thing happened. The funny thing is that if I simply log out while the command is running by typing exit, the command will keep running. So why is only my disconnect sending SIGHUPs to a process running with nohup?

When a Unix-like system is shut down normally, e.g. using halt, shutdown, poweroff etc. or the GUI equivalents, it will try to exit all processes gracefully first by emitting a SIGTERM signal to them. After some time it will send SIGKILL to the programs which are still running. How long is that delay? How much time do programs have to exit gracefully? If this is different between systems, I'd like to know the specific default setting for Ubuntu server. EDIT: Is it Systemd's 90s of delay as described here ?

I have two hotkeys for interactively looking up and killing a process on Linux:

bindsym $mod+k exec --no-startup-id \
    "ps axo pid,cmd | sed 1d | dmenu -i -l 20 | awk '{print $1}' | xargs kill"
bindsym $mod+$sh+k exec --no-startup-id \
    "ps axo pid,cmd | sed 1d | dmenu -i -l 20 | awk '{print $1}' | xargs -s SIGSEGV kill"

The second hotkey is the "try-harder" version for unresponsive targets. What is the most appropriate signal to use here? It seems like an abuse of SIGSEGV since there is no underlying segmentation fault. signal(2) says > The signals SIGKILL and SIGSTOP cannot be caught or ignored but in my experience, it is very common for an unresponsive process to survive SIGKILL while dying to SIGSEGV. What is the "least wrong" way to mercilessly kill a process?

A new _logstash_ version I'm using can't stop, attempting to connect to _Elastic_ all the time, while it can't (an authentication trouble, I will resolve later). a sudo systemctl stop logstash.service isn't enough to stop it, so I've issued a sudo systemctl kill logstash.service. But it doesn't stop it neither. a sudo system status logstash.service displays:

lebihan@debian:~$ sudo systemctl kill logstash.service

lebihan@debian:~$ sudo systemctl status logstash.service
● logstash.service - logstash
     Loaded: loaded (/lib/systemd/system/logstash.service; disabled; preset: enabled)
     Active: deactivating (stop-sigterm) since Sun 2023-08-20 07:51:21 CEST; 1h 4min ago
   Main PID: 47926 (java)
      Tasks: 176 (limit: 76997)
     Memory: 1.6G
        CPU: 28min 605ms
     CGroup: /system.slice/logstash.service
             └─47926 /usr/share/logstash/jdk/bin/java -Xms1g -Xmx1g -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djruby.compile.invokedynamic=true -XX:+HeapDumpOnOutOfMemoryError -Djava.security.eg>

août 20 08:55:36 debian logstash: [2023-08-20T08:55:36,702][WARN ][logstash.outputs.elasticsearch][main] Attempted to resurrect connection to dead ES instance, but got an error {:url=>"http://l >
août 20 08:55:41 debian logstash: [2023-08-20T08:55:41,704][WARN ][logstash.outputs.elasticsearch][main] Attempted to resurrect connection to dead ES instance, but got an error {:url=>"http://l >
août 20 08:55:42 debian systemd: logstash.service: Sent signal SIGTERM to main process 47926 (java) on client request.
août 20 08:55:42 debian logstash: [2023-08-20T08:55:42,326][WARN ][logstash.runner          ] SIGTERM received. Shutting down.
août 20 08:55:46 debian logstash: [2023-08-20T08:55:46,706][WARN ][logstash.outputs.elasticsearch][main] Attempted to resurrect connection to dead ES instance, but got an error {:url=>"ht

Why isn't my systemctl kill sending a SIGKILL event, instead of a SIGTERM? And how do I send a SIGKILL to my service to force it to stop, with systemctl?

I'm starting a Java process using nohup and & (running it in the background). This process gets terminated frequently. There is no pattern on when it is getting terminated. From the application (java process) logs it was evident that it was receiving a SIGTERM signal. So I used strace to figure out the source of the SIGTERM signal and it turned out to be systems. Why would systemd try to kill a process that it does not manage? Strace Output

13:35:20.838755 futex(0x7f1ef1ae49d0, FUTEX_WAIT, 16917, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
22:17:17.211643 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
22:17:17.211876 futex(0x7f1ef0e9c720, FUTEX_WAKE_PRIVATE, 1) = 1
22:17:17.211974 rt_sigreturn({mask=[]}) = 202
22:17:17.212183 futex(0x7f1ef1ae49d0, FUTEX_WAIT, 16917, NULL) = ?
22:17:17.538874 +++ exited with 143 +++

I've already combed through DMESG and messages logs and there was nothing that points to why the process was killed. Edit: The java process is started by a user as a bash command. But the user login is controlled using pblocald which is a systemd unit.

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

As a follow up to this question, I am correct that (4) (quote below) is the farthest I can get ? > in my app (a .NET app which runs as a systemd daemon), intercept the kernel signal sent to the process upon running kill (perhaps calling sigaction) so to ignore the kill request. And that with the disclaimer of it being possible only for cases when the user calls kill either omitting the signal number or using a trappable signal (like the default SIGTERM). If the user calls kill with SIGKILL (-9) or any other non-trappable signal - this will also fall short. Is the assumption above accurate ?

I liked SensorSmith answer at Forward SIGTERM to child in Bash , but for my systemctl script, it resulted in a double SIGTERM, because systemctl sends SIGTERM to the parent bash instance AND the child I am running. The result was instant termination before my child could gracefully shut down. What's the proper way to handle SIGTERM in a bash script based service?

Here's what happens in Ubuntu (Linux ubuntu 5.3.0-53-generic #47~18.04.1-Ubuntu SMP Thu May 7 13:10:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux, *bash* 4.4.20(1)): In Terminal, open a window (let's call it "window_1") and type:

"echo something;" SIGTERM

then

$$

**9781** then

-TERM $$

as expected, **something** is printed in window_1 and the window stays open. Now open another "window_2" and type:

-TERM 9781

and window_1 is closed (no time to see whether **something** is printed). Do the same with SIGINT and everything works as expected. Do the same with SIGUSR1 and everything works as expected, but only after the Enter key is pressed. Also, in *macOS 10.13.6* everything works as expected (with SIGTERM, SIGINT and SIGUSR1). Is anybody able to explain this apparent anomaly? Thanks in advance.

I have a basic question which I need help with. We have a use-case where we want to spawn a process in a different session/process-group i.e. if the parent spawning the process gets a SIGTERM, the child doesn't get the signal (or get killed). Although we want to kill this process (and its children) the next time we have to spawn the same process. To achieve this goal, we want to keep track of the process-id. I won't prefer to store it on disk as that could cause an issue where the process-id is not saved and we fail to kill it the next time. What are the ways to achieve the following? 1. Launch a separate process which doesn't get SIGTERM when the parent receives it - I think exec can solve this problem. 2. Keep track of the process and kill it before re-launching it - I think we can launch the process with a name but that doesn't seem like a clean way as it overrides the actual name.

I have a problem regarding the find command: I use this line in a script to run around 300 servers and check if a file is present, returns 0 if the file is there and returns 1 if the file is not.

$(timeout 4s ssh -n $user@$servername "find / -name file.jar 2>/dev/null | egrep '.*'")

Where $user is the ssh user, $servername is the server name of the server i want to ssh onto and file.jar is the file i am looking for. i dont want the file. i only want to return 0 if it is found. the command works for this. This command works flawlessly on most servers but for others fails with the output:

Killed by signal 15.

Is there a way to alter the command to stop throwing SIGTERM on some servers or would i require a new command entirely?

there was a nice write up somewhere on here about... not using kill-9 all the time which is SIGKILL and explained the reasons for doing so, and then went on to explain an order in which one should proceed from least aggressive SIGTERM ending up eventually at SIGKILL or rebooting. **can someone post a link to that for me? i cannot find it** using kill -l to do a listing I receive as output on the terminal *this is kill dash lowecase L, and NOT dash numeral one* HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMAX-3 RTMAX-2 RTMAX-1 RTMAX *I spaced out the above for readability. This is from SLES 11.4 x86-64* Am I correct in assuming the order of which these signal names are printed from kill -l correspond to the number you provide the kill command, such that if I wanted the bad *KILL* I would do kill -9 and if I wanted the better choice of TERM that would be kill -15 ? - Is this the only way to find out these numbers on a given system? - Is there a better more universal way of verifying what signals are available on a given linux system {RHEL, SuSE, debian, ... some stripped down version of linux from *i don't know where* used on some piece of hardware}? - If I write code, where & how should one check something system level like this before assuming a signal is: first available, and then that kill -number corresponds to a specific signal? - is there a good source for learning about all these types of signals, and what should be expected to always be available, for a typical *Linux* operating sytem?

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

Reading Gilles' answer , > SIGHUP is about the same as SIGTERM in terms of harshness, but it has a specific role because it's automatically sent to applications running in a terminal when the user disconnects from that terminal (etymologically, because the user was connecting via a telephone line and the modem hung up). SIGHUP is often involuntary, unlike **SIGTERM which has to be sent explicitly**, so applications should try to save their state on a SIGHUP. Does "explicitly" in "SIGTERM which has to be sent explicitly" mean that SIGTERM must be sent initially by a process (instead of the kernel) via the process calling kill()? I was wondering if SIGKILL must be explicitly sent to a specified process? Can kernel implicitly send any of SIGKILL and SIGTERM to a process? When an OS is shut down, does the kernel send some signal(s) to running processes to terminate them? What signal(s) is it and does the kernel send it implicitly? Thanks.

The issue is when I try to log in the server using SSh , it's not responding and cannot be pinged. And when I go to the console and reboot the server, its stuck in the reboot process. How Can this issue be resolved.

I have a process, and when I issue ctrl+c in the terminal, it closes the terminal window completely, anybody know why that might be happening? This is how the process is now started: exec "$(dirname "$0")/suman-shell" # a it used to be started like so, and there was no problem: "./$(dirname "$0")/suman-shell" # b it does look like using exec is what is causing the terminal window to close, so why does a close the terminal window, but not b, after receiving a signal?