Re: [OT] Re: Disabling (part of the) timers ?
Russ Allbery
> I am subscribed to several lists, and this is the only one for which
> hitting the 'Reply' button causes you to reply to the sender, not to the
> list. I have to hit the 'Reply All' button and delete the senders email
> address to send email correctly to this list.
> Is there anyone reading this who can correct this?
See:
<http://www.unicom.com/pw/reply-to-harmful.html>
for the reason why the list is not configured that way. I'm a curmudgeon
on this score -- I think people should get better software that
understands the concept of replying to the list, rather than overloading
the Reply-To header and making personal replies impossible for a client
that honors it properly.
Having been bitten many, many times in the past by the broken behavior of
mail clients that see fit to override Reply-To and send mail to the From
address against the mail standards, I have strong feelings about that.
That being said, really, the best solution is to have setting Reply-To be
a per-subscriber setting rather than a per-list setting. I'm pretty sure
Ecartis doesn't support that; I'm not sure if Mailman does.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Bill Tangren
> Bill Tangren <b...@aa.usno.navy.mil> writes:
>
>
>>I am subscribed to several lists, and this is the only one for which
>>hitting the 'Reply' button causes you to reply to the sender, not to the
>>list. I have to hit the 'Reply All' button and delete the senders email
>>address to send email correctly to this list.
>
>
>>Is there anyone reading this who can correct this?
>
>
> See:
>
> <http://www.unicom.com/pw/reply-to-harmful.html>
>
> for the reason why the list is not configured that way. I'm a curmudgeon
> on this score -- I think people should get better software that
> understands the concept of replying to the list, rather than overloading
> the Reply-To header and making personal replies impossible for a client
> that honors it properly.
>
> Having been bitten many, many times in the past by the broken behavior of
> mail clients that see fit to override Reply-To and send mail to the From
> address against the mail standards, I have strong feelings about that.
>
> That being said, really, the best solution is to have setting Reply-To be
> a per-subscriber setting rather than a per-list setting. I'm pretty sure
> Ecartis doesn't support that; I'm not sure if Mailman does.
>
I read this document, and I disagree with much of the premise. All I can
say is, from now on, I will be using the "Reply All" button (which I
guess is the equivalent of the 'g' button in the article, and the OP
will be getting two copies of my reply. Thanks for posting the link.
Christiaan den Besten
Sorry for that, meant to reply to the list .....
Just updated to STABLE-20050608, but I am still seeing "Jun 9 02:07:57 spool8 nnrpd[29749]: cache6.multikabel.net time 32740 idle
12561(15) readart 101(14) nntpwrite 19867(59)" in my log. So the timers are not diabled are they?
--
[root@spool8 etc]# grep timer inn.conf
timer: 0
[root@spool8 etc]#
--
That is what you meant to disable the timers right ?
bye,
Chris
PS: OS is Linux ia32, Fedora Core 3.
----- Original Message -----
From: "Russ Allbery" <r...@stanford.edu>
To: <inn-w...@isc.org>
Sent: Tuesday, June 07, 2005 8:52 PM
Subject: Re: Disabling (part of the) timers ?
(Please reply to the mailing list rather than to me individually.
Thanks!)
Christiaan den Besten <ch...@prolocation.net> writes:
> The first time I 'notices' the 'timers' were using more CPU than
> estimated was when Heith patched (as a request) the ovdb_server with the
> same 'timers' to see where it was spending its time. The server could
> barely serve more than 350mbit of feed (towards clients). After removing
> the timers again, we had no problem reaching 450mbit. So I decided to
> remove the timer from nnrpd and decrease the client-timeout check a
> factor (i++; if i>100 (now = time (); check possible timeout value;
> i=0)) etc... This did seem to decrease the CPU load.
> But you think we should have less overhead from all these 'gettimeofday'
> syscalls. nnrpd does a gettimeofday after each read/write sequence by
> default ... With 1000+ nnrpd's running probably makes some sence ?
It really shouldn't make a difference. If it is making a difference,
that's really a problem with your OS, I think, although some OSes
admittedly do have slow system calls. Tons of stuff uses gettimeofday.
That being said, I did incorporate a patch into STABLE and CURRENT that
would let you turn off the timer for nnrpd as well in inn.conf.
> PS: Are the patches for CNFS_BLOCKSIZE integrated into 2.4-STABLE or
> 2.4-CURRENT ? (or both or none ?).
If you're talking about the patch that zero-fills writes to CNFS_BLOCKSIZE
boundaries, it's in both STABLE and CURRENT.
Russ Allbery
> Sorry for that, meant to reply to the list .....
> Just updated to STABLE-20050608, but I am still seeing "Jun 9 02:07:57
> spool8 nnrpd[29749]: cache6.multikabel.net time 32740 idle 12561(15)
> readart 101(14) nntpwrite 19867(59)" in my log. So the timers are not
> diabled are they?
Snapshots aren't being generated off of Subversion currently. I'm afraid
that you either have to check out:
http://inn.eyrie.org/svn/branches/2.4
out of Subversion or wait a couple more days until I've finished the work
to generate snapshots.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.