Run as unmonitored on Windows
Closed this issue · 12 comments
So my crunching setu is a Windows server PC with GUI, as I find it a easier to use the Gridcoin wallet GUI rather then have to do everything in a terminal. The purpose I want is to have the script be able to run itself on login, as I have Windows set to restart itself after applying any updates that need it.
My first thought was to create a bat file that runs main.py and put that in the startup folder, and then set SCRIPTED_RUN to True, so that way it doesn't pause on start waiting for user input. The running of the script worked fine, and it even defaults to displaying the output in a terminal window which is what I wanted/prefered. However an immediate problem was apparent, which is the script would put create and store its output files wherever it was run from. If that location is the startup folder then obviously this is not ideal. This seems to happen regardless of what the SCRIPTED_RUN parameter is set to.
Personally, I would say to always have to store its output files in the same directory as wherever main.py is located, or even you could create a subdirectory next to the script and store it all in there if you wanted to make it a bit cleaner. I'm not sure how to set the output directory myself though, as there doesn't appear to be a parameter in the confy.py to set it.
Another possible problem/oversight I found is when SCRIPTED_RUN is set to True, that regardless of how the script was run, in the Info section I get the message about consider donating via sidestake, which I have already done, and that gets picked up correctly if I run the script with it set to False, as it says in the user/pause prompt how its recognised that it has been done. I can't tell if it isn't able to detect the sidestake and is running the dev crunching, or if is just simply the message that appears when it shouldn't be, as everything is otherwise working as it should be.
In your batch file you need to set the working dir to the same dir with FTM in it. That should fix the files being written to the wrong places. FTM will just write files to whatever the current working directory is.
Can you set your logging options to 'DEBUG' in the user_config.py, re-run, and send me the log output (makeasnek{at}gmail.com) I can look into why it's giving you issues w the sidestake. And can you also send along whatever the exact text it is saying about the sidestake. Thanks!
I also released the newest version mere minutes ago, so make sure you are on the latest one :)
I also released the newest version mere minutes ago, so make sure you are on the latest one :)
Yeah I noticed as even when running the script, I saw it notifying me of there being a new version available, and when I checked the repo I saw you had just made some new commits. I'll download that and use it before trying again.
So good news, the recent changes you made seem to have fixed whatever the issue was with donation sidestake message showing up when SCRIPTED_RUN was set to True, but just in case I still sent you the output log file in an email if you still happened to want to look at it.
Also I got the batch file working by setting the current working directory before running the script which solved the issue of the output files. So I think that's everything then.
Awesome! Thank you for the bug report and doing some testing for me :). I updated the readme to make sure to direct users to cd into the directory instead of calling the script by absolute path.
Another possible problem/oversight I found is when
SCRIPTED_RUNis set to True, that regardless of how the script was run, in the Info section I get the message about consider donating via sidestake, which I have already done, and that gets picked up correctly if I run the script with it set to False, as it says in the user/pause prompt how its recognised that it has been done. I can't tell if it isn't able to detect the sidestake and is running the dev crunching, or if is just simply the message that appears when it shouldn't be, as everything is otherwise working as it should be.
Ah I just noticed the message pop up again, though in it's new format which specifically says how it is in crunch mode. I believe I might have narrowed down the cause, in this instance at least, not sure if it is the same as the old version but I suppose that doesn't really matter.
So the cause from what I observed and have been able to reproduce, is how if the script runs before the Gridcoin wallet has started/is still in the process of starting up. I have emailed you another log file, in which there should be a mention of not being able to connect to the wallet.
I've solved this by just putting a timeout in the batch file to wait 60 seconds before running the script, which appears to have solved the issue. I don't know how bad it would be running the script without it detecting the wallet, perhaps as part of the SCRIPTED_RUNprocedure, it could check to see if the wallet is initialised, and if not wait X amount of seconds and then try again, and maybe even terminate itself if it fails to find a wallet after y amount of attempts?
Hey Dave thank you for the log I just took a look through it. Can you send a copy of the exact text it's displaying and/or a screenshot? This will help me track down in the code where this is happening.
It makes sense that if the wallet is not running yet, it can't talk to the wallet and check the sidestake. But in that case it probably shouldn't ask you to setup a sidestake since as far as it knows, there is no Gridcoin wallet.
To answer your other question, if you run it without the wallet, it will just fetch the stats it needs from Gridcoinstats. If it can't connect to Gridcoinstats at startup, I believe the program will just exit as it has no way to calculate profitability. It will also then "crunch for dev" for whatever % of time is defined in the config, minimum is 1 but default is 5. Crunch for dev doesn't kick in till around 1,000 hours of crunching though.
Adding a delay is a wise move in terms of making sure the wallet is started first.
I do have a check in there where FTM waits until the wallet is fully synced, but there is no check for "is wallet starting up but not accepting RPC requests from FindTheMag" as I'm not entirely sure of a good cross-platform way to check for that,
Hey Dave thank you for the log I just took a look through it. Can you send a copy of the exact text it's displaying and/or a screenshot? This will help me track down in the code where this is happening.
It makes sense that if the wallet is not running yet, it can't talk to the wallet and check the sidestake. But in that case it probably shouldn't ask you to setup a sidestake since as far as it knows, there is no Gridcoin wallet.
In this instance yeah, that's pretty much all it is I think. The exact line that is showing though, both now, and the oringal issue in the last version is:
Consider donating to this app's development directly or via sidestake: RzUgcntbFm8PeSJpauk6a44qbtu92dpw3K. Sidestaking means you can skip crunching for dev.
Setting SCRIPTED_RUN to either True or False makes no difference here as you would expect.
In case it is useful, the full output is:
***********************************************************************************>
*Sleep reason: NONE *Info: Allowing new tasks & updating SRBase GRC Price: 0.008 *
When you started using this tool, your average mag/hr was: 0.1161 now it is 0.1237 That's an increase of 6.49%!
Hours crunched for you vs dev: 0.1|0.0 Dev fee mode: crunch
Consider donating to this app's development directly or via sidestake: RzUgcntbFm8PeSJpauk6a44qbtu92dpw3K. Sidestaking means you can skip crunching for dev
Use Ctrl+C to exit FTM and return BOINC to previous config
HOURSOFF= How far off we are between "intended" (based on weight) and "actual crunch time"
ATIME and ACTIME are average wall time and CPU time per task, totals displayed as WTIME/CPUTIME
RWTIME is wall-time crunched during window (default is 60 days). Windows help FTM track changes in how projects award credit
USD/DAY R/P is revenue and profit per day in USD. Uses electrical costs from your user_config.py
***********************************************************************************>
Aaah ok thank you. Those messages make sense given that the wallet can't be connected to. So actually I think everything here is working as intended.
I'll add to the roadmap for the next release to add a "exit if unable to connect to wallet at startup"
Aaah ok thank you. Those messages make sense given that the wallet can't be connected to. So actually I think everything here is working as intended.
In this instance yeah, it it would seem so. Still not sure about what the original issue was when I first opened the isticket but eh, doesn't matter now. 😅
I do have a check in there where FTM waits until the wallet is fully synced, but there is no check for "is wallet starting up but not accepting RPC requests from FindTheMag" as I'm not entirely sure of a good cross-platform way to check for that,
My first thought would have been to check for the exe but even that is not going to work, as the program would be running, just not loaded yet. RPC wouldn't even be working yet either as it wouldn't have reached the point where it gets turned on, so you're right I can't think of any good way to possibly do it either. The only I could think of is to have the script wait and/or exit if it can't detect the wallet running, but that would change how some people might want to use it. Perhaps adding an option like you said to have to wait and then close if it can't detect the wallet, and have it default to enabled, as anyone turning it off would then do so for a specific reason.