I am trying to edit files via SSH, but it keeps exiting while editing with the message "Killed". A search says it might have been because of system resources, or something. However, it is just nano editing a small file. The policy says that I may not:
Run any process that requires more than 8Mb of memory space, more than 30 CPU seconds, or use more than 5% of all available system resources at any time.
The only apparently relevant part is the second, which I don't understand at all. Could someone clarify this?
Full Version: Why killed?
You're right, your process was killed due to overusage.
If you need to run it constatntly pleas eopen a trouble ticket and put all application need to be executed there.
If you need to run it constatntly pleas eopen a trouble ticket and put all application need to be executed there.
It is true that while I try to avoid doing so, I will occasionally accidentially leave the process running, in which case it can be killed. However, it also will sometimes die only a little while after being opened, which usually happens at the same time as MySQL going down for a minute. Why is that?
Processes were killed to prevent server's resources overusage.
how much of a strain is it on the server to
be editing a file w/ a pico clone?
Either nano is as bad as MSWord (doubtful)
or the server is stressed and looking for any
non critical process to kill.
xemocne:
if you are windows user... try this for small edits.
http://winscp.sourceforge.net/eng/index.php
be editing a file w/ a pico clone?
Either nano is as bad as MSWord (doubtful)
or the server is stressed and looking for any
non critical process to kill.
xemocne:
if you are windows user... try this for small edits.
http://winscp.sourceforge.net/eng/index.php
DING DING DING DING! Give Atrocity a shiny new Cigar.. Hit the nail on the head there... The server is OVERLOADED and so its looking at any processes to kill that are not owned by root/www/or critical owners. This happens quite OFTEN on my server as well. Most of the time it happens when hostony is doing a backup and killing the server because they (for some godforsaken reason) can't figure out a better way to back accounts up. So they bring the server to 100% CPU for hours on end taking some servers completely offline to "backup"...
Jason
Jason
We can suggest you upgrade to VPS.
There are no such programs that kill proccess which are not owned by root.
There are no such programs that kill proccess which are not owned by root.
The quote from our terms
QUOTE
Users may not initiate the following on our servers:
* Run any process that requires more than 8Mb of memory space, more than 30 CPU seconds, or use more than 5% of all available system resources at any time.
* Run any type of interactive real-time chat applications that require server resources. Remotely-hosted services are fully allowed.
* Run stand-alone, unattended server-side processes at any point in time on the server. This includes any and all daemons, proxy servers, anonymizers.
* Run any software that interfaces with an IRC (Internet Relay Chat) network.
* Run any process that requires more than 8Mb of memory space, more than 30 CPU seconds, or use more than 5% of all available system resources at any time.
* Run any type of interactive real-time chat applications that require server resources. Remotely-hosted services are fully allowed.
* Run stand-alone, unattended server-side processes at any point in time on the server. This includes any and all daemons, proxy servers, anonymizers.
* Run any software that interfaces with an IRC (Internet Relay Chat) network.
Why would the server ever be so overloaded that something/one had to kill mysql (I think) and an editing session?
The reason of such overloading is that we always start making backups of all accounts on the server at the beginning of week.
Can't the bringing down of mysql be avoided?
Before I backup my forums, I always turn off my forums. To keep new info from coming in. Probably that's their reason? o.O?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.