I propose that a vote be put to the membership, as suggested by mcnally in agora, to remove the idle daemon. The reason being that the idle daemon serves no purpose anymore, since (a) grex is not resource constrained for pty's or CPU/memory capacity, and (b) the benefit it has of preventing preventing obnoxious behavior is easily subverted, and (c) there is no evidence that it stops anybody from doing anything anyway.88 responses total.
I'm not a voting member, which means it's probably not my prerogative to second cross's proposal that the matter be put to a membership vote, but I do think it would be a good idea to settle the matter by a vote.
i vote yes
What benefit is to be gained by eliminating the idle daemon?
Well, some of us like to sit in party waiting for someone to come along to talk to. It becomes annoying when you have to re-login every 15 minutes or so.
It provides a minimal increase in resources to other user processes, but that's not terribly significant. However, I think a better question is, what benefit is there to retaining it? I can't see any, and it's kind of annoying to get kicked off every 20 minutes. Even if you `touch' your terminal every few minutes, you still get kicked off after 10 hours, regardless if whether you're busy or not.
Grex should only restrict things insomuch as they are necessary to keeping Grex safe. IMHO.
I'm going to argue that a 15 minute limit (which is VERY short ; m-net's used to be an hour) will actually encourage people to use idle daemon killers. these small programmes put a stress on the system load, and would obviously not be needed for a system with no idle daemon.
Another resource that the idle daemon helps conserve is network bandwidth, at least for users who come in over the net. I've noticed at least once in the past week a time of definite slowdown, which may come from CPU or network load, so I think we're not totally past the days of limited resources. (One point: I believe it's actually twenty (20) minutes: fifteen (15) before the first warning, and then disconnect after five more.)
How much bandwidth does an inactive login use? Not very much, I would say. Maybe some packets every few minutes to make sure the connection is still active?
re #8: Bandwidth and CPU utilization from idle users is so negligible it wouldn't be noticable if you had 1000 users with idle sessions open.
Re #10: Is the bandwidth/CPU usage that would occur from idle users if the daemon were turned off less or more than the resources the daemon currently uses?
I don't know. How many idle users would we have if we turned the daemon off? There's no real way to tell except by trying it. It's not like one has to make an irrevocable decision on the issue. It could be turned off with an understanding that in a month or two if people aren't happy with the results it could be put to another vote.. If people are really concerned that it will really hurt the system direction can be given to staff to turn it back on if problems start developing. In my opinion, however, the thing to keep in mind, is that ideally direction on policy changes should come from the board or from the members, not from staff, and that continuing to do something the way we've done it just because we've always done it that way and don't know what the alternative would be like isn't a sound strategy for directing system policy.
Doesn't today's idle timer crudely enforce the policy against (outgoing) bots and servers, by periodically logging out users and thus killing all their processes?
I'm not sure to what extent that's controlled by "robocop" and to what extent by "idled"
#14: As I understand it, robocop only kills orphan processes, waiting for idled to kill the idle parents (the shell).
Mcnally addressed the resource usage issue. I don't think that kicking off idle users is really keeping grex safe in anyway, though I concur with nharmon that grex should have the authority to do what it feels necessary to keep the system ``safe'' (though by what metric you judge safety is an open question). As for `bots' and the like; (a) You need network access to, well, talk to the network, which is only something members have (other users have very limited network access; but that's not at issue here). (b) m-net turned off its idle daemon, and doesn't seem to have much of a problem. (c) those users likely to run annoying bots on grex that are targeted at grex can already circumvent idled. Therefore, idled doesn't really buy one much.
I vote yes.
Re #16: You need network access to talk to the network, but that doesn't stop them from building the thing, starting it up, testing it (it can talk to localhost, after all), and then going away.
Re 18. Robocop will.
(What Nate said.)
Re #19: As I understand it -- not without idled.
I have an opinion on this issue, but before I give I think I should point out that this is not a "vote proposal" in the strict sense because according to the bylaws, vote proposals have to be entered by members and unless there's been a recent change in his status that hasn't been recorded yet, Dan Cross isn't one. The bylaws specify timelines such as a two-week discussion period for proposals, but since this isn't a vote proposal, the clock hasn't started ticking yet. (See http://cyberspace.org/local/grex/bylaws.html and particular "Article 5: Voting Procedures". (The copy of the bylaws posted in this conference isn't up-to-date, so please refer to the web version.)) In the meantime, this is a discussion item, not a vote proposal. Which is fine - the idle daemon is certainly an issue that's appropriate to discuss in Coop. That said, I think this issue is a bit of a silly candidate for a member vote, as there's no data for members to make an informed choice. If even the technical staff can't agree, how can members be expected to have a reasonable grasp of the consequences of their decision? So I propose an experiment: Let's turn off the idle daemon for a trial period (two weeks? a month?) and see what the effects are. If serious problems emerge, we turn it back on. In any case, after the trial people will have an idea of the consequences and can cast an informed vote. Or the situation might be so clear-cut that there's no need for a vote. What do you think? Let's keep on discussing, but unless somebody comes up with some really show-stopper reasons for not trying this, I think I'll turn the daemon off myself two days from now and we can have our trial.
I agree with remmers. I don't have the information needed to make a decision on the idle daemon. Anyway, it's a technical decision and should be left up to the staff. His suggestion of a temporary test is a good one, provided the staff doesn't see a likelihood of catastrophic consequences. This item did give me another reminder to re-up my Grex membership, as a follow-up to aruba's gentle requests. I finally took care of it.
You're calling this a discussion item, and yet you say there's "no data for members to make an informed choice." ?? i think there's lots of data in this fine item, sir. Also, i like the trial IDea
Sounds good to me. No, I'm not a member.
I support remmers' recommendation.
Me too. Remmers' sense of taking charge is something we need more of on the BoD. Thank you Remmers!
You're welcome, although I was wearing my staff hat more than my board hat.
You can wear both hats at once. If one had the bill pointing forward, and the other backward, then perhaps you'd look something like Sherlock Holmes.
This response has been erased.
We could use the "silly hat fund" to buy Remmers a Sherlock Holmes hat. He would need a Calabash Pipe too, although he would probably just blow bubbles with it.
Heh. I agree with trying it for a while.
I actually saw a gentleman walking in town wearing a deerstalker hat the other day.
DID YOU SEE WHAT HE WAS WEARING ON HIS OTHER HEAD< AHAHAHA WHY ARE YOU PAYING SO MUCH ATTENTION TO WHAT MEN WEAR
I can lend my hat.
OTHER IS A BIG FAG ,.
OTHER IS A FIG BAG
AHAHA< MROE LIKE HE DOESN"T HAVE A FORESKIN BECAUSE A DEMONIC RABBI ( WHO WAS PRESUMABLY DRESSED UP LIKE A DEVIL AND NOT A TROLL BECAUSE IT WOULD BE HARD TO HIDE THE HORNS) BIT IT OFF AT THE BEHEST OF HIS PARENTS> AAHAHAH
I can relate
CHEWED UP AND SHABBAT OUT
FIB BAG HAHAHAH
AHAHAHA < FULL OF LIES AND USED FORESKINS
Turned off idled. Also commented out the code in /etc/rc.local that invokes it, so that it won't start if the system reboots. Let's keep our eyes open and see whether or not problems arise. I looked at the robocop source code to see if it depends in idled in any way. Apparently it does not.
can we then run 'screen' from work, go home and start again ?
Re #43: When I, at least, said robocop "depends on" idled, I meant that robocop wouldn't kill a process with a living parent, and so to prevent someone from running eggdrop, say, idled would kill their shell, and *then* robocop would kill the daemon.
Except a person trying to run eggdrop isn't likely to stay logged in after it doesn't work because of the network restrictions.
In the absence of idled, people can presumably run daemons that don't access blocked network services. But then, they could do that before by running them in conjunction with a (trivial to implement) idled defeater.
Thanks, John. This will be an interesting experiment.
By the way, uh, just for the sake of the item, the following is a shell script
you can run in the background to foil that nasty idle killer:
#!/bin/sh
while :
do
touch `tty`
sleep 59
done
I think I stole that from like jp2 or someone a million years ago, but it's
what I've used ever since, when I've had need for such a thing. :(
That script has been around forever. Like I said in #47, an idled-defeater is trivial to implement.
I think the idle zapper should stay because when a user is logged in and his computer crashes or he otherwise becomes a ghost, that ghost login won't go away unless its zapped. you could run a !who and see a zillion ghost logins because nobody on staff logged in to manually clean up the mess.
Normally, those `ghost' logins go away by themselves once the network notices that the connection is gone. Let's try this and see what happens. If it's a problem, we can act accordingly.
Re. 50: :(
Re ghost logins - they don't seem to be accumulating. I ran a small experiment: Logged in, put my computer to sleep (thus losing the network connection), came back a few hours later. I was no longer connected. Logged in on another terminal; my previous login was gone. So the system seems to be taking care of them.
Well, Idled has been off for a week now, and so far, nothing particularly bad seems to be happening. At my count a few minutes ago, about 13 logins that would have been zapped are logged in. Most of those have been idle for less than 3 hours. The ability to be logged in from more than one terminal is convenient.
Today marks four weeks since John Remmers turned off idled. I don't think there have been any major system problems; one person complained about lack of a TTY device on login, but I note that the upper limit for tty's seems pretty low right now (somewhere in the 40's). It seems that that limit should be increased, rather than bring back idled. As of right now, grex claims to have 45 users logged in. At least two of those are doing something with FTP; the rest are doing whatever it is that people do on grex. Of those, around half have been idle long enough that they would have been zapped. But, only about 7 have been idle longer than 3 hours. If we assume that some people go to sleep, wake up, and do their grex thing but just leave an idle shell open most of the time, that doesn't seem like a bad number. In my opinion, this experiment has been a success. Other comments?
For my own experience, I sometimes grex from work, where we have an application proxy that is very aggressive about timing out idle connections. The net result is that if I am distracted even briefly my connection gets terminated there, but it seems to take Grex a long time before noticing and removing the session. The upshot is that it's pretty easy for me to, if I'm not paying attention, be logged in several times "at once" because the other connections are no longer open on my end. This isn't a big deal for me; when I notice I can clean it up. I'm only mentioning it in case there might be others like me.
If it was a big deal, you could kill your other login processes Marc.
Um, yes, I'm aware of that, that's why I said I "can clean it up." Thanks.
Do you run screen?
I wasn't able to log in on Tuesday night due to used up tty's.
isn't tuesday night family time ?!
I'd like to bump up the tty limit and see what happens. It should be higher anyway....
i'm sure you do a lot of bumping in those friday night dance clubs, dan
What can I say? Your mom is a freak like that, son.
you're.... my mom ?!
And that wasn't breast milk, soup
oh my. that's why they told me milk is yellow
I'm getting "all network ports in use" errors when I try to telnet in. (Ssh was just sitting there, so I tried telnet to confirm my suspicion; this was posted via backtalk.)
All network ports, or all terminals? The two are rather different. At present, there are only about 42 people logged in, so I don't think it's the latter. Possibly, if grex is serving a lot of network requests (mail, the web server, etc) it can run out of endpoints for TCP connections, which would make telnet not work (nor SSH, for that matter) though that's rather different than running out of pseudo-terminals, which would be the case if there were too many idle logins, as you seem to be implying.
And, it is near impossible for grex to run out of the former (unless we are being DoS attacked).
"All network ports in use" was what telnet said.
Regarding #71; Oh, I don't know about that. I've gotten machines to run out of TCP PCB's pretty easily, usually by running a benchmark program or something against it. Regarding #72; I doubt it had much to do with idle logins, then.
I just assumed it was the same problem -- sorry.
That's understandable; no need to apologize.
i say kill it, aperantly the overall system idle killer is down due to i forgot about a grex session a few days back and nearly 24 hours later i was still here. the party thing is annoying as hell though. every 20 minutes? kill it or extend it to an hour or something.
Right, idle daemon has been turned off. If I recall correctly, one reason for implementing the party idle killer was to make it (marginally) more difficult to defeat the system idle daemon. Since the latter has been disabled, maybe the party idle killer should go too. What do other people think?
I have no problem with turning off the party idle killer. But I do think it would be crappy to see 15 people in party and be the only one talking.
That's the main reason I can think of for keeping the party idle killer.
would it be possibel to create some sore of idle notification? like User Started Channel fuzzball May 1 13:17:38 party nharmon May 1 00:01:19 party remmers May 1 13:48:58 party would be what you see and this is what would happen if say I was idle for a set amount of time: User Started Channel fuzzball May 1 13:17:38 party (IDLE) nharmon May 1 00:01:19 party remmers May 1 13:48:58 party
How would that help?
lets people know if they're going to respond or not
right. so if you popped into party and everyone was idle, its knowing they arent gonna chat right offhand. if you killed the idle zapper and had no notifications its the luck of the draw as to if yor gonna get a chat.
Party has its own idle timeout.
re:84 yea, i thought this was about getting rid of it.
No, this item was about getting rid of the *system* idle daemon.
oh, oh yea i guess it is..... still since its gone anyways, maby this needs to become a party idle zapper conversation
TROGG IS DAVID BLAINE
You have several choices: