Forums

Hi guys,

I'm new to pythonanywhere.com. I've just tried to start a console (so far tried with python 2.7 and bash) and I just get the message: Starting unencrypted connection to consoles-1.pythonanywhere.com on port 80

This lingers on forever! Is there a possibility that my proxy is misbehaving in this handshake sequence?

Is there a way out? Has someone else had success accessing consoles vide a proxy?

Thanks in advance for the help!

-cruisemaniac.

Hi there,

We did have a server issue this morning, so that might have been the problem. Could you try again now and see if it's any better?

In general, connecting from behind a proxy should work, but it might be a bit slow -- depending on how capable the proxy is. Our consoles try to use WebSockets to connect back to our servers, which works really well, but I suspect that many (most?) proxies don't support WebSockets. If WebSockets don't work, the console will switch over automatically to using an HTTP-based polling system to communicate. This should work through pretty much any proxy, but is a bit slower and laggier.

Cheers,

Giles

I have the same issue on a network without a proxy. From an Ubuntu installed PC it appears fine, but with my ArchLinux installed laptop it is the same as above.

I have compared and aligned Firefox extensions between the 2 machines but cannot get it to work.

I would really love to get this working on my laptop as I will be supporting remote devs soon and this could really help.

Thanks

Craig

Thanks for letting us know, Craig. I'm setting up an ArchLinux VM now to give it a go, but in the meantime, which Firefox version are you using? Is there anything in the error console? From our server logs it just looks like your browser is connecting then immediately disconnecting, which makes me suspect it's a problem in our client-side code.

Giles

I have just tried this on another Arch machine and its working correctly, so the problem appears to be at my end.

I have placed the logs from Ubuntu and Arch FF at https://gist.github.com/2035602 any suggestions you could offer would be much appreciated.

Just zapped my .mozilla folder and now all seems well. Will let you know if I find a definitive cause of the problem.

I have discovered that if the Adblock plus extension is installed on my laptop, paw will not work.

The strange thing is that the same is installed on ubuntu with the same filter, without any problems.

Really glad you found the cause, other people who had the one line console issue also reported something to do with Adblock Plus... which is strange because we all use Adblock in the office as well. It would be great to pin it down to a specific setting that we could advise people to change. Giles is busily trying to install ArchLinux in a VM as I type this...

Follow up question - Which filter list are you using for Adblock? We have Arch Linux running in a VM and it still seems to work with ABP, presumably because we are using a different list or our settings aren't the same.

I'm using the default 'Easylist'. I have found that if I have the Adblock plus set to disable everywhere, it still wont work, but if I disable the extension in FF ad-ons it is OK. so I believe the filter is not the issue.

Hmmm... the plot thickens. Just a thought, do you have flash installed on either of these Linux distros? We use different transport protocols depending on what is available / supported by the users environment. Maybe ABP is messing with Websockets and Arch can't fall back to Flashsockets or something like that?

Flash is installed in all cases.

Do you know if adblock plus keeps settings anywhere other than the .mozilla folder. I can't see anything obvious.

I have just installed adblock plus on the other Arch machine, and it is happy.

I am having a similar issue in both Ubuntu 11.10 and Peppermint OS I am unable to start a console in either firefox or chrome with addblock plus enabled. Once addblock is disabled I am able to do so successfully. If there is a console already running I can use it with addblock enable just can't start a new one.

I'll pitch in if I can with debugging / testing if it will help.

Hi Jarrod,

Which filter are you using in adblock Plus?

I have tried with a completely new login on the Arch machine. The problem remains for the new user with adblock plus extension enabled. Seems to be an environmental issue, but sadly not local to my home folder :(

I'm using the default filters for adblock which seem to be EasyList in firefox, and EasyList + Fanboy's List in Chromium.

If there is any information that ABP gives you when it does cause the problem that would be great. I can see that there is an option inside the ABP menu item to report that it is blocking too much stuff on a certain page. Might be worth people doing that.

On our end it is stubbornly refusing to break on any different combinations of Chrome, Firefox, Arch Linux, and Ubuntu. Damn it!

I have installed the adblock plus diagnostic tool which revealed that nothing was being blocked.

I have reported this issue with adblock plus.

I am of the belief that there is a library version or application conflict somewhere, but I have no clue how to start looking into this further.

Any ideas welcomed.

Well you're not the only one that has reported the problem. I guess the problem with us trying to replicate it on Arch is that the setup can be unique.

Thanks for taking the time to have a look through the diganostic tool and reporting the problem. Much appreciated.

Cheers

I have recently updated to Firefox 12 with adblock plus enabled, dont know why but it all seems happy now. :D

Weird... we'll keep looking into it, but good to hear it works again!

I have Adblock Plus both on Firefox and Chromium -- PAW had worked fine with unencrypted connection via port 80.

However, today with the changeover to encrypted connection via port 443 -- js is broken on Chromium (continuous attempt to unsuccessfully connect) while js is very slow to load on Firefox (sometimes going through old screen states).

[BTW, latest stable versions for both browsers.]

Hm - one other person has reported that the switch to port 443 had caused issues. We'll look into building a fallback mechanism, whereby it tries 443/secured first, and then fails over to 80/unsecured...

Now operational on Chromium @1335718522 ... thanks. [The people who do not report issues are the ones who will log out and move on. That's worrisome because the cause of their disappearance will be invisible. :-]

Noticed also Giles' embedded console on his blog now works too on encrypted connection. That's cool, here's the code: <iframe style="width: 640px; height: 480px; border: none;" src="http://www.pythonanywhere.com/embedded/"></iframe>

Another mysteriously ended process for me. Another day another issue.

Hi cob,

Looking at our server logs, we had a restart yesterday evening on the server that was running your consoles. Unfortunately we have to bounce the servers every 2 or 3 days for maintenance; we also have to switch off the old servers whenever we do a new release. The upshot is that, currently, we can't guarantee that long-running processes will stay up forever.

We do plan to make some changes to the infrastructure in future that should allow for much longer-running processes, but that's probably in the medium-term rather than in the short-term. For now, if your requirement is to be able to "leave a process running forever", I'm afraid we can't support that.

hey rsvp, good to hear that Chromium is behaving again, also glad you like the embedded consoles!

Harry-I don't know where you came up with the idea that I want "to leave a process running forever". I start a process sometimes and go to stop it some hours later and it's already been stopped somehow-I suppose through the process you described. On the other hand another of the problems I have had here is that I sometimes start a process then later try to stop it and the system tells me that the process doesn't exist. Yet I can tell that the process does; one of the strangest situations I have ever seen BTW. This has happened a number of times and I have reported it to you guys. Obviously, since you can't figure out what is causing the problem you guys are still working out all the implications related to the underlying concept/structure of PythonAnywhere. For troubleshooting purposes, it would be helpful if we as individual users could do a simple 'ps' and be able to see what the system is reporting for each of our running processes. But you guys haven't yet reached the level with your product evolution where you can provide that functionality. BTW, this should be a basic capability that comes with any "Bash shell" product.

OK, I think we're narrowing things down - there are two problem cases:

1: you start a process, come back a few hours later, and find it's already been stopped. I think we've identified the cause for this problem, ie it was due to one of our site upgrades or maintenance reboots.

2: you start a process, come back a few hours later, and find that you cannot kill it, and the system tells you it does not exist even though you are sure (somehow) it is still running. This is a mystery.

Let's do this - next time you find yourself in situation 2, let us know immediately, and we'll try and debug the problem together. We'll have to go into detail of what the process was, what exactly it was doing, and how you can tell it is still running, so if you want to discuss that stuff in private, let's have the conversation by email. You can reach us at support@pythonanywhere.com

Sounds good on number two however I'm in the US and you are likely in Europe so when I'm on you may not be. I'll try anyway to contact you the next time it happens.

On number one could you give us some idea of when you will be doing upgrades or other similar work? I just had another process killed at some point this a.m. with no warning. Thanks.

Hey, re no 1's, we announce our scheduled upgrades via twitter a short while ahead of each ones. On the maintenance reboots, they're a temporary fix while we overhaul some of the infrastructure, but until we get that finished, they're going to be unpredictable I'm afraid... We'll keep you posted on how the infrastructure work goes. Will wait to hear from you if we see problem 2) again.

Just some observations and a tip: after numerous calls to vim (which needs to "repaint" the screen after edits), the browser window which contains the console seems to get deeply clogged (since the underlying code must account for screen states). This seems to account for the long (sometimes indefinite) delay in getting connected.

So try closing that browser window, and then reopen it from Dashboard to clear out the muck.

The difference between Firefox and Chrom{e,ium} seems to be that Firefox can tolerate more muck but at the cost of execution speed. Given a clean slate, Chrom{e,ium} seems to be more responsive.

Let me know if this concurs with your experience.

Hi rsvp -- how long a session is needed to cause this? Some of the other guys on the dev team use vim in a console all day while we're developing PythonAnywhere (I use the in-browser editor) and I don't think they've mentioned anything like this. But maybe they're using it in a different way in some manner.

Just to make sure I understand what you mean: when you say "the long (sometimes indefinite) delay in getting connected", contrasting it with the effects of closing and then re-opening the window, you're saying that you get this problem if in a clogged-up window or tab you go back to (say) the dashboard page, and then forward to the console window again -- sometimes to the extent that when you go back to the console window, it never connects. But if you close the tab, then go to the dashboard in a new window, you don't see it. Is that right? If so, are you going back to the console by hitting forward, or by clicking on the link in the dashboard? Or are you not going to the dashboard at all, but clicking the refresh button?

Either way, it all sounds very strange, and clearly we need to sort it out.

Re: "the long (sometimes indefinite) delay in getting connected" seems to especially occur after one shuts down the browser, then when the browser is restarted with an old tab containing the former console session, the browser tries unsuccessfully to resolve the old muck. It seems that as long as the console session is continuous, things are fine. The problem can be reproduced sometimes during a single session if the refresh button is hit (not advisable during vim editing). The command "clear" to clear the screen is helpful.

The key is to remember that a console can always be revived from the Dashboard. (This must be true, for otherwise a given console could not be shared.) Don't get attached to any particular tab for long.

I do not know what the browser is caching in terms of screen states, but really only the current state matters. Thus to expand on my tip: close the tab containing console when shutting down the browser -- to start fresh the next time, go to Dashboard, then open that console.

it looks like your security certificate is not valid. this cause problems with connection to the console. unfortunately i was not able to connect ....

Hi Borisvish,

It is a valid certificate from RapidSSL. However some browsers don't bundle that root cert. If you visit the console frame you can make an exception for it and should be able to connect.

Cheers

Hansel

Hi Hansel, could you please give more details how to do it. Was trying latest Chrome and FF 12.0. Result is the same. Could not connect waiting for an hour. Where Should I go to make exception? BTW Google show's warning for your you site as unsafe.

I was able to connect using latest Mac OS, however using OS X I could not. I could not connect from work (firewall?) using win xp

You can create the exception by visiting https://consoles-1.pythonanywhere.com/ in your browser.

The unsafe site warning is a bit more worrying. Thanks for letting us know and we'll have to investigate. What exactly does it say and where are you seeing it? Is it a popup from Chrome itself?

Thanks for all the info so far btw.

with OS X 10.5.8 chrom is shows ssl error and give warning of danger to proceed. with Win XP at office I have corporate firewall. I check and could see it blocks http://consoles-1.pythonanywhere.com/

Hi Borisvish,

Actually that may be a mistake in my response. I put "http" instead of "https". I've corrected the link now. Thanks very much for reporting the problem. I think your OS does not have the root cert for RapidSSL unfortunately. Which is why it is throwing that error :(