-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto client reboot function #483
Comments
I have rethought this (see here) and with daily, weekly, ... and a notice to users it might be helpful indeed, but I'd per standard let it in options until a user enables it (so she knows what she actually enables).
"the number of forking events":
|
Not at automatic function. A user function for individuals who do not sit and monitor their clients. If you read the main thread, a number of users commented on having to reboot their clients after a fork, in order to resync the client. Some of the users only monitor their clients periodically. A manual function to allow a one off reboot would address their concern over having to hover over the client to ensure it is synced after a fork event. |
The code shoul be made so the reboot is not needed. The fact that reboot is needed is indication of programming error or ba design. Auto reboot is just a workaround. Moreover it is impossible to determine when reboot is needed due to Halting problem. |
A MANUAL USER FUNCTION. For users who let their clients run without monitoring them on a full time basis. Some users have mentioned that they lose time staking or mining when a fork happens when they are away doing something.. A manual setting to allow a auto reboot would address the problem. As to the myriad of other functionality issues, I have already voiced an opinion as to how a stable and functionally client would be the best advertising for GRC. |
I'm not sure a reboot would be enough... you have to make sure you're on the right chain and stuff after/during a fork. |
An auto-reboot would be detrimental to the network, if such a 'fork' event was detected, if everyone's client was to reset then the majority of users who don't use auto-unlock would cease staking until they manually unlock their client, further decreasing staking participation. |
Along with a myriad of other notable gremlins that already exist. A number of long time users mentioned this on https://cryptocurrencytalk.com/topic/1331-new-coin-launch-announcement-grc-gridcoin... That their client requires to rebooted after a fork event. And that some users do not sit and monitor their clients and come back surprised by a fork event. Which I gather also results in loss of staking and which is rectified by rebooting the client. We have a medicine chest worth of other band-aids and workarounds, some of which befuddle new users and create negative commentary. It's simply a suggestion. Personally I have had my client hosed up during some the growing pain events, lost staking, lost coins, 0 mag, missing super blocks, missing projects, etc. However I have been on Boinc since 1999 and consider GRC a worthwhile endeavor. Kill off all of the gremlins and the client will sparkle and shine, right now it is not for novices or the faint of heart. |
windows users have reboot option for wallet not linux. |
Should we try to make the linux wallet reboot too? In the light of windows and linux feature parity? On the pro side, the wallet could automatically reboot if you encrypt your wallet. @denravonska what do you think, feature or ballast? I think we should remove it completely or try to make it work on all platforms. I could look into it if we want it to work on linux too. Oh, I am talking about the reboot function in general, not automatic reboot after x amount of time or something like that. Thats a bad idea. |
@skcin I think the current implementation should be replaced with something portable. We still need it for upgrade procedures but we probably shouldn't allow for it through RPC calls. |
I don't think automatic upgrades work on windows. I have suppressupgrade=false in my config but the last reported upgrade was mid July which is probably why I ended up on a fork last week. |
Recent versions shouldn't require reboots and if they do we need to focus on fixing the causes instead. |
Given the client can autolock for staking, and given the number of forking events that require the client to be rebooted to resync after a forking event, it might be a useful feature to enable the client to reboot via set timer.. e.g. once a day, week, biweekly, etc.
The text was updated successfully, but these errors were encountered: