Tag Info

Hot answers tagged

9

Check this Wikipedia link on Exec function and this link on Starting a process with the exec() calls e – An array of pointers to environment variables is explicitly passed to the new process image. The "e" suffix versions pass an environment to the program. An environment is just that—a kind of "context" for the program to operate in. For example, ...


6

Because of how waitpid works. On a POSIX system, a signal (SIGCHLD) is delivered to a parent process when one of its child processes dies. At a high level, all waitpid is doing is blocking until a SIGCHLD signal is delivered for the process (or one of the processes) specified. You can't wait on arbitrary processes, because the SIGCHLD signal would never ...


4

Processes in state D (uninterruptable sleep) cannot be killed while they are in this state. NFS was notorious for this but there are other ways to get a process stuck. Broken device drivers that don't return control to the calling process can also cause this behavior. One would need to reset the driver, but in general there is no way to do this. I hate to ...


3

To make a zombie process: $ (sleep 1 & exec /bin/sleep 10) This replace the shell which run sleep 1 with /bin/sleep 10 that won't know the sleep 1 process terminated, so creating a zombie in 10 seconds. I'm not sure what do you want when killing a zombie process. A zombie process was already dead, you can not kill it. Actually, you can make zombie ...


3

program & will still have the same stdin and stdout as program, but program & usually (depending on your terminal settings) won't be able to read from stdin without getting stopped by the system via the SIGTTIN signal (see https://en.wikipedia.org/wiki/Job_control_(Unix)#Implementation ). Background processes won't receive signals from keyboard ...


3

No part of the official kernel currently does that, nor any third-party kernel module that I've seen. Only a kernel component could do that. I think that /proc/[0-9]* is common enough in shell scripts that no official kernel component will ever do that.


3

nohup should only affect the hangup signal. So kill should still work normally. Maybe you are using the wrong pid or process name; compare with pstree -p or ps -ef. If you still suspect nohup, maybe you could try disown instead. $ sleep 1000 & $ jobs -p 13561 $ disown $ jobs -p $ pidof sleep 13561 $ kill 13561 $ pidof sleep $


3

The ps ax | grep -v grep | grep "XML2DB.jar -n" technique has a race condition: the grep instances may or may not get started in time for ps to see them, so you get inaccurate counts: see here and here. You aren't the first one to get in trouble using it. I did an strace pgrep somepattern on a RHEL box to find out what pgrep is doing. It stats every process ...


3

In general, it isn't possible for a shell to “adopt” a job. For a shell, a job means a few things: Associate a job identifier with a process ID. Display its status (running, suspended, dead). Notify the user when the status changes. Send a SIGHUP signal when the terminal goes away. Control whether the job “owns” the terminal (whether it's the foreground ...


3

The process name is nautilus. Nautilus contains its own code to copy files, this code is executed inside the nautilus process, not in a subprocess. You can see for yourself what subprocesses Nautilus runs by logging its system calls with strace: strace -f -o /tmp/nautilus.strace nautilus The clone system call creates new processes (it's a generalization ...


2

How about ps -eL -o user,pid,psr,comm,args. psr field gives you the processor currently assigned to that thread.


1

According to http://www.di.uevora.pt/~lmr/syscalls.html, the suffixes indicate the type of arguments: l argn is specified as a list of arguments. v argv is specified as a vector (array of character pointers). e environment is specified as an array of character pointers. p user's PATH is searched for command, and command can be a shell ...


1

It means a number of things. The backgrounded process is not holding up your terminal. It is being run "asynchronously" in that we are not waiting for it to complete. It will still die if disconnection is forced. Consequently the responses are not necessarily "active" but "passive", it is good form to redirect output to a file for later inspection. ...


1

Not so interesting answer: $ (A=$BASHPID && ( kill -STOP $A )) [1]+ Stopped ( A=$BASHPID && ( kill -STOP $A ) ) $ ps -C bash PID TTY TIME CMD 29453 pts/0 00:00:00 bash 29593 pts/0 00:00:00 bash 29594 pts/0 00:00:00 bash <defunct>


1

The setrlimit(2) syscall is relevant to limit resources (CPU time -integral number of seconds, so at least 1 sec- with RLIMIT_CPU, file size with RLIMIT_FSIZE, address space with RLIMIT_AS, etc...). You could also set up disk quotas. The wait4(2) syscall tells you -and gives feedback- about some resource usage. And proc(5) tells you a lot more, and also ...


1

If you used nohup, you can't kill them. The nohup command specifically prevents those processes from receiving the kill signals. If you simply used &, you can kill them by sending a kill or kill -9 to the PID. Well, you can kill them by rebooting the machine, but that might be a bit more extreme than you really want...


1

Both have there own + and - : nohup: nohup is good to use for running procs in background when proc don't need any user input like httpd server or any other server proc like that. nohup does create log in dir of proc execution. log file name default is nohup.out It avoids proc getting killed due to mistaken ctrl+C , ctrl+D . Just a safe guard. It's ...



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