Gridcoin-research: GRCRestarter force closing client despite being on latest version

[grctest]

This is the 3rd time I've experienced this with the latest client version, the grcrestarter believes that there is a more recent version of the client available (despite being on the latest version) and attempts to upgrade (windows UAC prompt - yes/no options both close the client).

I realize that the grcrestarter may make it easier for mandatory upgrades to go through, but i'd prefer to opt out of forced upgrades, especially when it shuts my staking client down.

Has anyone else experienced this?

[iFoggz]

hrm i think someone else mentioned this. anything useful in the grcrestarter.log?

so from what I see is every ~240 block timer the client enabled for a check for a upgrade.
runs CheckForUpgrade();
then checks for upgrade with a call to vb for ClientNeedsUpgrade();
omg im so not gonna repeat the numerous calls it does so lets get to it.

it checks the local and remote hash (md5) does not match it returns that it needs to be upgraded.
and does so. least thats my understanding of the process. so maybe there is a hash issue between local and remote.

u can suppressupgrade=true for now

[grctest]

Just had it happen again, posting all logs.

So I logged onto my windows machine, the grcrestarter is asking for UAC permission, I click 'No' and it closes my client fully.

Debug 2:

Jun 14 2017 00:20, Client outdated; needs upgraded[2].
Jun 14 2017 00:20, Found key AutoUpgrade 12/06/2017 06:12:54
Jun 14 2017 00:20, Ready for upgrade
Jun 14 2017 00:20, Restarting wallet with params upgrade

Debug (First instance of issue):

[DoTallyRA_START]  [DoTallyRA_END] 
06/12/17 00:39:20 {SBC} SetBestChain: new best=f9cfb8a715e05cf28847  height=924311  trust=3275838333972824660711873320762369734724920483558585417587755121813965410246  blocktrust=17683569863  date=06/12/17 00:38:56
06/12/17 00:39:20 {ACC}{PB}: ACC; 
06/12/17 00:39:20  {SVC} {Checking for Upgrade} socket sending timeout: 1201s
06/12/17 00:58:25 socket sending timeout: 1201s
            [repeating lines]
06/12/17 05:08:17 socket sending timeout: 1201s
06/12/17 05:09:08 Needs upgraded 1.000000
06/12/17 05:09:08 Executing upgradesocket sending timeout: 1201s
06/12/17 05:28:05 socket sending timeout: 1201s
            [repeating lines]
06/13/17 16:02:59 socket sending timeout: 1201s
06/13/17 16:13:26 Calling start shutdown...
06/13/17 16:13:26 {Done checking for upgrade} 
bitcoin.cpp:main calling Shutdown...
06/13/17 16:13:27 gridcoinresearch exiting...
06/13/17 16:13:27 Flush(false)
06/13/17 16:13:27 DBFlush(false) ended               0ms
06/13/17 16:13:27 StopNode()
06/13/17 16:13:27 ThreadSocketHandler exited
06/13/17 16:13:27 ThreadOpenConnections exited
06/13/17 16:13:27 ipcThread exited

Debug (Second occurrence):

[DoTallyRA_START]  [DoTallyRA_END] 
06/13/17 19:50:23 {SBC} SetBestChain: new best=7d351350280a95d3a5d2  height=926706  trust=3275838333972824660711873320762369734724920483558585417587755185816927163624  blocktrust=13450265960  date=06/13/17 19:50:40
06/13/17 19:50:23 {ACC}{PB}: ACC; 
06/13/17 19:50:23  {SVC} {Checking for Upgrade} socket sending timeout: 1201s
06/13/17 20:10:01 socket sending timeout: 1201s
            [repeating lines]
06/13/17 22:55:19 socket sending timeout: 1201s
06/13/17 23:16:06 Needs upgraded 1.000000
06/13/17 23:16:06 Executing upgradesocket sending timeout: 1201s
06/13/17 23:19:55 socket sending timeout: 1201s
            [repeating lines]
06/13/17 23:37:56 socket sending timeout: 1201s
            [five days go by in a broken state... wow i should have noticed waaay earlier]
06/18/17 21:57:39 socket sending timeout: 1201s
06/18/17 22:07:07 Calling start shutdown...
06/18/17 22:07:07 {Done checking for upgrade} socket sending timeout: 1201s
06/18/17 22:07:07 
Bootup
06/18/17 22:07:07 
bitcoin.cpp:main calling Shutdown...
06/18/17 22:07:07 gridcoinresearch exiting...
06/18/17 22:07:07 Flush(false)
06/18/17 22:07:07 DBFlush(false) ended               0ms
06/18/17 22:07:07 StopNode()
06/18/17 22:07:07 ipcThread exited
06/18/17 22:07:07 ThreadSocketHandler exited
06/18/17 22:07:07 ThreadMessageHandler exited
06/18/17 22:07:08 ResearchMiner:ShuttingDown..ThreadStakeMiner exiting, 0 threads remaining
06/18/17 22:07:09 ThreadMapPort exited
06/18/17 22:07:11 ThreadOpenAddedConnections still running
06/18/17 22:07:11 ThreadOpenConnections exited
06/18/17 22:07:11 Flush(true)
06/18/17 22:07:11 DBFlush(true) ended               0ms
06/18/17 22:07:12 Gridcoin exited
06/18/17 22:07:12 ThreadOpenAddedConnections exited

The second occurrence, the client was stuck outputting the following for 5 days (not staking)

06/12/17 00:58:25 socket sending timeout: 1201s

[iFoggz]

hrm the socket timeout likely the node or wallet connections. thats in net not a vb file least search says that. i still think the hashes are not matching for some reason so it keeps thinking it needs an upgrade.

[grctest]

Tried adding 'suppressautoupgrade=true' to my config file, grcrestarter again kicked my client offline. Is this the wrong entry for the config file? grcrestarter shouldn't be so aggressive.

Edit: The correct line is "suppressupgrade=true", i'll update you if it occurs again with this line added.

[3ullShark]

Auto upgrade is such a Microsoft thing to do. Why?

[iFoggz]

suppressupgrade=true

[tomasbrod]

Why?

For blockchain safety. It is important that security holes are plugged on supermajority of nodes fast.

[3ullShark]

Does Bitcoin have force upgrade?

By all means have a pop-up notification explaining that there is a new update with a link to the MSI but forced updates is just wrong.

[3ullShark]

This just happened to me.

[denravonska]

Should we disable grcrestarter for now and have people download the new version manually? When time comes we can add a more standard way of checking for updates.

[grctest]

I'd prefer that we scraped the github repo release page to compare versions, then providing a notification with the MSI download links or optionally upgrade the files via grcrestarter. Automatically throwing you to the UAC and killing the client can lead to long periods of client downtime.

[silent5am]

Just a thought: not all client updates are super important, right? Some updates are urgent because of security holes, others just implement new features.

There could be some sort of "update priority level indicator" that has like three levels: low prio, medium prio, high prio. Every update that is available for download will be flagged with one of these three, e.g. a security upgrade would receive the high prio flag.

The updater then can suggest to the user in what time frame the update should be downloaded, e.g. "High Prio update! It is advised to update your client within the next 24 hours" or "Low Prio update! Please update your client within the next 7 days."

Then there could be several options how to proceed, e.g. "update now" / "update in x hours" / "update in x days" - preferably letting the user manually pick the number of hours/days - and/or have an additional "update behaviour" setting that gives the user to set up X for different update priorities.

Something that should be ensured is that client auto-restart after update is applied correctly (if necessary).

[3ullShark]

Killing the running client is a bit cut throat.

I would feel better about the auto-upgrade if it happened like ClickOnce where it applied the update the next time the client started. However, I would still like the option to say yes/no to applying the update even if it's something that has to be added to the conf to enable the confirmation dialog.

With the way it is now I've set suppressupgrade=true in the .conf which has solved the bug (I mean feature) permanently.

[gridcoin]

We can fix the false positive signal where it thinks it should upgrade for one. Since the majority of nodes are windows, while we are still in beta, it is definitely valuable to have the feature.
Regarding 'cutthroat', we dont just kill the client. There is a thread that flushes the wallet, look in the stopnode area, that detects when the client is being killed. GRCRestarter sends the signal to kill the wallet in 10 seconds. Then the wallet exits gracefully. GRCRestarter has a busy wait loop waiting for the process to exit before it upgrades. So its the same as clicking exit, waiting, then upgrading the files.

[3ullShark]

I get that it's a valuable feature but the way it is now is just not expected behavior from any piece of software I've ever seen (other than the Windows OS which is controversial).

What if someone is in the middle of sending a transaction or building a transaction that took a lot of time to put together (lots of inputs and send addresses). It will annoy people when it shuts down.

Having a message displayed in the client that there's a new update, and have it auto-install on next start would be a lot more user friendly. You could even have a button next to the message that restarts it now.

[gridcoin]

I understand the concern- my only answer is : We dont have frequent updates, and it checks that flag on startup so its more likely that you havent started doing that yet- and yes, I agree if there is a better long term way we should do it. For now the benefits outweigh the risks -
There are a LOT of situations like this in Gridcoin, like the necessity to port the Neural network to c++, cosmetic features, ease of use for boinc integration- all competing for resources.

If you want an idea that works, the gitian builder system from bitcoin works, and does include a signed installer. The pro is the user can reinstall all of GRC with one click. The con is we will no longer have auto updates.

So for now while we are in beta, its still valuable to have the legion of windows at least upgrade the version to a supermajority.

[3ullShark]

Ok, you've sort of convinced me :-) but bear in mind there have been a few people in IRC complain about it.

Maybe making the updates happen on startup is something to think about in the future when it comes out of beta and updates are not as critical.

The Gitian Builder system looks interesting and a good way to prove that the final build is trustworthy.

[denravonska]

Auto upgrades are now disabled by default but can be enabled with the "autoupgrade" flag.