Forums

I can't imagine anyone working with a Bash shell for any length of time without having some kind of ps capability. I know you have said that if PythonAnywhere were to give people ps access then everyone could see everyone else's process list. However, not having the capability to see one's own process list is simply not realistic. This can't be that difficult of a problem to solve.

Another question: if I have "killed" all my console windows how is it possible that a process that I started in one of the console windows is still running now even as I type this post? The way this system is supposed to work, per your explanation, is that if I kill a console then any processes associated with that console are stopped. So I have no consoles open, and haven't for almost 5 hours. Yet I have a process running? Bizarre. And btw, I know the process is running but since I can't display my process list I can't stop it.

Hi Cob,

I'm not really sure, you haven't given me much information about how you launched this process or how you know that it is still running. Did you fork it off the main console process? If you fork an infinite loop off and then kill the parent then of course it's not going to kill the child in that situation. If you tell me the process name I can kill it for you manually now.

I agree that we could certainly provide some abstraction of the underlying user processes with a 'kill' button next to each one. That sounds like it might be a useful feature for people. I'll add a ticket.

Hansel, thanks for your response. How can I send you an e-mail? In any case, the process I'm referring to resulted from a python script which I started yesterday morning and which should have been stopped when I killed (not closed) the console associated with it.

you can send email directly to the entire team at support at pythonanywhere dot com. Gets sent to all our mail boxes in case someone is away.

Cheers

+1 for a process tree. Ctrl+C and Ctrl+Break don't seem to transmit very reliably, so it's currently difficult to kill a stuck process.

Thanks, tjwarren -- I've upvoted that on our to-do list. In the meantime, if you want us to kill any of your processes, just send us a message via the "Send feedback" link at the top of any page when you're logged in, and we'll sort it out manually.

BTW what happens when you try to send Ctrl-C and it doesn't work? I've never seen it fail myself, but it's perfectly possible that we've got bugs in the works somewhere.

so why can't you create a custom version of ps that checks arguments for sensibility (like, my processes only, etc) and then calls the real 'ps' to do the job? Seems like just a few minutes of work?

Same with kill?

Thanks for thinking about it...

giles -- I've just tested it, and although it does seem to be reliable it can take a while for the Ctrl-C to make it to the stuck process.

For instance, if you create a program "busyloop.py":

for i in range(10000):
    print(i)

If you run this from bash (python3.2 busyloop.py), and immediately hit Ctrl-C, it will be several seconds (and many values of i) before the KeyboardInterrupt exception actually takes place (average i for 10 runs is 2194).

Further testing indicates it's likely just an I/O issue (if I put a time.sleep call into the above loop my Ctrl-Cs are handled pretty much immediately), so this is probably a pretty minor issue. It might be worth pointing out in the FAQ, though, similar to how you point out the work-around to the Ctrl-Shift-V extra character.

Thanks, tjwarren -- I see what you mean. What's happening is that the various in-memory buffers that sit between the various bits of code that sit between your code and the browser-based console are filling up, and when you send Control-C, it arrives in your code immediately but all of the stuff that was in the buffers needs to "drain" through to the console before you see the results. We obviously need to fix that somehow, and I've put something on our to-do list.

Greg -- sorry for the silence, I thought one of my colleagues was answering this one.

Unfortunately we can't do it the easy way:

• Your processes don't necessarily all run on the same machine, so a ps from one console won't necessarily pick up stuff from another, or indeed web applications, scheduled tasks, and so on.
• Even disregarding that, if we wanted to write something that could kill only processes started in the current console, a simple shell-script based wrapper would need access to the normal ps command. Because the wrapper would have to run in the protected execution environment that your own code runs in, then it would only have access to stuff that was in that environment. That means that the normal ps command would have to be there too, so we'd effectively be supplying a fully-fledged ps command. Of course, we could write our own ps ourselves from scratch, but that would obviously be non-trivial...

Anyway, what we need to do is write something that aggregates all of your processes from all our machines and makes it easy to kill them. It's definitely doable, but it's a reasonable amount of work -- so it's not at the top of the list right now. Still, the more votes it gets (and I've noted yours, tjwarren's, and cob's) then the sooner it will happen!

So in that case users can run ps in each of their consoles if need be. It's a heck of a lot better than the situation as it stands now. Your goal to make it easy for us to kill our processes is admirable but standing still now, in terms of making progress, is not. The user ps command would take minutes to implement as another user and I have suggested. How about making that happen? I'm beyond tired of the "orphan" process problem. And regarding your explanation about the protected environment obstacle(s), either you have programmed yourselves into a corner and can't find your way out or you need to rethink the situation.

Hi Cob -- as I said above, Greg's solution is sadly not something that can be implemented in minutes.

I do think my solution can be implemented in minutes (for a sufficiently large number of minutes) by usign the setuid bit in the usual way. Even if you have it disabled for scripts (not uncommon) you can still use it in a little console app.

I googled around a bit (pun unintended) and found this.

   http://www.tuxation.com/setuid-on-shell-scripts.html

Might be worth a look. Maybe not. :-)

(assumption: you're on a *nix platform of some sort. Seems like a safe bet.)

Looking forward to SSH!

(of course, the ps command has to be prevented from being run directly, so you have to set permissions appropriately on the ps command as well, to remove non-owner execute (and read and write) permissions. And maybe from the directory it lives in.)

Finally, since I am being a complete pain, if you want to you can just get the source for ps, remove what you don't want, and leave a subset program.

The source for linux ps can be found here: http://procps.sourceforge.net/

Ok, maybe we're up to a half-hour. :-)

Best wishes!

Hey greg, I don't think we're up for the challenge of hacking up a ps alternative, with all the /proc mangling it would involve, given the security and privacy implications of getting it wrong... Here's what I think we might realistically do though:

• in the medium/long-term: premium users will move to a different sandboxing model, which will include root access to a virtual system, and full bash controls, including ps

• in the short/medium-term: a web-based process listing / dashboard. And possibly even a web api for listing and killing processes.

We'll keep you posted!

I know this has been a while, but I ran into this (a need for ps and possibly kill) again today, and was wondering if any progress had been made?

Thanks!

(This is only within the context of one console session...)

There's still no ps, but we have built in a 'show my processes' button on the consoles page and the scheduled tasks page -- let us know if it works for you?

Cool. Haven't seen that. I'll take a look.

I still think my comments above about PS are worth trying; the console isn't available to shell scripts, for instance, but I understand it's a lot of work.

Thanks for the response!

Actually that web interface looks pretty nice. Thanks for that.

I think the ps thing would be nice to have because I do a lot of ssh connections that don't use the web site, but this is adequate for occasional use.

Best wishes,

-greg

Hi everyone, this isn't quite the "ps" command you're looking for I'm afraid, but if you check out our new beta docker consoles then you'll get a limited ps command. It'll only show you processes that were started from that same console, but you may find it useful in some cases. Let us know if you want to give it a try.

The "show process list" button on the consoles page is still the best single source of the truth for listing all your processes on all console servers (including ssh processes btw @greg)

Please add to the API a way to "show process list" and kill this processes.

Reason: Cleaning up manually is not a way how things have to be done in a big project. Users must have a way to kill they processes from code. For example, if Selenuim driver hangs forever (eating up CPU resources), it hangs the whole script. It have to be a way to show and kill processes using API instead of manually entering PA dashboard and clicking on buttons.

Thanks for the suggestion -- it's on our to-do list, and I've added an upvote on your behalf.