Forums

And from the 23rd to today the 26th its been continuing to do this [pasted at the bottom of the post]

I guess i have to refresh my credentials from looking at it, does that seem likely? Thats worrying, i should only have to do that once.

Is there any way i can prevent this script from eating 90%+ of my daily CPU allowance, should this script fail again?

Thanks

=========================================

[?1049h(B[?7h[?1h=(B(BGetting https://accounts.google.com/o/oauth2/auth?client_id=NONONONONONONONONONONONO(B Looking up accounts.google.com(B Making HTTPS connection to accounts.google.com(B Verified connection to accounts.google.com (cert=accounts.google.com)(B Certificate issued by: /C=US/O=Google Trust Services LLC/CN=GTS CA 1C3(B Secure 256-bit TLS1.3 (ECDHE_RSA_AES_256_GCM_SHA384) HTTP connection(Bnding HTTP request.(B HTTP request sent; waiting for response.(B/1.0 302 Moved Temporarily(B accounts.google.com cookie: NONONONONONONONONONONONO Allow? (Y/N/Always/neVer)(B[?1049h(B[?7h[?1h=(B(BGetting https://accounts.google.com/o/oauth2/auth?client_id=NONONONNONONONONONONONONONONONO(B Looking up accounts.google.com(B Making HTTPS connection to accounts.google.com(B Verified connection to accounts.google.com (cert=accounts.google.com)(B Certificate issued by: /C=US/O=Google Trust Services LLC/CN=GTS CA 1C3(B Secure 256-bit TLS1.3 (ECDHE_RSA_AES_256_GCM_SHA384) HTTP connection(Bnding HTTP request.(B HTTP request sent; waiting for response.(B/1.0 302 Moved Temporarily(B accounts.google.com cookie: NONONNONONONONONONONONO Allow? (Y/N/Always/neVer)(B Failed to start a local webserver listening on either port 8080 or port 8090. Please check your firewall settings and locally running programs that may be blocking or using those ports.

Falling back to --noauth_local_webserver and continuing with authorization.

Go to the following link in your browser:

https://accounts.google.com/o/oauth2/auth?client_id=NONONONONONONONONONONONONONONO&access_type=offline&response_type=code

Enter verification code: Failed to start a local webserver listening on either port 8080 or port 8090. Please check your firewall settings and locally running programs that may be blocking or using those ports.

Falling back to --noauth_local_webserver and continuing with authorization.

Here is my code up to the point where it breaks:

import os
import ezgmail

APIKEY =   os.path.expanduser('~/cleanerbasicprofile/apikey.txt')
TOKEN =    os.path.expanduser('~/cleanerbasicprofile/token.json')  
CREDS =    os.path.expanduser('~/cleanerbasicprofile/credentials.json')

ezgmail.init(tokenFile=TOKEN, credentialsFile=CREDS)

It seemed to drop into a text based internet browser. The first time i ran it to see what happened, i can't remember from where i launched it, it seemed to move from window to window automatically, like it was holding down the Enter key, and i saw some things like Lynx browser, which turns out is a Text based internet browser. I couldnt see the error messages or prompt screens properly because they seemed to move from window to window automatically, like Enter key held down etc.

I made a debug folder to test it, and it didn't do this again, but i couldn't get as far into the errors, to see them all this time, as i couldn't get past the bit where it was asking me to log in to Gmail.

Is Lynx a part of pythonanywhere, or must this coming from the ezgmail library?

Anyway, this thing probably was running round in circles, with the "Enter key held down" etc for hours before Error 137 from pythonanywhere.

Any idea how to prevent this from happening again?

One more, i searched the ezgmail repo for lynx and found nothing. Its a thing on pythonanywhere.

It probably added a lot of CPU expense to the error, and has possibly frustrated attempts to get eyes on the errors At least so far.

Has this been a problematic feature for PA users, reported on the forums? Is it popular or unpopular?

Why is it there?

Just for completeness, the error is caused by the token expiring after 7 days, because the project on google cloud is marked as testing, when it needs to be published not to expire.

So this will not recur once i publish and maybe reset token/cred.

So this comes down to the question of Lynx which was running on loop for 11 hours, for every hourly schedule, until the sheer amount of noise/memory generated by this order of magnitude of processing, became too much for PA's resource manager, i imagine per process...

I am a £5 a month user, and it was a days allowance, it seems like lynx should not loop like this, if thats what was happening, looking at logs, each ran for 44000~ seconds.

Can you handle stuff like this better?

Seems like reporting it could save someone from the tarpit in future if you did a fix for this situation. Its a very popular use case, the gmail api, and a common noob mistake, leaving the project in testing mode. Maybe its only the gmail api which lynx loops on, and you've never seen this bug* before.

Anyway, i dont think i need an admin to help me prevent this from happening in future, but its more like a bug report?

How do you run your code?

It was running for days via the task scheduler.

As mentioned in the original post, or maybe the first comment underneath it, i first tried to run the code from one place, then another, i am not familiar yet with the PA UI so i am not sure where.

But the issue was running for days and days from task scheduler. It was looping in Lynx from there, for 11 hours at a time per task. It looped once from another test (maybe a console, maybe a Run Script button) that was not the task scheduler. It did not loop from another location, maybe a console, maybe a Run Script button.

May i ask a second question while i'm writing this comment?

If its important, or not a commonly asked question i could make a new post.

I am testing another script. I ran it for the first time on a task scheduler. It expected os.getcwd() to be the project folder where the script is located. Instead it was the home folder.

Easy fix. But why is this? I would have thought the folder from which the script executes would be the same as the current working directory as python sees it.

You should not assume working directory. It's a matter of choice how stuff is executed.