Tag Info

Hot answers tagged

5

> bash -c 'exec -a sadhadxk sleep 1000000' & pgrep doesn't work but > ps | grep '[s]adhadxk' 18931 [...] sadhadxk 1000000 Correction: pgrep does work but not against the command name (which is the name of the running binary), only against the command line: > pgrep -f sadhadxk 18931


4

You can use word notation for more readability : kill -STOP <PID> # pause kill -CONT <PID> # continue working Check man 7 signal


4

SIGTERM allows a process to perform cleanup before it terminates, but whether or not the process actually does so, and what sort of cleanup it performs, depends on how the program was written and (to an extent) on the facilities that the language the program was written in provides. So when a program receives SIGTERM it's not obliged to save anything, but ...


4

ps --sort=lstart doesn't actually sort by lstart, According to this serverfault comment: lstart gives a full timestamp, but cannot be used as a sort key. start_time gives the usual 'time within the last 24 hours, date otherwise' column, and can be used as a sort key. This is implicitly documented in ps's man pages, where lstart is not listed under ...


3

You could do: perl -e '$0="sadhadxk"; sleep infinity' & It should set both the process name and argv[0] on systems where it's supported so should show sadhadxk in both ps and ps -f output, so should be matched by both pgrep -x and pgrep -fx.


3

You could use wmctrl to gracefully close all windows of a particular application1 (as far as I know it's "as clean as if the application was closed using menu->Exit"). using app wm_class: for win in $(wmctrl -lx | awk '$3 ~ /Icedove/ {print $1}'); do wmctrl -ic "$win"; done using app pid: for win in $(wmctrl -lp | awk -v icepid=$(pgrep icedove) '$3 == ...


3

While this might be a little clumsy, you could say that. Creating a process takes two steps: Allocate a u area (basically, information about the process that is accessible to the kernel), fill an entry in the process table, initialise all related components... basically, just create another process for the kernel to manage. This is done through the fork ...


3

The parent (sudo) is notified that the child process has exited. As the only purpose of the parent was to run this child process it terminates. Other processes would not terminate just because you kill a child process. On the other hand the child doesn't care what the parent process does. The parent could even terminate immediately after the child process ...


3

This depends on how the script is writing: If directly by redirection (i.e. my_script.sh > ~/1212_000001/some_file), you can use lsof -p <script-pid> and you'll see the open file on your output directory Else, the output of ps axjf' will show you the pid dependencies of sub-processes launched by your script, which may give you the information ...


3

"arguments that cannot be located" typically means that the process has no command line arguments because it's not a normal user process but one started directly by the kernel. When you're looking for a process that's doing something wrong, it's usually not one of these kernel processes, so your colleague suggested filtering those out. tty is not "just a ...


3

You can start the process in screen, type screen (it will start new screen session), run any command just like in your regular shell, detach screen (by pressing Ctrla, then d) and attach to the screen from any other terminal tab by typing screen -r. In this case the process's parent is screen, which is detachable / attachable from any terminal session, ...


2

The usual way would be to use pgrep: $ pgrep init 1 2215 6300 $ ps ax | grep init 1 ? Ss 6:41 /sbin/init 2215 ? Ss 1:54 init --user --restart --state-fd 26 6300 ? S 0:00 init --user --startup-event indicator-services-start 17522 pts/10 S+ 0:00 grep --color=auto init Note that you might need to use other tricks ...


2

In Linux, once a parent process is killed its child process becomes an orphan. But then the "warm hearted" init process adopts that orphan process which allows it to proceed. In order to kill parent and its children processes you can use: pkill -TERM -P <parent's PID> (Note: orphan process is different from zombie process, but that's for another ...


2

What you're seeing should not surprise you. You've started gedit two different ways, via two different parents, so of course the PPID — parent process ID — is different in the two cases. The first is a child of Bash, because you started it from a Bash command line. The second child's initial process will be your OS's GUI system, but because it's being ...


2

Your caracteristics are way too restrictive. The key notion here is: a daemon is a background process, therefore it cannot be the controlling process of a terminal, nor can it have a controlling terminal. This simple "rule" allows daemons to survive across terminals open/close and users login/logout. Each terminal has a controlling session, that is, a set ...


1

When looking at the Wikipedia page: "a process is an instance of a computer program that is being executed". So if usually to be executed the program needs to be loaded in RAM, a process is not necessarily in RAM. You can for example thing about a sleeping process being put in swap. The process is still running (i.e. it is being listed using the ps ...


1

Every external command and every subshell has its own PID. Shell builtins don't have one. I am not aware of any feature that gives you the PID of the just exited synchronous command. Of course, you can run all commands this way: command & pid=$!; fg


1

To get the Window ID in my program, I have the program set the title to something unique, then have the program start wmctrl and parse its output (and not the shell script that started the program), and then report on the Window ID (most often via a file). Since the program doesn't continue until the windows are open, you will never have to wait to long. ...


1

Try doing this : sleep 600 &


1

To debug this, in top select ffor fields and switch on PPID by moving the cursor there and pressing Space. You might need to deselect one of the other fields (VIRT) so you can actually see this Parent Process ID. Using the PPID you should be able to tell which program invoked that shell, it is probably your program's PID, and you are actually looking at a ...


1

Assuming you can restart the program and put it in a pipe, you can then pipe it to xargs, with the following caveats: you want to run the command one line at a time (-n 1) you want to put the output inside a parameter (-i) you probably want the message to run as soon as the tail reports it, so you need tail to be line buffered. Depending on what you have ...


1

There are no relations between a PID and a job ID on shells I have used (bash, dash and zsh). However, a shell job is a child process of the shell, whereas PID 1 (init) is the ancestor of all processes, including the shell. Therefore a process with job id 1 will always have a PID greater than the job ID. The assignment of a job ID depends on the shell. On ...


1

Jobs are a shell concept. A job is a subprocess¹ of a shell that the shell tracks. A shell instance running on one terminal doesn't know anything about the jobs of another shell instance. When you run jobs in the shell running in the second tab of your terminal emulator, this lists the jobs in that shell. The shell running in the second tab doesn't know ...


1

Why do you use \ at all? The detach character is d.


1

Frankly it sounds a bit silly. grep -Ev "[[]" excludes processes having the opening square bracket in their command. While these are often kernel processes, even a regular user space program can have that character present on the command line. grep -Ev "tty" is the same in pale blue. It excludes processes having the string "tty" somewhere on their line ...


1

To get the parent PID of the process, portably (POSIXly), you can use: ps -p "$PID" -o ppid= or (on Linux): grep '^PPid' "/proc/$PID/status" |cut -f2 for more ways, see http://superuser.com/questions/150117/how-to-get-parent-pid-of-a-given-process-in-gnu-linux-from-command-line


1

Don't use sudo in init scripts. They're run as root to start with. If you were to use sudo in /etc/rc.local (which as per #1 there is no point in doing), you need to provide a $PATH or the path to the executable because there is no $PATH set when this is run at boot by init. So, e.g., if you wanted to run ls, first find out where it is: whereis ls ...



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