I have it set up like this: A script in /etc called mersenne containing only this:
cd /mersenne ./mprime -d I have then added this line in my /etc/inittab c9:2345:respawn:/bin/bash /etc/mersenne > /dev/tty9 This means that it will automatically start mprime and send the output to tty9. When I'm in console mode I can press Alt-F9 and get the current info. If I'm within X then it's Ctrl-Alt-F9.. If mprime dies for some reason it will be automatically restarted. This will not help the original poster seeing the current output since he doesn't have local access to the server. If he wants he can redirect to a file instead but it is bound to get big after a while.. A note in the end. This setup will run mprime as root which might be something frowned upon when running it on a server. On my home machine I don't care.. /Lars On Sun, 2007-11-11 at 07:27 +0000, Brian Beesley wrote: > On Sunday 11 November 2007 04:32, Yves Bellefeuille wrote: > > Heath Volmer wrote: > > > I'm fairly sure that I can get my Ubuntu server to run the mprime > > > programs in the background at startup (although some advice is > > > welcome). > > > > I have the following in /etc/rc.local: > > > > sudo -u yves /home/yves/gimps/mprime & > > This will leave the parent process in memory until mprime terminates. Why not > use nohup instead. > > > > > My concern is since this server essentially runs headless, I won't be > > > able to see what activity is going on. Can it be set up to run into > > > a log file or do I need to pipe it? How am I notified of important > > > events? > > > > There's a log in the files results.txt and prime.log. > > What Yves said. Also you can use top to keep an eye on the active processes > using CPU time; mprime should normally be the biggest user of CPU resources > on the system. > > However what I do is slightly different - I make an ssh connection with the > headless server and run mprime remotely in a terminal window on my main > system. This way you get the same display you would if you were working > locally. The wrinkle is that the remote process crashes if the local system > goes down for some reason, or you accidentally close the terminal window. > > Regards > Brian Beesley > _______________________________________________ > Prime mailing list > [email protected] > http://hogranch.com/mailman/listinfo/prime _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
