Designing a self-upgrade stratergy
This is a general design/programming question.
I have been given the responsibility to design the upgrade strategy for our product. The product is run on remote devices with no user interaction. So we have to achieve everything remotely.
The product basically has two daemons/services running S1 and S2. While S2 does all the work and S1 oversees S2. S1 periodically checks S2 and restarts it if it is not running etc.
Now I need to write a self-upgrading capability into S1. S1 has to check with a server and if an upgrade is available it will have to download it (lets call it upgradeFile) and execute it.
Before executing the upgradeFile S1 will stop S2.
upgradeFile, when it executes, will attempt to replace the S1-disk-executable-file and S2-disk-executable-file with the new versions it is carrying.
After the execution of upgradeFile is finished, S1 will restart S2.
Now I am very anxious of the fact that I am replacing the S1-disk-executable while S1 is running. With all the complexity of the loader and VM I am not sure if this is a good strategy.
I have checked the internet forums, books and I haven't found any articles talking about this. I don't even know if I am putting this question in the right forum.
Any help, advice or pointers to articles on this subject would really appreciated. Thank you.
I am currently programming on Linux Mint 14 and Qt 4.8. And we are also developing a new version for Android.
Re: Designing a self-upgrade stratergy
Hello,
I hope my post will be useful to you.
Well you have asked about the auto upgrade S1, and you have one issue Replacing the S1-disk-executable while S1 is running.
You may use the following steps for this.
1. Place a file with upgrade information like (www.example.com/myserver/upgradeInfo.txt)
1.1 upgradeInfo.txt contains: "1.0.1" in first line and "www.example.com/myserver/S1.executable" in another line.
2. if upgrade version is higher than the S1 version, then download the latest file from path (www.example.com/myserver/S1.executable)
NOTE : You have to implement a method in the installer if the S1 process is running then kill the process and install the rest.
AND YAY File is checked and replaced.....
CHEERS....
Re: Designing a self-upgrade stratergy
Kirankumar,
Thanks for your reply. But can give a flow of events in your scheme. Like who will invoke the installer and when? Its an remote and unmanned device.
sky.
Re: Designing a self-upgrade stratergy
Well its not "Kirankumar" , its "KaranKumar",
anyway, in my last post i have provided you a short idea about how to do auto update/upgrade a software program.
Well the flow is so simple.
Client app continuously check for an upgrade, whenever it got an upgaded version then another process will start which downloads the file and after download it close the existing running app and start installing it (Just like any other software .... "Firefox").
Re: Designing a self-upgrade stratergy
Sorry about that KaranKumar. The platform is Linux Mint 14. So I am worried that I will be creating a Zombie if the client spawns a process and dies. Can the child process kill the parent? If so what are the things I have to take care of? Should my child process delete the pid file in /var/run? How should the child process clean up so.. it does not remain a zombie? It is for questions like these that I am seeking answers for. Thank you.
Re: Designing a self-upgrade stratergy
Actually you are not going to create a zombie process because you start detached an another process. so as it is a separate process it can kill its parent and still remains parent...
Just go ahed and no worry about zombie coz all are alive here :)
CHEERS
Re: Designing a self-upgrade stratergy
Can you explain how to kill the parent process? I mean how would the child process know the parent pid to send a signal to it?
Re: Designing a self-upgrade stratergy
Well i dont know exactly how to do that....
According to my idea, you should pass the PID of the process to its child process when child process starts.
So, if child process have tha parent PID then it can kill the parent via system call ....
The idea is now clear.. child should track its parent process and kills after download of upgrade.
Now everything will be managed by the child.
Child process will be started as a separate process that means it is the parent process...
THANKS
;)