Record pid of Orocos.run in filesystem

[jakobs]

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]

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]

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
#36 (comment).

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]

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).