New answers tagged

0

For those that just want to kill a process and wait for it to die, but not indefinitely: It waits max 60 seconds per signal type. Warning: This answer is in no way related to traping a kill signal and dispatching it. # close_app_sub GREP_STATEMENT SIGNAL DURATION_SEC # GREP_STATEMENT must not match itself! close_app_sub() { APP_PID=$(ps -x | grep "$1" ...


2

The time window even for an external 680uFx400V capacitor battery is very low for an average 100W desktop PC - just a half a second or so. With internal PSU caps it's even less. What are you really trying to achieve? Even if you will able to write a timestamp to a log file, you still need sync() cycle to happen or to do manual sync() call, and if you're ...


31

On Linux it depends on the file capabilities. Take the following simple mykill.c source: #include <stdio.h> #include <sys/types.h> #include <signal.h> #include <stdlib.h> void exit_usage(const char *prog) { printf("usage: %s -<signal> <pid>\n", prog); exit(1); } int main(int argc, char **argv) { ...


5

kill(2) man page explains: Linux Notes Across different kernel versions, Linux has enforced different rules for the permissions required for an unprivileged process to send a signal to another process. In kernels 1.0 to 1.2.2, a signal could be sent if the effective user ID of the sender matched that of the receiver, ...


-1

the signal would carry but the process owner belong to root. so, the other user don't have the right to terminate the process so you will receive permission error problem. terminate process is only possible when you own the ownership(proper rights) of the process.


21

Nothing: strace kill -HUP 1 [...] kill(1, SIGHUP) = -1 EPERM (Operation not permitted) [...]


18

I can't seem to find any information on this aside from "the CPU's MMU sends a signal" and "the kernel directs it to the offending program, terminating it". This is a bit of a garbled summary. The Unix signal mechanism is entirely different from the CPU-specific events that start the process. In general, when a bad address is accessed (or written to a ...


0

It may be that you are a victim of a well known bash problem that frequently hits make users. I did not yet check bash 4, but bash 3 incorrectly does jobcontrol inside scripts. This usually causes makefiles that contain a loop over several subdirectories not to be easily killable by ^C because the sub processes run in separate process groups even though ...


214

All modern CPUs have the capacity to interrupt the currently-executing machine instruction. They save enough state (usually, but not always, on the stack) to make it possible to resume execution later, as if nothing had happened (the interrupted instruction will be restarted from scratch, usually). Then they start executing an interrupt handler, which is ...


37

The shell does indeed have something to do with that message, and crsh indirectly calls a shell, which is probably bash. I wrote a small C program that always seg faults: #include <stdio.h> int main(int ac, char **av) { int *i = NULL; *i = 12; return 0; } When I run it from my default shell, zsh, I get this: 4 % ./segv ...


17

A segmentation fault is an access to a memory address that isn't allowed (not part of the process, or trying to write read-only data, or execute non-executable data, ...). This is caught by the MMU (Memory Management Unit, today part of the CPU), causing an interrupt. The interrupt is handled by the kernel, which sends a SIGSEGFAULT signal (see signal(2) for ...


2

To answer that question, you have to understand how signals are sent to a process and how a process exists in the kernel. Each process is represented as a task_struct inside the kernel (the definition is in the sched.h header file and beginns here). That struct holds information about the process; for instance the pid. The important information is in line ...


6

A zombie process is basically already dead. The only thing is that nobody has acknowledged its death yet so it continues occupying an entry in the process table as well as a control block (the structure the Linux kernel maintains for every thread in activity). Other resources like mandatory locks on files, shared memory segments, semaphores, etc. are ...


5

Ctrl+C (control character intr): It will send SIGINT signal to a process and usually application gets abort but the application can handle this signal. For example you can handle a signal with signal() function in C Language. Ctrl+Z (control character susp): It will send SIGTSTP signal to a process to put it in background and like SIGINT it can be handle. ...


2

In order to have a non-interactive job respond to SIGINT, you need to create a handler for SIGINT: $ ( (trap "echo Got SigInt" SIGINT; sleep 60) & ) & [1] 13619 $ [1]+ Done ( ( trap "echo Got SigInt" SIGINT; sleep 60 ) & ) $ ps -o pid,pgid,args PID PGID COMMAND 11972 11972 bash 13620 13619 bash 13621 13619 sleep 60 13622 ...


17

Take a look at the POSIX specification for the write() function: The write() function shall fail if: … An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread. So the sequence of events is: The head process exits. This causes all ...


26

It depends on the OS buffers and the timing between the 10th and 11th writes of dmesg. After head writes 10 lines, it terminates and dmesg will receive SIGPIPE signal if it continues writing to the pipe. Depending on your OS buffer, dmesg will often write more than 10 lines before head consumes them. To see that head had consumed more than 10 lines, you ...


3

head closes stdin after printing 10 lines. Then dmesg detects that the stdout is closed and exits. To be more precise, dmesg will receive the EPIPE error from the write call to stdout. From the dmesg.c source code here: https://github.com/karelzak/util-linux/blob/v2.27.1/sys-utils/dmesg.c#L654-L659 rc = fwrite(p, 1, len, out) != len; if (rc != 0) { if ...



Top 50 recent answers are included