I've got a process that is currently running (arserverd) that was started by user "remedy". I am able to log in as this user. I would like to capture stderr and stdout without restarting the process. Is this possible?
If the process is already running, you could use the truss command to intercept writes to file descriptor 1 or 2:
truss -w 1,2 -p pid_of_arserverd
Truss will output lines like
write(1, " m e s s a g e\n", 8) = 8
Truss is specific to Solaris. On linux systems, look for strace instead.
Truss will slow down the process that you're trussing somewhat, so it's not something you'd want to use all the time. If you're looking for a permanent solution, your best bet is probably to redirect stdout and stderr to a file when launching the program. You can regularly truncate the file to keep its size manageable. An alternate is to run the program within a screen session that you can reconnect to when you want to interact with the program.
I don't think so but you can try to read from /proc/PID/fd/1 for stdout and /proc/PID/fd/2 for stderr (replace PID with the PID of the process).
Related
Just for the sake of the question, say I open a terminal an log into my Linux computer. I run a program that keeps outputting information on my screen, looping. I close the terminal window, and the program shuts down.
I set up a cronjob or a startup script that launches the same program as in example 1. The program is looping now, run as root.
I open a terminal, and log into my computer through SSH. Can I make a Bash script that retrieves the output of said program, even if it's running somewhere in the background? I mean, is the program "virtually" outputting information (as in example 1)?
The program closes stdout and stderr when it exits. Looping it as you describe will just cause it to start and exit continuously. You could look at redirecting stdout and stderr.
I'm trying to restart a custom IRC bot. I tried various commands :
load.php
daemon load.php
daemon load.php &&
But that makes the script execute inside the console (I see all the output) and when I quit the bot quits as well.
The bot author only taught me the IRC commands so I'm a bit lost.
You can install a package called screen. Then, run screen -dm php load.php and resume with screen -dR
This will allow you to run the script in the background, and still be able to use your current SSH terminal. You can also logout and the process will still be running.
Chances are good the shell is sending the HUP signal to all its running children when you log out to indicate that "the line has been hung up" (a plain old telephone system modem reference to a line being "hung up" when disconnected. You know, because you "hang" the handset on the hook...)
The HUP signal will ask all programs to die conveniently.
Try this:
nohup load.php &
The nohup asks for the next program executed to ignore the HUP signal. See signal(7) and the nohup(1) manpages for details. The & asks the shell to execute the program in the background.
Clay's answer of using screen(1) is pretty awesome, definitely look into screen(1) or tmux(1), but I don't think that they are necessary for this problem.
This line might help you
php load.php &
I'm accessing a webserver via PHP. I want to update some info in the Apache configs, so I start a shell script that makes the changes. Then I want to stop and restart Apache.
Problem: as soon as I stop Apache, my process stops and my shell script, being a child process, is killed. Apache never restarts. This also happens with Apache restart.
Is there a way to fork an independent, non-child process for the shell script, so I can restart Apache?
Thx,
Mr B
You can use disown:
disown [-ar] [-h] [jobspec ...]
Without options, each jobspec is removed from the table of active jobs. If the `-h' option is given, the job is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If jobspec is not present, and neither the `-a' nor `-r' option is supplied, the current job is used. If no jobspec is supplied, the `-a' option means to remove or mark all jobs; the `-r' option without a jobspec argument restricts operation to running jobs.
./myscript.sh &
disown
./myscript.sh will continue running even if the script that started it dies.
Take a look at nohup, may fit you needs.
let's say you have a script called test.sh
for i in $(seq 100); do
echo $i >> test.temp
sleep 1;
done
if you run nohup ./test.sh & you can kill the shell and the process stay alive.
hi i am new to valgrind. I know how to run valgrind on executable files from command line. But how do you run valgrind on server processes like apache/myqld/traffic server etc ..
I want to run valgrind on traffic server (http://incubator.apache.org/projects/trafficserver.html) to detect some memory leaks taking place in the plugin I have written.
Any suggestions ?
thanks,
pigol
You have to start the server under Valgrind's control. Simply take the server's normal start command, and prepend it with valgrind.
Valgrind will attach to every process your main "server" process spawns. When each thread or process ends, Valgrind will output its analysis, so I'd recommend piping that to a file (not sure if it comes out on stderr or stdout.)
If your usual start command is /usr/local/mysql/bin/mysqld, start the server instead with valgrind /usr/local/mysql/bin/mysqld.
If you usually start the service with a script (like /etc/init.d/mysql start) you'll probably need to look inside the script for the actual command the script executes, and run that instead of the script.
Don't forget to pass the --leak-check=full option to valgrind to get the memory leak report.
Is there a way to get the current working directory of a process using it's PID programmatically on OS X?
Cocoa, Carbon, or AppleScript are all acceptable.
It is not acceptable to send "pwd" to the current terminal window/tab (Do not want to affect the workspace).
The linux command "pwdx" also is also unacceptable (just in case you read over the "Cocoa" part)
On 10.5 and later:
lsof -a -p $PID -d cwd -Fn
(Prefix with sudo if the process is owned by root.)
The following AppleScript is a partial solution for your problem. Given the UNIX pid in the variable thePID it first gets the name of the process. It then sends the do shell script command to the application process which will result in a child shell process being spawned. The child process inherits the current directory which can then be determined by running the pwd command.
tell application "System Events"
set theName to name of first process whose unix id is thePID
end tell
tell application theName
do shell script "/bin/pwd"
end tell
The script does not work for processes that do not link to the AppleEvent framework (e.g., pure POSIX processes).