[kman42]

I have a process running int he background. How do I pause it and then restart it?

I know ctrl-Z will pause processes, but I'm not sure how to get the process to the foreground using its PID or to restart it.

thanks,
kman

[Ludovic Hirlimann]

Originally posted by kman42:
I have a process running int he background. How do I pause it and then restart it?

I know ctrl-Z will pause processes, but I'm not sure how to get the process to the foreground using its PID or to restart it.

thanks,
kman

fg PID.

[kman42]

Originally posted by Ludovic Hirlimann:
fg PID.

I get an error: No such job.

I used top to get the PID.

Basically, I want to pause the Folding@home client when I am running on battery so I don't eat through my battery time as quickly. I don't want to go through the hassle of killing and then launching it with all the appropriate flags and I thought it would just be easier to bring it to the foreground and then ctrl-Z it.

kman

[utidjian]

Originally posted by kman42:
I get an error: No such job.

I used top to get the PID.

kman

This is a job control issue (and also dependent on shell). IF you started the process with:

somecommand &

then it usually echoes a number (the job number) back to you at that time. To determine the jobs you have running type the command:

jobs

It is as simple as that. It should list it something like this:

[1]+ status somecommand

The number in the brackets is the job number. To "foreground" the job just type:

fg

or if there is more than one job

fg %jobnumber

If it has job number 1, you would type:

fg %1

Then to suspend it just do Ctrl-G.

[kman42]

Well, that doesn't seem to work either. I did start it with

./osx-3.25 &

osx-3.25 is the name of the Folding@home client application.

When I type jobs, I get nothing, but I can see the process running in top. Hmmm...


kman

[leffo]

Originally posted by kman42:
I have a process running int he background. How do I pause it and then restart it?

I know ctrl-Z will pause processes, but I'm not sure how to get the process to the foreground using its PID or to restart it.

thanks,
kman

This is a bit tricky to do with simple shell-job-stuff, if at all possible. Check out the screen-command though. I think that will help you.

[suthercd]

You could also set up an alias for your starting command and it's parameters in .xinitrc. That would simplify starting it.

Craig

[utidjian]

Originally posted by kman42:
Well, that doesn't seem to work either. I did start it with

./osx-3.25 &

osx-3.25 is the name of the Folding@home client application.

When I type jobs, I get nothing, but I can see the process running in top. Hmmm...


kman

Weird...

What shell are you using? I just tested the instructions I gave in tcsh and bash.. to make sure. It works for me here.

For the 15 years I have been using Unix and Linux job control is the only method I know of for handling backgrounded processes from the commandline. (ie: fg, bg, %N, Ctrl-Z) and it has always worked unless something was broken.

I looked into the Folding@home project site and there are options to run the process at different process prioritites (niceness) see: http://folding.stanford.edu/console-userguide.html
You should be able to run it re-niced to the lowest level with:

./command -nice X

where X is the level you want to run it at. By default, on the Linux box I am testing this on, it runs at nice = 19 which is so low a priority I don't even notice it. IOW it looks like it is using damn near 100% CPU in top butit gets out of the way when I want to do anything else. In this way it can be run and not interefere with any task that is more demanding. So check your config file.

[Richard Edgar]

Don't kill-STOP and kill -CONT do the necessary?

[OreoCookie]

Nice'ing the job won't do the trick, because it will still suck your battery.

In any case, I would nice it (10 works fine for me). Since 10 is the standard nice, a simple

nice [binary] &

would put it in background.

jobs works fine here.

[leffo]

kman42 says that he wants to be able to pause a process when on battery-power and then resume it when on AC, right? Well, how would you do that with simple shell jobs? If anyone know how to do that, please inform me because I have no idea. The only way I can think of to this is to use screen. Like this:

Let's say you want to start top, pause the process and then continue it later on. This is how I would do it:

First, start top inside screen, which is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells) (man screen).

Code:
screen top

Then, inside screen, which is now running top, press Control-a-z to pause the screen- and top process. top is now suspended and you're back at the command-line. Now you can safely do whatever you want, screen will keep track of your process.

To resume top just type:

Code:
screen -r

and the top process is resumed. To actually terminate the top process and screen press Control-a-q inside screen.

By using screen you can close your Terminal, logout or whatever (besides re-booting) and your process will continue to run. If you would just use job-commands you would not be able to resume the process if you quit your shell (like closing the Terminal).

Hope that made sense. I just came back from running in the sun (yay, summer is coming!) for an hour, so I'm still a bit high on endorphins

[utidjian]

Ach!! My mistake. I forgot he wanted to do all this to save battery power.(thud)

Originally posted by leffo:
kman42 says that he wants to be able to pause a process when on battery-power and then resume it when on AC, right? Well, how would you do that with simple shell jobs? If anyone know how to do that, please inform me because I have no idea. The only way I can think of to this is to use screen.

Yes, BUT screen will NOT suspend the process. It will still be running and using up battery power. As an example: Start a screen session, start top, "suspend" the screen session, then run another top... you will see two top sessions running in the second top.

Out of all the suggestions so far... the one by suthercd seems the most practical... almost. Just create a script and give it a button. Click on the button to start... another click to stop.

Another method would be to have the FAH process start on bootup. It would monitor whether the system was on bater or AC, if on AC then run, if on battery then suspend. I don't have a Mac OS X laptop so I can't test it oer work it out. Is there something like hwmond on the laptop? In Linux (where I do have a laptop) there is cat /proc/apm. /proc/apm contains a string of the automatic power management status of the laptop. It would be trivial to have a script check it periodically to determin e if the FAH process should be suspended or not.

[leffo]

Originally posted by utidjian:
Yes, BUT screen will NOT suspend the process. It will still be running and using up battery power. As an example: Start a screen session, start top, "suspend" the screen session, then run another top... you will see two top sessions running in the second top.

Oh my, you're right! All this time I thought the process was being suspended as well. Thanks for pointing that out!

Is there something like hwmond on the laptop?

hwmond is included in Darwin, but:

Code:
(leffo@NL03-23-109) [~]$ sudo hwmond
Password:
"PowerBook4,3", hwmond will NOT run on this platform.
(leffo@NL03-23-109) [~]$

so no luck there.

The tricky thing is, how can you easily suspend a process and later on resume it if that functionality isn't included in the application itself? If you do it the shell-job-way you need to keep the shell open to be able to resume a suspended process. I'm out of ideas.

[Richard Edgar]

Could someone please explain why kill -STOP and kill -CONT don't achieve the original goal of suspending and resuming the offending process?

[leffo]

Originally posted by Richard Edgar:
Could someone please explain why kill -STOP and kill -CONT don't achieve the original goal of suspending an resuming the offending process?

No, because it works great! Silly me, missed your original post
Thanks! Quite excellent actually.

So, kman42, this is it. Richard had it figured out all the time

[kman42]

Originally posted by leffo:
No, because it works great! Silly me, missed your original post
Thanks! Quite excellent actually.

So, kman42, this is it. Richard had it figured out all the time

Cool. This discussion really took off overnight and I was quite happy to see the answer this morning. thanks to everyone!

The next question is: How do I get my cocoa app to issue a terminal command? I wrote a little app to monitor the progress of F@H and it would be cool to include this functionality either with a couple of buttons or a timer that checks for A/C power periodically.

kman

[utidjian]

Originally posted by leffo:
No, because it works great! Silly me, missed your original post
Thanks! Quite excellent actually.

So, kman42, this is it. Richard had it figured out all the time

Except, IF one does a kill -STOP on the PID of FAH AND closes the shell it still kills it for good NOT just suspend.

If it works for kman42... fine. Even better if it works around his broken job control. But it still has the shortcoming of closing with the shell... it is STILL shell dependent. Incidentally, kill -STOP and kill -CONT are essentially identical to Ctrl-Z and fg. IOW they do the exact same thing.

Although it is a workaround it still doesn't explain why the regular fg, bg, Crtl-Z... and so on do not work correctly. I would consider something to be "broken" if those didn't work.

[Richard Edgar]

It can be a bit random (and depend if X forwarding is being done), but closing a shell does not usually kill a job run with &. If you really want to make sure, then start it with nohup. Admittedly I can only test under Solaris 9 - OSX might be slightly different.

Addendum: Having just had a look at man nohup, it looks like putting an amperand on the end of a command prevents hangups on commands run with & from csh (and tcsh). I imagine that YMMV with other shells.

[kman42]

Originally posted by utidjian:
Except, IF one does a kill -STOP on the PID of FAH AND closes the shell it still kills it for good NOT just suspend.

If it works for kman42... fine. Even better if it works around his broken job control. But it still has the shortcoming of closing with the shell... it is STILL shell dependent. Incidentally, kill -STOP and kill -CONT are essentially identical to Ctrl-Z and fg. IOW they do the exact same thing.

Although it is a workaround it still doesn't explain why the regular fg, bg, Crtl-Z... and so on do not work correctly. I would consider something to be "broken" if those didn't work.

I'm not sure if anything is actually broken or not. I have certainly been trying these things using various shell sessions. I'm starting the F@H process at startup using cron so I am actually never in the shell where the process is started. My job control works using jobs, fg, etc if I try it using commands issued within a single shell session. For instance, the following commands give the expected results:

top &
jobs
fg 1

etc...

I think my problem has been in trying to interact with processes that were not started manually in my current tcsh session.

Other ideas? This has been a very fruitful discussion for me thus far.

kman