Hot answers tagged process
8
Conceptual level
When you start a process from your shell, the current working directory of the process is the same as the current working directory of your shell. In the context of the shell, the current working directory is the location you are currently "at."
The current working directory of any process is used to interpret relative paths.
For example, ...
5
If you want to look at a particular process named e.g. wing_ide, then
ps a | fgrep wing_ide | fgrep -v fgrep
gives you a number at the beginning of the line (in my case 29837) use this number as follows:
fgrep '[heap]' /proc/29837/maps
The output look like:
01d56000-07026000 rw-p 00000000 00:00 0 [heap]
If you do this on a ...
4
summary:
You should use jobs to list, and use kill %n to kill the n'th backgrounded process, and if your bash supports it : kill %-1 will kill the n-1'th backgrounded process.
details:
# find / -print >/dev/null 2>/dev/null &
[1] 1291234
# find /./ -print >/dev/null 2>/dev/null &
[2] 2162424
# find /././ -print >/dev/null ...
3
What you could do is having a daemon (let's call it filld as it fills up F each time P needs it).
When you launch it, it tries to open the FIFO (and blocks as there is no reader). Each time a reader comes, it writes to the FIFO what it needs to write (fork-ing and exec-ing G for example), closes the FIFO and reopens it. Each time, it succeeds in opening, it ...
3
Am I then right to think that any pair of processes can be piped to each other?
Not really.
The pipes need to be set up by the parent process before the child or children are forked. Once the child process is forked, its file descriptors cannot be manipulated "from the outside" (ignoring things like debuggers), the parent (or any other process) can't ...
3
This is unrelated to the parent process ID. The problem is simply that you are killing all the processes running run_tcp_sender.sh, but you have no such processes — the processes you're interested in are running bash.
You can instruct pkill to match on the whole command line:
pkill -f '^bash run_tcp_sender.sh'
Another approach would be to kill all the ...
3
pkill by default sends the SIGTERM signal to processes to stop. Here's a list of the signals you can send a process. You can send them by name or number typically:
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 ...
3
Well, it depends on what you mean by "file" and how exactly the library accesses it. Here are a few approaches (both kluges) that come to mind:
Use a temporary file, in the normal mkstemp meaning. mkstemp returns a file descriptor number to an unlinked file. You can then create $FOO/mypasswd as a symlink to /proc/self/fd/returned_number. There is a small ...
3
Something like
compile && { test -f /path/to/dont_run || run; }
should solve your problem. touch /path/to/dont_run would prevent run from being executed. You can make this more complicated (and more convenient) by e.g. defining a shell function cond_run_cmd which does some check like that, limited to its tty (so that you can have several in ...
2
Do not use kill -9 if not absolutely necessary, and most of the time it is not absolutely necessary. Always try kill (without -9) first. See here for more explanation.
I think that your "trouble" killing firefox is a direct result of your kill -9 (or pkill -9). Firefox maintains lockfiles in the profile directory. The lockfiles are there to prevent two ...
2
Using exec is a pretty good demonstration of PID reuse:
#!/bin/bash
cat > foo << 'EOF'
echo "Inside foo."
sleep 5
exec ./bar
EOF
cat > bar << 'EOF'
#!/bin/bash
echo "Inside bar."
sleep 5
EOF
chmod a+x foo bar
./foo &
while sleep 3; do
[[ -f "/proc/$!/cmdline" ]] || break
printf 'pid %d == %s\n' "$!" "$(tr '\0' ' ' < ...
2
As derobert already indicated, probably the easiest way to get a different name in the process talbe is by renaming the 'private' python executable from python to wing_ide.
The startup command, /usr/bin/wing4.1, is actually a minimal schell script calling a second script /usr/lib/wingide4.1/run-wing.sh this I patched as follows:
@@ -66,7 +66,9 @@
# ...
2
A process can only write to its own /proc/pid/comm. So since it sounds like you can modify the IDE's code, you can just have it write to /proc/self/comm.
Another option would be to change the name of its Python executable, and then change all the #! lines, but that may be a PITA.
Other—more painful—options would be writing some C code and using LD_PRELOAD ...
2
There are several ways of marking the instances of a process. You can do that via the command name in the process list (e.g. matlab_1 instead of matlab) or via an environment variable. Using the PID is possible, too. You just have to output it before matlab is started:
nohup time bash -c 'echo $$; exec matlab -some_parameters -r "run '"$1"';exit"' ...
2
That sentence isn't very clear. First, parent should be ancestor, as the process setting up the pipe can be a parent, or a grandparent, or a grand-grand-…-grandparent, or one of the communicating processes. Second, the sentence doesn't mean “if you want a pipe, there must exist a common ancestor process”, but “if you want a pipe, a common ancestor process ...
2
The shell of the pipeline is the common parent which sets up a communication channel between the several members of the pipeline.
Any process can be piped to any other. The only processes that can usefully be piped together are "filters" that read from stdin and write to stdout.
For example, if you issue the command
$ tail -f /etc/motd | tail -f | cat ...
2
An infinite loop is the reason for at least two reasons. Beside the one you noticed: You want the file updated on every access, don't you? Otherwise you could simply create a regular file with the right content.
A hook for open*() is possible but probably not trivial. FUSE is the way to go. If you are lucky then a module for this already exists. Otherwise ...
1
In the end, it seems that the Matlab command is subsequently spanning other processes (JVM) when called. However, there is an undocumented function feature that returns the PID of the running Matlab process:
nohup time matlabR2012b -nodesktop -nosplash -nodisplay \
-r "fprintf('PID: %s\n', num2str(feature('getpid')));run $1; exit" &> "$2" &
1
This is by design.
Closing a session doesn't close all of the user's programs. This is by design. For one thing, the user could have programs running in other sessions. The user could also have wanted to keep a program running in the background while he isn't logged in on any terminal (screen or tmux is especially popular for this).
What closing a session ...
1
Background processes get upgraded to parent process of (on Linux usually) init, PID 1.
obviously the & is for run it on background. The question is why it keep running if it was launched by root but root is no longer active?
root is active as long as your system is up running. (root as in the superuser.)
Anyhow, it doesn't have anything to do with ...
1
It's the & sign after the truecrypt command. This is causing the truecrypt session to run in the background. if you remove the & symbol it will close when the terminal window is closed.
If you'd like to keep the &, you can use the fg command to bring the session to the foreground, after which it should close with the window. Use jobs to list ...
1
#!/bin/bash
exec 3<>file
rm file
exec program
To be precise: There is a race condition. And the program has to use the file descriptor. If you have to pass a file path then use /proc/self/fd/3. But theoretically the file (even though deleted) is accessible through this proc path for other processes, too.
1
Every process has a current working directory (CWD) that it's assigned to when it starts up. You can do the following to find out the working directory for a process.
Run ps aux to find out PID of a process:
$ pgrep cupsd
24532
To find out current working directory of a PID: 24532
$ sudo pwdx 24532
24532: /
So process (PID: 24532) has a CWD of /.
...
1
You can see the entire command used to invoke a process using top, but it doesn't show it by default. Toggle that with lower case c. This should enable you to distinguish one python app from another.
The difference between the command line invocation and the process name shows up in proc too, as cmdline and comm.
1
Seeing zombies tends to indicate a bug in the process that spawned them: that process is supposed to reap the zombies (by calling wait) or explicitly ignore SIGCLD (or set the SA_NOCLDWAIT flag).
However this is a minor bug. Zombie processes only consume an entry in the process table, which is a negligible amount of resources. The problem only becomes ...
1
In Unix/Linux, new processes are created by the fork(2) system call (or some sugared-over version of it, or perhaps by another variant of clone(2)). It is the parent's responsibility to do a variant of wait(2) to collect the exit status of the child process (if the parent finishes before the child, init(8) gets to take care of the orphan). A terminated ...
1
As ever - it depends. Most monitoring-tools will turn yellow or red of they encounter more than a certain number of zombie processes.
So basically - yes - it is normally a sign of a problem.
But I have seen programs that spawn zombie-processes as part of their "normal" operations. These zombie-processes went away when the according top-level-api (I do not ...
1
Does this happen every time you use gvim? Does gvim works apart from leaving a zombie after it exits? Unless it causes real problems, I would simply ignore it - zombies doesn't tax the system's resources. I wouldn't be surprised if it was a bug in gvim - or perhaps in gtk, but unless the program doesn't work at all, I'd ignore it.
A zombie/defunct ...
1
If you're continuously encountering a zombie process I would be inclined to think that there is definitely something wrong. Zombie process do occur. I generally see a few a month on the various systems that I maintain both at work and home.
Usually they can be accounted for due to operator error or to an issue with a particular piece of software. Reboots ...
1
Having though more about my question I think I can answer my question.
[R]unning state is tracked as user mode(utime) and kernel mode(stime) as it requires cycles.
Sleep/idle time can (sort of) be calculated by subtracting calculated running time in jiffies from start_time, time process started after reboot. This isn't all that reliable assuming the clock ...
Only top voted, non community-wiki answers of a minimum length are eligible
