Grex's staff and board ignores important member concerns in E-mail. I could sympathise with ignoring baseless or silly complaints, but that's not what I'm talking about: I'm talking about them ignoring important issues I've brought up in E-mail because I'd prefer not to discuss them in coop. Most of the times, I've been completely ignored. Have you ever read Grex's /etc/aliases? It's quite a doozy, quite complicated for a file like that. But what's the point, if mail sent to those aliases is ignored?35 responses total.
What's the point of GreX at all, unless you're considered "special"
BS. e-mail sent to staff of a legitimate nature sent by people not proven by themselves to be twits is treated seriously and is reponded to. Can you grok the implication?
I already explained I'm talking about reasonable complaints, and not just staff. Did you read what I wrote?
*yawn*
Staff is ignoring like crazy
Well, you drove away the one staff person most likely, by a large margin, to respond to any particular complaint. Otherwise, what albaugh said.
It was all my fault, I admit. That's why I asked for item 68 to be deleted. But look, it hasn't been deleted. Look who's the culprit now. The staff, as usual.
Actually, I think the staff member most likely to answer any message is Steve Weiss, who has not been driven away. However he usually processes mail only once a week and occasionally misses a week. I never read any staff email. I should check my grex-box. Oops 2013 new messages. Is that all?
The recent stuff is important
Not just staff, folks: board.
I don't usually mess with this stuff, but I took a very quick look at it. It looks to me like the locking of naftee's account was perfectly ordinary. Naftee had lots of pointless processes running that drove Grex's system load very high, making the system nearly unusable. The system was so slow, Joe had difficulty logging in. I believe he went to the pumpkin and got on the console to kill the processes. Killing naftee's processes fixed the problem. If I had some time to kill, I'd go look at what he was running in detail and try to figure out why robocop didn't kill it, but it doesn't particularly surprise me that it didn't. Robocop is really not that smart, and trys to err on the side of not killing stuff. I have no way of knowing if naftee was doing this to cause problems or had some sensible end in mind and just screwed up. Running "fortune" zillions of times with the output directed to /dev/null doesn't have any obvious sensible application, but it isn't exactly a normal vandal attack either. Only think I can say in his favor is that naftee does not have a record of doing this kind of crap. It might be reasonable to restore his account if he'll be more careful in the future.
(Yes, I had to go to the Pumpkin and use the console to log on to figure out what was happening.)
You really didn't. Grex was usuable, if incredibly slow.
From off-site, I only use ssh, which could not open a connection. After logging in from the console, I used telnet from another machine on the network and discovered that there was a queue, even with fewer than forty people logged in (I don't remember the exact number now). Yes, a visit to the pumpkin was required.
nope. i was able to use grex remotely just fine.
Bully for you.
I did manage to log onto GreX, but when I did a ps at the bash promt, I only recieved the output of two jobs. Therefore I assumed that whatever jobs I had before had ceased running and the high load averages were not of my doing. I was unable to run top and kill the processes myself though.
gelinas is just impatient, and you paid for the trouble his impatience caused.
I paid for the cost of a bug! At least janc mentioned he could look into the problem, as apposed to gelinas, who just likes to QUASH USERS
I hope janc finds some time to kill and puts some sensibility into this senslelessnes.
I'd like to know one thing gelinas has done as staff besides killing accounts.
21: Tough monkeys, bunghole.
Our staff is doing a wonderful job of remaining cool and calm and reasonable despite the baiting. Kudos, guys.
Actually Joe does lots of useful stuff, including killing users. Staff kills lots and lots of users. I used to do dozens a week when I was still active. I thank Joe for his efforts. If I'd seen an account running crap like that, I'd have locked it too. If it was a mistake on your part, then it is possible to rectify the mistake.
Killing users is a NEGATIVE action, even if it's necessary; it doesn't contribute to the system at all. What has gelinas done POSITIVELY? ABSOLUTELY nothing.
A hearty 'thank you' to all the staff who keep Grex functioning in spite of name calling, personally directed verbal abuse, and general negative feedback. I -really- appreciate the job you're doing.
This response has been erased.
Such as, jp2?
No! Don't respond! You're letting the trolls win!
Thanks Joe, for dealing with this.
Is it possible to set a limit on the number of processes any account can run at one time and if that is exceeded, to automatically kill them all? And generate a report so the account can be killed too?
re 24 How so, sir?
#31: that would be a resource limitation that grex probably does not support with such fine-grained detail, but experiences nonetheless through some robocop-ish thingy. say something? ^@ Stripping bad input: Too many bad characters say something?
Grex does impose a limit on the # of processes a user can use at one time, and has further logic to kill forkbombs. Grex does not have good logic to limit people's ability to run a small fixed number of things in rapid succession or otherwise more creatively increase system load. There's an expectation here that people will behave in a responsible fashion when it comes to shared resources, and that includes consuming the time of staff just as much as any other scarce resource.
TROGG IS DAVID BLAINE
You have several choices: