The best method is to start the process in a terminal multiplexer. Alternatively you can make the process not receive the HUP signal.
A terminal multiplexer provides "virtual" terminals which run independent from the "real" terminal (actually all terminals today are "virtual" but that is another topic for another day). The virtual terminal will keep running ...
There are a few ways to do this, but the one I find most useful is to use GNU Screen.
After you ssh in, run screen. This will start another shell running within screen. Run your command, then do a Ctrl-a d.
This will "disconnect" you from the screen session. At this point, you can log out or do anything else you'd like.
When you want to re-connect to the ...
In bash, the disown keyword is perfectly suited to this. First, run your process in the background (either use &, or ^Z then type bg):
$ wget --quiet http://server/some_big_file.zip &
By typing jobs you can see that the process is still owned by the shell:
+ Running wget
If you were to log out at this point, the background ...
+1 for @jamzed terse answer, however the OP might need some explanation:
ps | grep "[d]jango"
Using that regex you are launching a process which its ps string will not match itself, since the regexp matches "django" and not "[d]jango". That way you'll exclude the process that has the string "[d]jango" which in this case is grep; The same can be applied to ...
I know this is an old thread, but in case anyone else is having the same issue, I had...
What may be happening is that your process had a TCP port open when it crashed or otherwise exited without explicitly closing it. Normally the OS cleans up these sorts of things, but only when the process record goes away. While the process may not appear to be running ...
I've made a script that accomplishes this task.
The idea commes from James Lawrie's answer and this post: http://www.linuxforums.org/forum/programming-scripting/52375-reading-memory-other-processes.html#post287195
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --...
where $pid is the actual number of the pid; for more info see: info gcore
may take some time for the dump to happen, and some memory may not be readable, but is good enough... be aware also that it can create big files, I just created a 2GB file that way..
Just to be thorough, I'll point out tmux, which has the same basic idea as screen:
tmux is intended to be a modern, BSD-licensed alternative to programs such as GNU screen. Major features include:
A powerful, consistent, well-documented and easily scriptable command interface.
A window may be split horizontally and vertically into panes.
On newer kernels (2.6.32+) on CentOS/RHEL you can change this at runtime with /proc/<pid>/limits:
[root@host 7671]# cat limits | grep nice
Max nice priority 0 0
[root@host 7671]# echo -n "Max nice priority=5:6" > limits
[root@host 7671]# cat limits | grep nice
Max nice priority 5 ...
Here's how to get detail on a service without any external tools on Windows 7 and 8:
Open the Resource Monitor:
Open Task Manager and click on the Performance tab
Click on "Open Resource Monitor" at the bottom
Show Service Detail:
Click on the "CPU" tab
In the "Processes" section, find the process you want; you can sort by CPU by clicking the "CPU" ...
As documented here, the prlimit command, introduced with util-linux 2.21 allows you to read and change the limits of running processes.
This is a followup to the writable /proc/<pid>/limits, which was not integrated in mainline kernel. This solution should work.
If you don't have prlimit(1) yet, you can find the code to a minimalistic version in the ...
From which environment are you creating the process?
If you're doing it from an environment such as C code, you can fork() and then in the child, send a SIGSTOP to yourself before the exec(), preventing further execution.
A more generic solution (probably best) would be to create a stub that does so. So the stub program would:
Take arguments consisting of ...
You can attach to the process using GDB and the process ID and then issue the call command with exit(0) as an argument.
call allows you to call functions within the running program. Calling exit(0) exits with a return code of 0.
gdb -p <process name>
.... Gdb output clipped
(gdb) call exit(0)
Program exited normally.
As a one-line tool:
MikeyB's answer is correct. From this question on superuser, here's a more concise version:
( kill -SIGSTOP $BASHPID; exec my_command ) &
To understand this, one needs to understand how processes are started on unix: the exec system call replaces the currently running program with a new one, preserving the existing PID. So the way an independent ...
Restarting mysql in that case is a bad practice. It results in thrashing your buffers and if your database is large enough - it will take some time to warm up.
I suppose you have some heavy queries that consumes too much cpu.
Use mysql> show full processlist to identify long-running queries and try to optimize them: create indices, re-write queries to ...
I had exactly the same problem and unfortunately auditd didn't do much for me.
I had traffic from some of my servers going towards google DNS addresses, 126.96.36.199 and 188.8.131.52. Now, my network admin has mild OCD and he wanted to clean all the unnecessary traffic since we have our intern DNS caches. He wanted to disable outgoing port 53 for everyone except ...
You have a few options:
1) make mysql inform Upstart that it has started by emitting an event
initctl emit mysql-started" or similar.
This could be handled by adding the initctl invocation to /etc/init.d/mysql.
2) Disable mysql from the normal SysV runlevels and create a wrapper Upstart job that
starts it (not this doesn't handle stopping - just an ...
The only way to get rid of a zombie is to make its parent wait() so it can report its exit status. You can do that by sending SIGCHLD to the parent, assuming the parent is written properly.
If you have zombies it usually means the parent is NOT written properly (because the child already sent SIGCHLD to its parent when it died and became a zombie), so the ...
You can use sh -c and exec to get the command's PID even before it runs.
To start myCommand, so that its PID is printed before it begins to run, you can use:
sh -c 'echo $$; exec myCommand'
How it works:
This starts a new shell, prints the PID of that shell, and then uses the exec builtin to replace the shell with your command, ensuring it has the same ...
My answer is a variation on the typical answer for searching for "foobar" in a ps listing. The argument of "-A" "ps" is more portable than "aux", I believe, but this change is irrelevant to the answer. The typical answer looks like this:
$ ps -A -ww | grep [f]oobar
Instead I use this pattern:
$ ps -A -ww | grep [^]]foobar
The main advantage is that it's ...
Yes, absolutely: screen(1) is the answer.
To get started, add screen -R to ~/.bash_profile or equivalent, log out, and log back in.
To continue what's running in the background, press Control-A then N. This will create a new terminal screen in the foreground while seamlessly continuing your running process on the background.
Press Control-A then " to get ...
I recommend not making it one account but a mailinglist. You can also let the tech support email point to a ticketing system (e.g. Request Tracker), so you can make annotations to the request and easily retrieve the history of the ticket.
One account with one password is not really good practice, actually a mailinglist isn't either.
Get yourself a ...
First of all it is not true that process forking is generally more efficient than threading. This hugely depends on how the OS kernel handles threads/processes.
It is well known that forking processes is an easy, efficient task on Unix systems, but terrible on Windows. Which means that on Windows you're probably much better off using threads, while on Unix ...