According to BASH manual page, > When Bash receives a SIGINT, it breaks out of any executing loops. In > all cases, Bash ignores SIGQUIT. So if there was a shell script, started from bash shell, to which a SIGINT or SIGQUIT is sent via the following commands, they have no effect on the script. The script still keeps on running. $ /usr/bin/kill --verbose --signal SIGQUIT > sending signal 3 to pid > $ /usr/bin/kill --verbose --signal SIGINT > sending signal 2 to pid > So how can a SIGQUIT or SIGINT be sent from a bash interactive shell to a shell script that has been started by another bash shell? However if application or script is started from **systemd-user** then it receives both the signals SIGQUIT and SIGINT. SIGQUIT has the benefit of creating a core dump when the script or application exits.

As far as I understand, once a TCP connection is established, there's no actual flow of data unless one of the two ends actually sends a message, they are both blocked on a call to receive a message. As in, it's not like either end is sending periodic messages to the other one saying "just to let you know, I'm still alive". If that's the case, then I would expect that if either end of the communication channel was _abruptly_ shut down (e.g. kill -KILL it, but also just unplug the power cable of the whole machine), then the other end would not know. Going to a concrete example, I can establish a connection between two terminals via socat: - listen from one terminal and take note of the PID

$ socat -d4 TCP-LISTEN:12345 -
    $ # ctrl-z
    $ jobs -l
    + 958602 Stopped                 socat -d4 TCP-LISTEN:12345 -
    $ fg

- connect from the other terminal and take note of that PID too

$ socat -d4 TCP-CONNECT:localhost:12345 -
    $ # ctrl-z
    $ jobs -l
    + 958730 Stopped                 socat -d4 TCP-CONNECT:localhost:12345 -
    $ fg

(Both socat commands spit out quite a bit of output because of the -d4 debug messages.) Now, if I open a third terminal end issue

$ kill -KILL 958730

I see Killed being printed in the _second_ terminal, with no more debug lines from socat than those that were printed before, but in the _first_ terminal I do see more output:

2025/02/10 18:04:42 socat D select -> (, 0x0, 0x0, 0x0, NULL/0.000000), 1
2025/02/10 18:04:42 socat D read(122, 0x61dbb1b48000, 8192)
2025/02/10 18:04:42 socat D read -> 0
2025/02/10 18:04:42 socat N socket 1 (fd 122) is at EOF
2025/02/10 18:04:42 socat D data loop: sock1->eof=3, sock2->eof=0, closing=1, wasaction=1, total_to={0.1000000}
2025/02/10 18:04:42 socat D select(1, &0x1, &0x0, &0x0, &0.500000)
2025/02/10 18:04:43 socat D select -> (, 0x0, 0x0, 0x0, &0.000000), 0
2025/02/10 18:04:43 socat I poll timed out (no data within 0.500000 seconds)
2025/02/10 18:04:43 socat I shutdown(122, 2)
2025/02/10 18:04:43 socat D shutdown()  -> 0
2025/02/10 18:04:43 socat D tcsetattr(0, 0, {00006506,00000005,000000bf,00008a3b, 15,15, 03,1c,7f,15,04,00,01,00,11,13,1a,00,12,0f,17,16,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00})
2025/02/10 18:04:43 socat D tcsetattr() -> 0
2025/02/10 18:04:43 socat D tcsetattr(1, 0, {00006506,00000005,000000bf,00008a3b, 15,15, 03,1c,7f,15,04,00,01,00,11,13,1a,00,12,0f,17,16,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00})
2025/02/10 18:04:43 socat D tcsetattr() -> 0
2025/02/10 18:04:43 socat N exiting with status 0
2025/02/10 18:04:43 socat D exit(0)
2025/02/10 18:04:43 socat D starting xioexit()
2025/02/10 18:04:43 socat D finished xioexit()

But I don't understand, if [SIGKILL can't be caught/handled in user code because it's handled directly by the kernel](https://stackoverflow.com/a/35570675/5825294) , then 958730 should have no chance of doing anything like sending a message to say "sorry, I'm dying", and therefore 958602 should never know about it. Where's the flaw in my reasoning?

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?

I am executing and killing a process as follows:

python some_script.py &; pid=$!; sleep 5; kill -9 $!; ps -o pid,sid,uid,state,start,command

In other words: I execute a script in the background, record its process id, sleep 5 seconds, terminate it with a SIGKILL, and finally display the list of processes. The script itself is quite memory intensive. Its source code is included at the end of the question. The output of ps is

PID    SID      UID S  STARTED COMMAND
 72014  73317 22563342 R 20:56:36 [python]

This is followed by confirmation that the process was successfully killed:

+ killed     python some_script.py

My question: **why is the Python process displayed with brackets around its name in ps?** According to [this answer](https://unix.stackexchange.com/questions/22121/what-do-the-brackets-around-processes-mean) , square brackets indicate that the process's arguments are unavailable. Usually because the process in question is a kernel process, although clearly that isn't the case here. One possibility that I can think of is that the process's memory has been wiped, including its stack, which contains the list of arguments. But if the process's memory is being wiped by the kernel, shouldn't its state be DYING or ZOMBIE instead of RUNNING? --- Source code for some_script.py: ```[python] import asyncio async def create_tasks(n_tasks): tasks = [task() for _ in range(n_tasks)] await asyncio.gather(*tasks) async def task(): await asyncio.sleep(10) if __name__ == "__main__": asyncio.run(create_tasks(1000000))

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?

My process **a.out** is starting by a timeout command similar to:

1 ./a.out - 
It runs on a server and I  have  no control over that because it is part of a shell script that being invoked by the server automatically. 

Is there any possibility or solution that I can implement so that a.out won't get killed until it finishes? 

 - I already mapped signal 15 (SIGTERM) by SIG_IGN macro, so it runs about 5s instead of 1s.
 - If I send SIGKILL to

timeout``` then both gets killed. - Sending SIGSTOP and SIGHUP to timeout seems to have no effect. I searched a lot regarding this matter, but all questions and texts seems to be on timeout usage. Is there anything else I can do? like another signal, forking, preventing timeout to get time correctly, blocking signals, doing something in inline assembly, anything at all? Thank you.

I am trying to overwrite or change the Signals of a process. As I guess there is a table of signals in every process separately. Is there anything like that in the /proc folder? Thank you for your time.

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 ?

So, my situation is this: I have created a launcher, key bindings and an alias that opens GLava and CMus in a drop-down terminal at the same time, using this shell script: #!/bin/bash c=$(ps -e | grep -c xfce4-terminal) if [ $c -gt 0 ] then xfce4-terminal --tab --drop-down -x cmus | glava --desktop & $1 else xfce4-terminal --drop-down -x cmus | glava --desktop & $1 fi It is perfect and glorious, but for one small problem. I'd very much like for both programs to also CLOSE at the same time. Is there a way to have one programs' termination trigger another? Specifically, if I have CMus and GLava open, I'd like to be able to close CMus (say, by simply pressing 'q' and quitting CMus or by closing the terminal, or killing the program, OR a special key binding, etc.) and have GLava immediately close/terminate as well. As it stands, I have a separate key binding to pkill GLava after I've closed CMus, which works fine, I suppose, but is certainly a little clunkier than I'd like. Maybe there's a way for GLava to only get triggered if CMus is running, a sort of whitelist maybe? A simple shell that closes both programs that I can bind? Or another thought perhaps? I'm open to any suggestions, being the noob that I am. Any help is much appreciated.

What are differences for running program between sudden cutting of power and SIGKILL? We have microservices that use database. I am tasked with creating automatic test that simulates sudden power off (not nice shutdown but unplugging from power without UPS). Intent is that after powering back we want to verify that database is still consistent etc. I plan to simulate it using killall -9 microservice_name. How good is this simulation? Is doing one or the other more destructive? I am especially worried about flushing (or not) file buffers, but maybe there are other differences? Bonus question: what when we compare with not actual power, but sudden kill of virtual machine?

I scanned using ClamAV and found these files: [root@ip-172-31-23-37 ~]# sudo clamscan --infected --recursive --exclude-dir="^/sys" / /tmp/.X25-unix/dota3.tar.gz: Multios.Coinminer.Miner-6781728-2 FOUND /tmp/.X25-unix/.rsync/a/kswapd0: Multios.Coinminer.Miner-6781728-2 FOUND I already deleted these files and also the parent folder but the process still running: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31107 root 20 0 1304592 1.1g 6960 R 98.0 31.2 44:22.94 clamscan 2474 root 20 0 714000 267428 2896 S 50.0 7.0 0:09.11 kswapd0 28253 1008 20 0 712144 264716 0 S 50.0 7.0 2290:36 kswapd0 Tried to kill its: [root@ip-172-31-23-37 /]# ll /proc/2474/exe lrwxrwxrwx 1 root root 0 Dec 10 16:36 /proc/2474/exe -> /tmp/.X25-unix/.rsync/a/kswapd0 (deleted) [root@ip-172-31-23-37 /]# killall kswapd0 [root@ip-172-31-23-37 /]# pidof kswapd0 432 [root@ip-172-31-23-37 /]# kill 432 [root@ip-172-31-23-37 /]# kill -9 432 [root@ip-172-31-23-37 /]# pidof kswapd0 432 [root@ip-172-31-23-37 /]# ll /proc/432/exe ls: cannot read symbolic link /proc/432/exe: No such file or directory lrwxrwxrwx 1 root root 0 Dec 10 16:37 /proc/432/exe [root@ip-172-31-23-37 /]# killall kswapd0 [root@ip-172-31-23-37 /]# killall kswapd0 [root@ip-172-31-23-37 /]# killall -9 kswapd0 [root@ip-172-31-23-37 /]# killall -9 kswapd0 The process still exist even killed so many times. How to force kill that and prevent back/running again?

I can not kill irq/${nnn}-nvidia by kill -9 or pkill -f -9. Does anyone how to kill or stop those process?  (I am using Ubuntu 16.04, if that is relevant.)

After entering su when I prompted to enter a password: user@debian:~$ su Password: I can't send SIGSTOP (ctrl+Z) from my keyboard (the same terminal) - nothing happens. So the only way to exit is to type some (right or wrong) password. Why can't I suspend su such a way? UPD: It seems that ctrl+Z is queued. Thus when sending ctrl+Z - nothing happens, but then after typing Enter signal arrives and su becomes stopped. Still can't understand such behavior. Is this standard behavior for all Unix-like or just Linux?

When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really. So, what's happening during those minutes?

Terminator allows custom layouts with a command such as bash -lc 'npm start'; bash However, triggering SIGKILL (CONTROL-C) will kill part of the terminal and mess up your layout. SIGQUIT works but that's hard to remember. Is there a way to have a layout with a bash command that drops into a bash interactive terminal after SIGKILL, instead of having to use SIGQUIT?

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.

I know that a process cannot prevent SIGKILL. But is there an external way to temporarily prevent SIGKILL to reach a (specific) process? (something like dropping packets by firewalls).

I run a Sheevaplug (small ARM server) with Debian 9. It does not have any third-party repos enabled in sources.list / sources.list.d. I have a backup script which runs as root, and uses at. I think something broke on Sep 13, because I am getting these emails that look like they come from at. They are daily, like my backups. The body of the message just says Killed. I can't think what would be sending SIGKILL to my process! Without gathering any more information than I have now, can you think of *any* reason this would happen? It can't be from the OOM killer (Out of Memory condition), because I have a full kernel log in dmesg which does not show any OOM messages. The at job is #!/bin/sh # at uses sh shell set -e cd /d/backup/jenkins-desktop/ for i in */; do nice ionice -c 3 rdiff-backup "$i" ../jenkins-desktop.rdiff/"$i" done I doubt it's systemd SystemCallFilter=, and that would send SIGSYS by default. I see that a couple of rlimits send SIGKILL. But I'm not doing anything to set rlimits myself; also it looks like in both cases you would be killed by SIGXCPU first, which defaults to fatal and should show "CPU time limit exceeded". I have looked in journalctl --since=-2d -p notice and there are no errors, only some success messages from anacron. --- Return-path: Envelope-to: root@brick Delivery-date: Thu, 13 Sep 2018 02:14:15 +0100 Received: from root by brick with local (Exim 4.89) (envelope-from ) id 1g0GD0-0000Xr-Bz for root@brick; Thu, 13 Sep 2018 02:14:14 +0100 Subject: Output from your job 1843 To: root@brick Message-Id: From: root Date: Thu, 13 Sep 2018 02:14:14 +0100 X-IMAPbase: 1541805998 113 Status: O X-UID: 1 Killed

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?