Tag Info

New answers tagged

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


0

That just means the daemon's parent (pid 677) started the new session, forked, and the child (pid 678) inherited that session and kept running. This could happen if some wrapper script was used to daemonize something (and for some reason didn't exec its target - perhaps to handle restarts), or just because the process chose to fork again prior to entering ...


-2

sudo kill -9 $(job -p) This will work


0

The 1st coloumn of the same row(at the extreme left) of the thread it will show the ID of the thread. grep that thread ID in the output of ps -eLf and you will see the thread. Remember, you have to use the options -eLF to include the threads in the output. From man ps : -L Show threads, possibly with LWP and NLWP columns


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


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.


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


1

Try doing this : sleep 600 &


0

I try on my gnu/gentoo, no such problem, here it is: ~ # ps -o ppid -o lstart --sort=lstart PPID STARTED 3851 Mon Dec 15 21:25:51 2014 4037 Mon Dec 15 21:25:52 2014 4042 Tue Dec 16 22:02:24 2014 ~ # ps -o ppid -o lstart --sort=lstart PPID STARTED 3851 Mon Dec 15 21:25:51 2014 4037 Mon Dec 15 21:25:52 2014 4042 Tue ...


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


-1

You can get it with pfiles /proc/* Check this post for solution http://atoz-networking.blogspot.in/2014/12/how-to-get-process-id-attached-with-port.html


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


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


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


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


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


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

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

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


0

Each process has its own address space, i.e. each process can only access its own virtual memory and not the memory of other processes. Executables and shared libraries are mapped into the process's address space. In your example of a ruby script, the script is only read and interpreted by the ruby interpreter which builds a compiled version of the script ...


4

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


1

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


0

start cmd: # screen -ls There is a screen on: 24525.pts-0.syscontrol (Attached) start cmd: # pstree -p 24525 screen(24525)─┬─bash(10773)───su(10790)───bash(10791) ├─bash(10863)───pstree(11099) └─bash(24526)


0

All the times are per-process (in older versions of Linux, they were per-thread). Metering starts when a process is forked, continues over all of its execs, and ends when it exits. Times from its children are not included; they are available in the respective records for each child when the child exits. If you're using the acct_v3 format, the records include ...


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


0

If you mean writing a program that allows using the command to control your program after it went to the background, you can use IPC mechanisms such as sockets and dbus. Your program will go into the background and acts as a "server" if no other arguments are given. Otherwise, it will acts as "client" and try to communicate with the "server". The client ...


0

Write the following script to file (ctx.sh). with ctx.sh <core> you will see all the processes running on a given core and changing nv-context switches will be highlighted. Looking at this, you will be able to identify which are the competing processes for the core. #!/bin/bash if [[ $# -eq 0 ]] then echo "Usage:" echo "$0 <core>" ...


0

I'm not totally sure what you mean by "communicating with it" - but if you mean start/stop, there are a few easy ways to "hack" this type of behavior. Option 1: Code your application to run natively in the background. For instance, python has a daemon module where you can move your process into a service/daemon like state. Here's an example in python: ...


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


0

Quoting Linux Device Drivers, 3rd Edition. I didn't use the Quote button, as I wanted to bold the options Except where specified otherwise, all of these options are found under the "kernel hacking" menu in whatever kernel configuration tool you prefer. Note that some of these options are not supported by all architectures. CONFIG_DEBUG_KERNEL This option ...


0

ps -o pid,user,vsz,rss,comm,args The 4th column (rss) is the resident set size, the non-swapped physical memory used by a task, in kiloBytes.


-1

You can use get the pid running location using the below command ls -l /proc/PID_id/cwd


-1

I ended up using the following: grep -r "$command" $(ls -l /proc/$pid/cwd | awk '{ print $11 }') | awk -F: '{ print $1 }' Where $command="$(cat /proc/$pid/cmdline | sed 's\x0/ g' | sed 's/.$//')" Which will recursively grep through the files in the directory that the script is in to find the file containing the command line that ran the nc command. Seems ...


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


0

As a general rule, you never want to do ps aux | grep -v grep, that's what pgrep is for: pgrep -u root The command above will list all processes started by root. You do need ps if you want to 1) exclude those whose name is enclosed with [] and 2) restrict to those not listed as running in ttys. You can avoid some of the problems mentioned in the other ...


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


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


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


2

The only thing that comes close is iostat from the sysstat suite which also works for regular users or maybe atop -d (fails with a floating pointing exception here). Nearly same question was already asked here: http://serverfault.com/questions/260818/in-absense-of-iotop-which-command-is-most-appropriate-for-get-i-o-bounded-proces iotop doesn't work for ...



Top 50 recent answers are included