Currently, vdsm deamon script starts (respawn) vdsm process as vdsm user, and during that vdsm starts super vdsm process as root.
 * when vdsm dies, svdsm process supposed to notice and exit by itself.
* if svdsm dies, in the next proxy call by vdsm, vdsm supposed to start new svdsm instance after verifying that old instance is dead and call it.
This is super vdsm and vdsm startup design in general.

In current implementation we have some edge cases that we need to handle:
 * vsdm can try to communicate with old instance of svdsm.
* vdsm can kill wrong process that got last svdsm pid before starting the new instance of svdsm. * vdsm can try to communicate with svdsm before svdsm starts to serve requests.
And i guess there are many more possible senerios that can cause bugs..

As it seems, it doesn't make sense that vdsm manages root process, and can kill it..

What if svdsm will be the manager of vdsm:
 * deamon script starts up svdsm instance instead of vdsm
 * svdsm forks vdsm and changes its privilege (uid to vdsm)
 * vdsm receives as parameter svdsm pid for sudo requests
* when vdsm dies, svdsm will start new instance of vdsm automatically, and note the crash reason to syslog. * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its son process, and another instance of svdsm will start automatically and start new instance of vdsm.

Sounds like much correcter and easier to maintain design.

Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm user (check log permissions, clean old temporary files and so on if needed..)

Royce Lv has already started to work on such design here
I want to update it and push it forward.

I would like to hear more opinions and point of views on this change,


Yaniv Bronhaim.
RedHat, Israel
vdsm-devel mailing list

Reply via email to