Tips On Managing Multiple Linux Processes

From The Player Project

Revision as of 02:33, 31 January 2011 by Rmattes (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Using Player with multiple robots, each with its own player server and set of clients, can be hard to manage, especially during development when you are frequently stopping, modifying, and starting multiple programs, often all on the same computer if using one of the simulators.

One approach is to open many terminal windows, or use the "screen" program.

Another is to run programs in the background in one or a few terminals, and save the output of each program t files. Is bash and most other Linux shells, '>' redirects a program's output. '2>' redirects it's error log. '2>&1' merges those two for that process. For example:

wxgazebo file.world > gazebo.log 2>&1  &
player > player.log 2>&1 &
myplayerclient > client1.log  &
myplayerclient > client2.log  &

Then later you can look at the log files. The 'tail' program is useful here, especially 'tail -f'.

Also, note that you can still enter commands in a terminal even if a background process is printing output.

A long time ago I used MDNS service discovery to automate some of this. I'd run a Player server with Stage and several robots, and each robot had a device that issued a broadcast MDNS notification on the network, and MDNS listening daemons on different machines would run clients. This made it easy to start up lots of clients, and distribute them on different computers. I think the MDNS/Rendezvous code is still in Player but don't know if it's maintained -- I haven't used it or tested it in several years.

Personal tools