I am on Ubuntu 16.04.5 LTS (AWS) I am creating a python process via this command: nohup python -u main.py > nohup.out 2>&1 & I would like to send a ctrl-c/SIGINT to the process, so I send kill -2 . When I start the process from my terminal, this works fine, the program receives the keyboard interrupt and closes gracefully. When I start the process via a .sh script or via another bash process (e.g. bash -c 'nohup python -u main.py > nohup.out 2>&1 &'). (I believe both methods start the process in the same way), the process does not receive the SIGINT when I send it. SIGTERM (default kill) works normally and closes the process, but does not let the process close gracefully, but I need. What's happening?

I moved code to a new virtual server running Ubuntu 22. I have the following (edited to make names shorter) in my crontab so that it runs **myCommand** only if it is not already running:

*/1 * * * * cusack flock -x -n ~myLock myCommand >> ~my.log 2>&1

When it runs, it puts

: SIGINT: bad trap

in my logfile. It did not do this on the old server. Am I doing something wrong? My goal is, as alluded to above, to just have one copy of myCommand running at a time. If it is still running from the last time, it should do nothing. Other posts led me to believe that this was a proper way to do this, and it worked on my old server. So why does it give me this error message? I tried adding a "-E 0" thinking that a 0 might mean everything is OK as it does in some contexts, but that didn't work. I added "-x", which didn't work and shouldn't change anything since according to the documentation it is the default anyway.

I'm struggling with not working CTRL+C in a certain environment shell command line (CentOS 7 / Vagrant guest of Windows host). I use bash there. The OS, seem, does not matter. Example run sleep 1000 and press the ctrl-c:

$ sleep 1000
^C^C^C

So, it's typing ^C and that's it. ^C is bound for the interruption.

$ stty -a
intr = ^C; ...

How to *make* it work? In the following post, where I was inspired to fix it, the answer explains a lot but does not give a simple answer on how to make it work.
https://unix.stackexchange.com/questions/92562/why-didnt-ctrl-c-work
It seems it's a simple thing that I'm struggling with.

In the below one-liner, I run an "infinite" while loop which prints some numbers:

$ bash -c 'trap stopit SIGINT; run=1; stopit() { run=0; }; while [ $run ]; do for i in {0..4}; do v=$(($i*50)); d=$(for ((k=0;k<=(5+$i);k++)); do echo -n $(($v*(($k+$i)%2))),; done); d=${d%?}; c=$(echo numbers $d); echo $c; sleep 0.1; done; done ; echo Done'
numbers 0,0,0,0,0,0
numbers 50,0,50,0,50,0,50
numbers 0,100,0,100,0,100,0,100
numbers 150,0,150,0,150,0,150,0,150
numbers 0,200,0,200,0,200,0,200,0,200
numbers 0,0,0,0,0,0
numbers 50,0,50,0,50,0,50
numbers 0,100,0,100,0,100,0,100
...

... and the "expanded" script is:

trap stopit SIGINT; 
run=1; 
stopit() { 
  run=0; 
}; 
while [ $run ]; do 
  for i in {0..4}; do 
    v=$(($i*50)); 
    d=$(for ((k=0;k<=(5+$i);k++)); do echo -n $(($v*(($k+$i)%2))),; done); 
    d=${d%?}; # cut final comma
    c=$(echo numbers $d); 
    echo $c; 
    sleep 0.1; 
  done; 
done ; 
echo Done

The idea is that the while loop runs "forever" and prints (running task), and once you get bored, you stop it by pressing Ctrl-C. However, what I want, is to print a message *after* Ctrl-C has interrupted the while loop - in the above example, that is the echo Done command. In the above example, I hoped that Ctrl-C would set the run variable to 0, thereby making the loop exit "cleanly" which would then print the command and exit. Unfortunately, when I press Ctrl-C nothing happens, that is, loop keeps on going and then I have to explcitly kill it. How can I make the above script/one-liner exit the while loop on Ctrl-C, and print the final message?

I have an interactive C program that reads a phrase from the terminal, and computes a series of anagrams. I also have a Perl program that reads and buffers lines from STDIN until receiving a reserved "end of input" token, sorts the lines, organizes them into columns and sends them to STDOUT. The C program uses the BSD/MacOS popen() to start the Perl program with a single bi-directional pipe, and fprintf()'s the anagrams on the pipe until it's generated all the anagrams; sends the "end of input" token, and then issues getline()'s on the pipe to read back and print the formatted results. It works fine normally. But I added a SIGINT handler to the C program so I could interrupt a long-running anagram, print whatever results it had thus far, and loop around for more terminal input. The handler sets a flag that the main program checks after writing to the pipe. If it's set, it breaks out of the anagramming loop and proceeds as if the loop had ended naturally: it sends the end-of-input string, and reads back the formatted results. It breaks out okay; the fprintf end-of-input gets a normal return code; but the first getline returns a null pointer indicating EOF, so I don't get any partial results. The C program continues normally, as intended. I don't find anything in the docs to indicate that a handled SIGINT affects any open pipes, but I can't think what else would be preventing me from receiving anything from the Perl program.

I know the recommendable way to **terminate** a foreground process is through the SIGTERM signal, it because it gives the opportunity to the process itself to clean/release resources. This signal only can be generated/send through a command, it through any of the kill pkill killall commands - until here I am ok. Furthermore it is the **default** signal for these commands. Now, I know the SIGINT signal **interrupts** a process. Therefore "similar" as _terminate_. But I read the following answer (extract) from: * [How does SIGINT relate to the other termination signals such as SIGTERM, SIGQUIT and SIGKILL?](https://stackoverflow.com/a/4047975/3665178) >SIGINT and SIGQUIT are intended **specifically** for _requests from the terminal_: particular input characters can be assigned to generate these signals (depending on the terminal control settings). The default action for SIGINT is the same sort of process termination as the default action for SIGTERM and the unchangeable action for SIGKILL; Until here according with the answer SIGINT is triggered by keys combination (ctrl + c) **and** _theoretically_ SIGINT does the same than SIGTERM, it about to: _give the program itself the opportunity to clean/release resources_. To be honest after to read many tutorials, I couldn't find and confirm that information explicitly. It for example from: * [signal(7) — Linux manual page](https://www.man7.org/linux/man-pages/man7/signal.7.html) * [24.2.2 Termination Signals](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) In many places for these signals are used the _interrupts_ and _terminates_ terms. Furthermore, from the same answer exists the _@Jonathan Leffler_'s [comment](https://stackoverflow.com/questions/4042201/how-does-sigint-relate-to-the-other-termination-signals-such-as-sigterm-sigquit/4047975#comment4351902_4047975) (extract) as: >**This is the key point**: SIGINT and SIGQUIT can be generated from the terminal using single characters, while the program is running. The other signals have to be generated by another program, somehow (eg by the kill command). SIGINT is less violent than SIGQUIT; the latter produces a _core dump_ Until here as a possible conclusion: SIGINT can be triggered through either key combinations or command and SIGTERM only by command. Reason of this post: If _theoretically_ SIGINT does the same than SIGTERM **Question** * When is mandatory send SIGINT programmatically? It appears in kill -l, so can be use it. **Extra Questions** Again, if _theoretically_ SIGINT does the same than SIGTERM - and both can be ignored/blocked/handled * Why was created SIGINT? * Why ctrl + c was not assigned from the beginning to SIGTERM? To be honest I assumed that SIGINT is **not** safe because it _interrupts_ the process and therefore would leave some data in a not consistent/integral state

When I run sleep manually, and then kill -INT it, sleep exits immediately. For example: $ /bin/sleep 60 & 4002356 $ kill -INT 4002356 + Interrupt /bin/sleep 60 $ ps -C sleep PID TTY TIME CMD $ However, when I do the same thing in a shell script, sleep ignores the SIGINT. For example: set -o xtrace echo /bin/sleep 10 & child="$!" /bin/sleep 0.1 ps -C sleep kill -TERM "$child" # SIGTERM /bin/sleep 0.1 ps -C sleep wait "$child" # will return immediately echo /bin/sleep 10 & child="$!" /bin/sleep 0.1 ps -C sleep kill -INT "$child" # SIGINT /bin/sleep 0.1 ps -C sleep wait "$child" # will wait for 9.8 seconds Why/how does sleep ignore SIGINT when I run sleep inside a shell script? I get the same behavior with dash and bash. My kernel is Linux 5.4.0.

I have a program that ignores SIGINT but that I want to run in the foreground. I would like to find a way to force it to close on Ctrl-C. Is there any way to write a wrapper (that you'd call ./wrapper.sh my_program) that would force the misbehaving program to quit, potentially by detecting the ignored SIGINT and generating a SIGKILL? [This answer](https://stackoverflow.com/a/21660539/3404377) is the exact opposite of what I am looking for -- I would like to force a program that ignores a signal to quit on SIGINT.

I inherited an old PC-server (quad Pentium 4) that only had partitions for /, /boot and swap (RAID1 with 2 1T SATA disks), but needed to update the distro (from CentOS 6.9). I decided to create a new partition so that the one containing / could be formatted. But I forgot to add the -p flag to resize2fs and now it's silently staring back at me and I can't tell how much longer it could take (it's been at it for 50+ hours). Now, I know that shrinking a filesystem [can take a long time](https://serverfault.com/q/213693/426271) , but while I could wait for [100 hours](https://serverfault.com/q/436224/426271) , something like [800 hours is out of the question](https://bbs.archlinux.org/viewtopic.php?id=147563) . Here's what I'm thinking at the moment: - Go ahead with the Ctrl+C && e2fsck. - Mount the partition and manually delete 100G+ worth of data that serves us no purpose. - Start from the top with resize2fs -p ... But I haven't been able to find [consensus](https://www.spinics.net/lists/linux-ext4/msg51307.html) on just how [dangerous](https://serverfault.com/a/501623/426271) it is to send SIGINT to resize2fs. I do have an extra backup of the important information, but would still like to do this without corrupting the filesystem. And yes, I'm aware it might be faster to just install the distro from scratch and restore my backup. **Update**: I decided to interrupt it. And everything seems to be fine, but the question still stands. I'm still curious.

I am executing a bash script and I want to correctly terminate a command (by pressing CTRL+C) that I am launching inside the script. This is the script: trap ctrl_c SIGINT function ctrl_c() { PID = $! kill -s SIGINT -$PID wait $PID echo "mycommand stopped!" } mycommand directory -option | grep --line-buffered -A 'Hello|Bye' >> output But it doesn't stop mycommand.

We know that - aside from SIGKILL and SIGSTOP - a program can intercept IPC signals, and run its internal handler circumventing the operation of the default handler. I can think of at least one very good reasons for doing this with the SIGINT signal. + Namely implementing a signal handler that executes either a last ditch backup, saves a memory dump, or writes to log, before reverting to the default signal operation that terminates the process. I can also think of a good reason why a piece of malware might catch and block SIGINT: + Namely to extend the execution time of the process . For the majority of users,Ctrl+C is the go to keyboard shortcut for most terminal users and there are many that are unaware of Ctrl+Z (SIGTSTP which only stops the process, which remains among terminal jobs), not to mention Ctrl+\ , which sends the SIGQUIT and creates a core dump. + If Ctrl+C gets caught and blocked, such users will likely try to open another terminal window, and run something along the lines of:

ps aux | grep [process name]

get the process PID, and execute the SIGKILL with

kill -9 [$PID]

+ Similarly, users connecting to a terminal session on a remote machine, will attempt to make a second connection with a new terminal session, and go through a similar process/PID search in order to terminate the culprit. Obviously, this tactic might extend the process runtime by only a short period, but even extra 3 minutes of a file transferring process using a high bandwidth connection of 10MB/s will transfer almost 2 GB of additional data, so there is certainly some merit to it. However, recently I have noticed - perhaps only because I started paying attention to it - that there are programs that seemingly fall into another subset. - These programs, which are open-source and have packages maintained and examined closely enough that hiding a major piece of malware code seems highly unlikely. + They do not take control of keyboard input like vim and other text editors + They have internal handlers that catch SIGINT and ignore it completely. There is no eventual process termination and to the best of knowledge no last ditch critical tasks are attempted. **My question**: * Is there a possible reason why a process might choose to intercept but drop SIGINT completely for a legitimate purpose? * In other words, can there be a good reason (from a code or system standpoint) or situation when catch and ignore of SIGINT is more advantageous than its known default operation that would terminate the running process?

When running Jetbrains IDEs (such as PyCharm and Android Studio) through dmenu, I get the following warning: >The IDE ignores SIGINT: the "Stop" button in run configurations may not work. It then links this support page which says >...it's up to the user to change the way the IDE is launched so that the signal is not blocked (e.g. run from the terminal instead of the dmenu)` **Why does dmenu cause this behavior? Is there a setting or a workaround available?** --- After some testing to determine potential workarounds, I found I can run pycharm& in a terminal and close the terminal without issue or warning. However, if I make a script run.sh whose full contents are:

#!/bin/bash
pycharm&

When I run run.sh I get the SIGINT warning.

I learned from https://unix.stackexchange.com/a/230568/674 thatping will exit with 0 after receiving SIGINT, which allows a bash script containing a ping command to continue running instead of exiting. I have a script with similar behavior: #!/bin/bash while true; do sudo -S sleep 4; echo $? sudo -k; done When I run it, I type Ctrl-C when it asks me for password, and the script doesn't exit, but continue running. The only difference is that sudo upon receiving SIGINT exits with 1 not 0. So I wonder why the bash script doesn't exit but continue running? Thanks. $ ./test.sh [sudo] password for t: 1 [sudo] password for t: 1 [sudo] password for t: 1 ...

I have a perl script, which indirectly invokes mysql (to execute a long SQL script). I would like to disable Ctrl+C while that script is running, but somehow the signal still reaches mysql, which then says "Ctrl-C -- query killed. Continuing normally." (I believe that's from mysql) I have: * set the $SIG{INT} to 'IGNORE' -- indeed, the Perl script keeps running * set a process group on the Perl script -- indeed, ps -e -o uid,pid,ppid,pgid,command shows that mysql is in the same process group as my Perl script * mysql is invoked after both of those happened. Why would that signal still arrive at the mysql process, and how do I prevent that?

I have a "main" bash script that runs another bash script (23.sh). In the main script, I have a function that catches Ctrl+C operations and prompts for a password. If password is entered correctly, then it kills the main file. However, I have an issue: when the user enters Ctrl+C twice in quick succession, the script freezes up (see comments in script below). How do I deal with this? In essence, I would like the function ctrl_c() to be recursive so that when a user uses Ctrl+C when within the function, it still takes effect. I remember from a long time ago (some 10 years) that I was told that recursion in fuctions is a **bad idea!** Any solution? #!/bin/bash # This is the main file that runs data collection code 23.sh in an infinite loop function ctrl_c() { clear echo "** Trapped CTRL-C0" sleep 1s echo "'''''''''''''''''''''''''''''''''''''''" echo "Enter Admin password and click [ENTER]: " # When user enters ctrl+c in here the program freezes up read passPhrase if [ $passPhrase == "pass" ]; then echo "Password correct" for i in seq 1 5; do sleep 1 echo -n "." # pkill 23.sh # pkill main.sh done pkill main.sh else echo "Incorrect pass phrase. 'Service Selection' screen will in 5 seconds load" for i in seq 1 5; do sleep 1 echo -n "." done # ./23.sh fi } trap ctrl_c INT while : do ./23.sh done

I have a script that boots up a test environment using `docker-compose`. This script pipes the mixed stdout of many docker containers on stdout through less: # This is part of a larger script with some setup and teardown. $ docker-compose up --build | less +F -r `less shows an undesired behavior here: When hitting Ctrl+C, docker-compose receives it and shuts down itself. Desired behaviour is only to interrupt the following (+F) feature of less` (like it does when viewing e.g. a large log). **What I want to achieve in the optimal case: Interrupt the following with the first Ctrl+C and quit the whole test environment on the second Ctrl+C.** I've toyed a bit around and tried the following things: - Register a `trap 'do_exit' SIGINT that would implement the logic above. docker-compose` however still exited upon Ctrl+C. - Use `trap '' SIGINT to catch SIGNT totally. docker-compose` however still got the Ctrl+C out of thin air. *Another observation:* This works in `zsh: (trap '' SIGINT && docker-compose up --build | less +F -r)` (it does not react to SIGINT at all) The same line behaves differently in bash and is killed by SIGINT. Here is the full (buggy) script for reference: #!/usr/bin/env bash service_name=xxx for dir in ../1 ../2 ../3; do if [ ! -d "$dir" ]; then echo "docker compose requires $dir, please check $dir do exist in the same folder level" exit 0 fi done docker-compose up --build | less +F -r if [ ! $? -eq 0 ]; then echo "Couldn't start service or Control-C was pressed" echo "cleaning up" docker-compose down exit $? fi docker-compose rm --all --force Any solution or experiences with this? -- Edit: I've also tried the solutions here without any success: - https://unix.stackexchange.com/questions/197199/is-there-any-way-to-exit-less-follow-mode-without-stopping-other-processes-in - https://unix.stackexchange.com/questions/26826/follow-a-pipe-using-less/139295#139295

I'm aware that if I press esc followed by typing :q!, I can exit the vim editor, due to [this question](https://stackoverflow.com/questions/11828270/how-do-i-exit-the-vim-editor) . However, the standard convention is for programs to exit when ctrl + c is pressed, which sends a SIGINT to the currently running process. For example, top, tail -f, and ping all follow this convention. My question is this: _Why_ doesn't vim follow this well-established convention? Is there a historical reason, or is it something else? It seems to me that it would avoid a lot of confusion for new users if it followed this standard convention like everything else. _(While we're at it, why is it SIGINT and not SIGTERM in the first place?)_

I want to make a specific combination of keyboard keys in order to terminate a process e.x I want to terminate the process by pressin CTRL + C ^ 3 (pressing three times C: CTRL +CCC). So basically I want to replace CTRL + C with CTRL + CCC

In the interactive console, pressing ^C on zenity --info & fg closes the Zenity window. One can only use zenity --info & wait in a script. But ^C doesn't close the Zenity window in this case. Is there any way to make wait behave more like fg and make ^C work?

I have setup a simple script like the below: sshpass -p $password ssh -T $username@$ip_address -p 30007 $save_file.pcap sh tcpdump -i eth5.1 -s 0 -n -v -U -w - EOF sed -i '1d' $save_file.pcap The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly). The purpose of the sh and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file. The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file: drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes Got 665 And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL+C. The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine. This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed that I included here. I've tried to instead set things up like follows instead: tcpdump -i eth5.1 -s 0 -n -v -U -w - & read -n 1 -s; kill $! The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen. Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL+C in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?