Hot answers tagged

7

With zsh: pids=() trap ' trap - CHLD (($#pids)) && kill $pids 2> /dev/null ' CHLD sleep 2 & pids+=$! sleep 1 & pids+=$! sleep 3 & pids+=$! wait (here using sleep as test commands). With bash it would seem the CHLD trap is only run when the m option is on. You don't want to start your jobs under that option though as that ...


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 ...


6

You can access the return code of the last command executed with the special parameter $?. There is no documented standard (at least none that are widely adopted) for return codes other than "0" being success and non-zero being a failure. You will have to check the manpage of the specific command that you are running.


6

kill -STOP $PID [...] kill -CONT $PID


5

A port is considered "in use" whenever there are any sockets bound to it. They don't have to be in LISTEN state, just bound. Therefore the TIME_WAIT sockets that you see do count. It gets a little bit more complicated if any sockets are bound to addresses and ports. Different sockets are allowed to be bound to the same port if they're bound to different ...


5

The definition of sleep(3) allows for the call to return before, at, or after the time specified: DESCRIPTION sleep() makes the calling thread sleep until seconds seconds have elapsed or a signal arrives which is not ignored. So we have these possible scenarios The call is interrupted with an uncaught signal. sleep() returns immediately and ...


4

First, process creation is rarely a useful event to log and it's irrelevant for security (except for resource limiting). I think you mean to hook the execution of programs, which is done by execve, not fork. Second, the use cases you cite are usually best served by using existing mechanism made for that purpose, rather than rolling your own. For logging, ...


3

pgrep is not able to filter a process based on its state. Try: ps axo pid,stat | awk '$2 ~ /^Z/ { print $1 }'


2

A list of non-zero CPU % processes: ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm --sort=+pcpu | awk '$8!=0.0 {print}' | awk 'NR>1' To count them ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm --sort=+pcpu | awk '$8!=0.0 {print}' | awk 'NR>1' | wc -l To see this continuously updated, but them in a file called ...


2

I don't know why changing the kernel name would have made a difference (perhaps sd*1 runs after sd* allowing a bit more time for work to get done?), but udev doesn't like long-running actions in events: Starting daemons or other long running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed ...


2

As the process is a child of the shell you opened over ssh, this process will be terminated as soon as you log out of the shell, e.g. by disconnecting. You can use different methods to work around this: Start the program with nohup (no hang up) and disown it: nohup somecommand & disown %1 This will redirect all ouput to a file $PWD/nohup.out, if ...


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 ...


2

The short answer is no: once an application has allocated memory, and used it, it "belongs" to that application, and unless that application releases it nothing else can reclaim it. (This isn't as simple as a call to free() though since that just returns memory to the individual application's pool, not to the system.) Swap is supposed to help with this: ...


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 ...


2

You can get a lot of internal information about processes, the scheduler, and other components of the OS and the hardware by using cat /proc/... where ... can be many things. For instance, it could be a process ID, followed by a lot of specific information request, or scheduler debug information request, for example: cat /proc/sched_debug To see the ...


2

The ps command is a good place to start. It allows you to specify what information to display for a set of selected processes (possibly all processes). You can read the man page for detailed information on the available information you can get, which are specified as flags to the -O option. The following is a start for what you might want: ps -O "%mem ...


2

POSIX guarantees you that a successful, uninterrupted sleep will sleep at for least as long as you request: http://pubs.opengroup.org/onlinepubs/009604599/functions/sleep.html On Linux, it may take longer due to 1) rounding 2) waiting on the scheduler to put the process/thread on the CPU 3) time spent in a stopped state: ...


2

Process handles are a Windows concept so as far a Unix and Linux are concerned, there is nothing to close in the first place. The parent process must however properly get the process exit status with waitpid or wait. When a process has stopped, i.e. is suspended but has not exited, it can be resumed and you can find a lot of information about it. When it ...


2

If you need in depth scheduling info, you could use one of these tools - perf SystemTap dtrace (I dont know what the state of the linux port is) sysdig All of these can tap into kernel hooks to display events such as context switches, interrupts, I/O, system calls etc.


2

You can use pgrep with the -x flag: kill -9 $(pgrep -x P1) or better, with pkill you can do this: pkill -9 -x P1 with BSD pkill: pkill 9 -x P1


2

You could try with pgrep: pgrep -o chromium The -o flag will only print the oldest (least recently started) of the matching processes. If all your chromium instances are child processes of that parent process with pid 6167, then this must be the oldest chromium-browser process, therefore pgrep -o should print that pid. Tested with an apache instance: ...


2

If you're looking for the top level chromium process, it could be the one with parent process id of 1 (init), try using pgrep -P1 chromium to find its PID. You may wish to try using ps ef to see processes listed in a tree like structure to find a parent. Note: ps switches are ef and not -ef.


2

//fakeExec.c #include <unistd.h> #include <stdio.h> #include <sys/syscall.h> int execve(const char *path, char *const argv[], char *const envp[]) { printf("Execing \"%s\"\n", path); return syscall(SYS_execve, path, argv, envp); } In the terminal: $ gcc -fPIC -shared fakeExec.c -o fakeExec.so $ export LD_PRELOAD=$PWD/fakeExec.so ...


1

The sh utility is a command language interpreter that shall execute commands read from a command line string, the standard input, or a specified file. The application shall ensure that the commands to be executed are expressed in the language described in Shell Command Language ps displays the currently-running processes. This makes sense because we are ...


1

For a command you run from the shell, read the shell documentation on ulimit. There is a ulimit() function that does the same thing in C. There are also various limits you can apply via implementation-specific methods. In FreeBSD, you can set limits per user in login.conf, or using a command called rctl. Some Linux distros use a limits.conf. There is a ...


1

You can apparently follow a process using strace. If you know the PID of the process then you can do: strace -o strace-<pid>.out -f -p <pid> Notice the -f switch. It will help you to follow newly created processes that are descendants of the process whose PID was used in the command, above. For information on strace see this question.


1

The easiest way is to enable system call auditing See the following link for details´╝î http://serverfault.com/questions/199654/does-anyone-know-a-simple-way-to-monitor-root-process-spawn If you're monitoring all processes, just remove the -F uid=0 part Logs are written to /var/log/audit/audit.log


1

It could be CPU consumed within a kernel process, driver, or interrupts. This is not an answer, but one way to approach solving it. Some details to this approach are Linux-specific. Install sysstat aka sar package and modify or add a sar-collection crontab (on RedHat systems, /etc/cron.d/sysstat): * * * * * root /usr/lib64/sa/sa1 -L -F -S XALL 10 6 Be ...


1

In general, it probably won't have a bad effect. However, Linux by default allows overcommitting memory. That means that if a process asks for memory, Linux will say "sure". Then, if it actually runs out of memory (including swap space), Linux will start killing processes to free up memory. So, if your process allocates 117GB but does not use most of it, it ...



Only top voted, non community-wiki answers of a minimum length are eligible