search

rock-core / tools-orocosrb

Rock's low-level component control library in Ruby
0 stars 12 forks source link

Record pid of Orocos.run in filesystem #36

Open jakobs opened 9 years ago

jakobs commented 9 years ago

I think it would be nice to record the pid of the processes that are spawned by orocos.rb in a file in /tmp, so that we could have a rock-killall to remove leftover processess from failed scripts. Also, this would provide a way to see which tasks belong to rock, and distinguish between different types of task ownerships.

doudou commented 9 years ago

I think it would be nice to record the pid of the processes that are spawned by orocos.rb in a file in /tmp, so that we could have a rock-killall to remove leftover processess from failed scripts. Also, this would provide a way to see which tasks belong to rock, and distinguish between different types of task ownerships.

The problem is to be sure that you keep it up to date ... which is pretty hard.

Tasks can already report their TID. We could make them report their PIDs as well, which would account for the rock-killall thing (list all tasks on name service, kill them, if the task is owned by somebody else you can't kill it)

goldhoorn commented 9 years ago

Why not creating a directory in /tmp with links to /proc, if a process got killed and the pid is not removed from tmp it does not matter because the corresponding entry in /proc dosnt exist also any more. so a rock-killall can cleanup also the structure. Even for deamons it happen that the daemon died and a entry is still existent.

On 15.01.2015 20:52, Sylvain Joyeux wrote:

I think it would be nice to record the pid of the processes that
are spawned by orocos.rb in a file in /tmp, so that we could have
a rock-killall to remove leftover processess from failed scripts.
Also, this would provide a way to see which tasks belong to rock,
and distinguish between different types of task ownerships.

The problem is to be sure that you keep it up to date ... which is pretty hard.

Tasks can already report their TID. We could make them report their PIDs as well, which would account for the rock-killall thing (list all tasks on name service, kill them, if the task is owned by somebody else you can't kill it)

— Reply to this email directly or view it on GitHub https://github.com/rock-core/tools-orocosrb/issues/36#issuecomment-70149767.

Dipl.-Inf. Matthias Goldhoorn Space and Underwater Robotic

Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany

Tel.: +49 421 178 45-4193 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: matthias.goldhoorn@informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

doudou commented 9 years ago

because the corresponding entry in /proc dosnt exist also any more

It might be reused. You would have to make sure that the PID is not the PID of a new process (as opposed to the one you want to kill) before killing it. Resolving using the CORBA interface would provide this.

Even for deamons it happen that the daemon died and a entry is still existent.

True, and it can get messy when it happens. This is why init systems try very hard to cleanup afterwards (and why the systemd guys prefer handling the PID handling internally instead of letting the init scripts do it).