Hot answers tagged

4

The T indicates that the process is "stopped". My guess is that you suspended a job (with Ctrl-Z, or with kill -STOP 9649), forgot about it, and then exited. A suspended job can be resumed by sending it the CONT signal (kill -CONT <process_id>), or, by using either the fg (giving the control of the session back to the process) or bg (resuming the ...


3

Use pgrep like this: if ! pgrep -u $USER top >/dev/null 2>&1; then exec top fi Explanation: The pgrep utility exits with a zero exit code if the command can be found running. Therefore, negate the test. Also restrict it to the current user with -u $USER, so that it doesn't for some reason pick up someone else's processes. $USER is a ...


2

Because of the way the mount point gets hidden with umount -l, there is no way to find which processes are still using affected files. The only way to get the list is to use lsof before umount -l to grep the relevant path. Example: lsof | grep "/mountPoint/". If you want, you can take that output to extract the PIDs and continue monitoring them.


2

You can try using setsid (part of the util-linux package) in the .xinitrc to start the script in a new session: setsid statusbar but will it still receive your signals?


2

What is the name of the script itself? Does it match the pattern Recorder Manage? If so, the pgrep is finding the script itself in addition to the process you're looking for, which will then make it effectively a crap shoot as to which will be listed first. Also, don't use kill -9 unless you absolutely have to; just use kill to send SIGTERM rather than ...


2

Use exec to replace bash with java: [program:programname] command=bash -c "source /path/to/env/file && exec java -jar /path/to/jar.jar" In such a case you will have only one process to be killed.


2

Make the command instead a shell script that replaces itself with the java? #!/bin/bash source /i/pity/da/env/foo exec java ...


2

When you run ps al, it (by default) lists all processes with a controlling terminal (tty). It’s most likely that the process you started was “daemonised” to dissociate it from the terminal you were using when you started it. If you include the x option, ps lists processes without a controlling terminal, e.g., ps alx displays all processes for all users ...


2

When I was looking for something similar the suggestions seemed to be along the lines of 'run the program under a separate user' - as you can write per-user iptables rules - http://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html. Having said that, selinux rules might do what you're looking for - ...


2

A process in 'D' state is normally (but not always) "blocked on I/O wait". This can happen if a disk is busy and suffering high service times, for example. Process in D state count towards the load average, even though they're not using real CPU resources. In the case of NFS, a process can spend a lot of time in 'D' state waiting for the NFS server to ...


2

pkill never kills itself, just like pgrep nerver lists itself; pkill does exit after killing each process matching the criteria, except itself. pkill does kill its parent(s) if it(they) match the criteria, but if the parent is a shell unless you use an unignorable signal (usually only -9 aka -[SIG]KILL) the shell normally ignores it. If it includes your sshd ...


2

If the program is always started from the shell and you have full control over it (ie. it is not hardcoded inside 3rd party program), then you can use some locking mechanism like lockfile or flock. For example by adding flock -n /tmp/top -c top to the .bashrc/.zshrc you will ensure that only first instance of the shell will run the top command (unless you ...


1

pkill is doing exactly what you told it to do: it killed the processes whose parent is 100. Not processes whose parent's parent is 100. Neither Linux's pkill nor FreeBSD's has an option to traverse the process tree. You can call pstree -l and parse its output. Keep in mind that if A forks B, B forks C and then B dies, there's no parent-child relation left ...


1

Get the PID of the scala process you want to track using SCALAPID=$! after starting the scala process in background then find the memory usage of the process using ps -o size= -q $SCALAPID the returned value is in kilobytes


1

Maybe you can use nocache. It's a small program that you use like nocache cmd.


1

Agreeing that pgrep is the way to go, there are some pitfalls. You need not use the -q option, since you can redirect the output of pgrep to eliminate that: pgrep -U $USER top >/dev/null || exec top The pitfalls lie in the fact that it is not a standard utility, so you have to keep in mind that it may not be portable. Here are a few manpage links, to ...


1

On Linux, the following should work without requiring a new driver: sudo modprobe ftdi-sio vendor=0x0001 product=0x0002


1

Here is one way to achieve it: $ cat parent.sh #!/bin/sh echo parent.sh running ./child.sh $ cat other.sh #!/bin/sh echo other.sh running ./child.sh $ cat child.sh #!/bin/sh parent="$(ps -o comm= -p $PPID)" if [ "$parent" != parent.sh ]; then echo this script should be directly executed by parent.sh, not by $parent exit 1 fi echo "...



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