fred
fred copied to clipboard
freenet
Update the tray (and possibly the wrapper) on Windows
This allows updating FreenetTray.exe and could also be used for updating the wrapper binaries. That is important because we may lose large numbers of Windows nodes due to Oracle moving JVMs from 32-bit to 64-bit.
It seems to work (though should be tested more widely), but has one serious bug: If the node takes too long to shut down, it may still be shutting down when the tray starts back up. If so, the tray won't restart it, and the node will stay offline until the user reboots (or logs out and in) or until they click on the rabbit.
So for nodes which take a long time to shut down - that is, nodes with plugins! - this could be a problem. On the other hand, users of such nodes are more likely to be active users, click on the rabbit regularly, and complain if it doesn't work.
Fixing this properly requires some means of waiting until the node has actually finished shutting down. The FreenetTray.exe does not appear to provide this AFAICS.
Also, note that this won't work unless FreenetTray.exe is in the nodeDir(). On old nodes upgraded via update.cmd, it might be in bin/. On really old nodes that haven't been upgraded it might not exist at all.
Note that it uses relative filenames so hopefully it will work on non-English installs in spite of problems with charsets and batch files.
This would work more reliably if we wait for the wrapper to exit. nextgens toad_ the standard windows way of waiting for a process to exit is to loop nextgens toad_ a la https://stackoverflow.com/questions/8177695/how-to-wait-for-a-process-to-terminate-to-execute-another-process-in-batch-file
-exit is not documented as waiting until the node has stopped before exiting the tray. Removing the anchor file means the node will shut down, which is sufficient. If you want to change that behavior I could do that, too.
On Mon, Mar 21, 2016, 8:55 AM Matthew Toseland [email protected] wrote:
This would work more reliably if we wait for the wrapper to exit. toad_> the standard windows way of waiting for a process to exit is to loop toad_> a la https://stackoverflow.com/questions/8177695/how-to-wait-for-a-process-to-terminate-to-execute-another-process-in-batch-file
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/freenet/fred/pull/520#issuecomment-199240488
Given the choice between changing the tray and implementing waiting for the wrapper in batch script I think changing the tray makes more sense. I'll do that.
Improvements addressing bertm's issues pushed. Also it will use the new FreenetTray.exe rather than the old one if it is updating FreenetTray.exe, which should be sufficient to make waiting for shutdown reliable given operhiem1's planned changes. However, the latest changes have not been tested yet.
This doesn't include a 64-bit wrapper binary? I can test parts of the tray without one, but not the entire setup.
Yes, I tested it by replacing the FreenetTray.exe with an older version of the executable (in the installer history I think). Then it should update it to the latest version, which is included in the dependencies.properties. This allows updating FreenetTray.exe. It should also allow deploying the new wrapper exe's (put them in the same deployment group with the mustExist flag set to false). IIRC when I was working on this I didn't have a 64-bit wrapper binary, somebody else was working on that.
The plan was to deploy the 64-bit wrapper dll and the wrapper exe separately from the 32-bit versions, and then have a new FreenetTray that uses the appropriate wrapper exe.
Right. The tray changes are implemented but not yet tested and pushed. My understanding is we do not yet have 64-bit binaries to work with. Is my recollection correct that @unixninja92 built them?
On Fri, Apr 8, 2016, 1:16 PM Matthew Toseland [email protected] wrote:
The plan was to deploy the 64-bit wrapper dll and the wrapper exe separately from the 32-bit versions, and then have a new FreenetTray that uses the appropriate wrapper exe.
— You are receiving this because you commented.
Reply to this email directly or view it on GitHub https://github.com/freenet/fred/pull/520#issuecomment-207522091
I have but it's based on code I downloaded from a random blog. I was going to recreate it and build it myself, but life has gotten really busy recently and haven't had a chance to yet.
We now have a 64-bit wrapper (thanks to work by @Thynix in 2018 that got it built). The changes here look like they could be important. Can these be finished so they are ready to merge?
