<div dir="ltr">Hi Simon,<div><br></div><div>I've not read much of the background here (the majority of the previous posts seem to be around Puma, not MySQL?), but it looks a bit similar to a problem I've seen before due to MySQL killing idle connections.</div><div><br></div><div><b>Our problem</b></div><div><br></div><div>We had a monolithic Rails app which served thousands of requests per minute, but occasionally requests would take 15 minutes on a critical process for no apparent reason.  We ultimately pinned it down to the fact that we had a specific model which used it's own database connection (outside of the standard database pool).  I won't go into the reasons on that; let's just say it was necessary without a huge refactor.</div><div><br></div><div>When the app started up, it would initialise the main connection pool and this separate connection.  Due to the way we routed requests, 99% of the time we hit that model would be through 2 servers, and 1% would be on the other 5/6 servers (not exact ratios/etc, it's been a while now...).</div><div><br></div><div>Consequently, for that 1% of requests, after a certain amount of idle time, MySQL would drop the connection<font color="#ff0000">*</font> on the 5/6 because they weren't using the connection.  The servers, however, were not aware that the connection had been dropped so when a request came in they would try and make a request to the database.... which would time out after 15 minutes!</div><div><br></div><div>Why 15 minutes?  That was the long request timeout specified in our Passenger configurations, so after 15 minutes it would kill the process and spawn a new one.</div><div><br></div><div><font color="#ff0000">*</font> I'm not sure what the configuration is for MySQL to drop the connection, or even if it is configurable.  But be aware: MySQL will drop connections after a certain amount of idle time and your process that initiated the connection <i><u>will not know about it</u></i>.</div><div><br></div><div><b>How this (maybe!) relates to your problem</b></div><div><br></div><div>This may explain the reason that reducing the number of servers fixes the problem for you. Making a couple of assumptions:</div><div><ul><li>Only 1% of your calls use your extra database connections (utter guess on my part)<br></li><li>You're round-robbining requests to each server</li><li>You get 50rpm and you have 4 servers, so each server will process ~12.5rpm<br></li></ul><div>Then on average you'd only get <b>1 request every 8 minutes</b> that would keep these connections alive.  Given a real-life setup, it's not too far-fetched to imagine a server taking longer than 10 minutes (or whatever the MySQL timeout is) between having these requests.  Consequently, over a few hours, each of your servers would gradually drop out.</div></div><div><br></div><div>It would make sense then, if you reduced the number of servers to 1, you'd have <b>1 request every 2 minutes</b> on average; so you're much less likely to have a connection dropped.</div><div><br></div><div>This would also depend on your Puma configuration of course.  If it's not configured to kill processes which run over (say) 15 minutes, then it'll probably be unable to recover because, over time, all it's threads would get tied up in handling requests which will never end.  I have a vague feeling that there is no configuration for this on Puma but I may be completely wrong, it's worth looking for either way.</div><div><br></div><div>I hope that makes sense and is of some use (feel free to drop me an email off-thread if not, as this thread is getting quite long!) but hopefully this will give you another avenue to investigate.  Good luck!<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Ed</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 February 2016 at 11:17, Simon Morley <span dir="ltr"><<a href="mailto:simon@polkaspots.com" target="_blank">simon@polkaspots.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>An update, a request for more help. Hello LRUG.</div><div>-------------------------------------------------------------------</div><div><br></div>A month later, I'm still fighting this mean and cruel bug. (Puma dying, a gazzillllion CLOSE_WAIT connections bla)<div><br></div><div>Whilst it's been a generally miserable month, I have learned much, reduced the bloat, upgraded gems, Rails, discovered a memory leak, shorted our CI cycle, etc. I won't bore you.<div class="gmail_extra"><br></div><div class="gmail_extra"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Still suffering, we started moving individual end-points over to a separate set of servers (with haproxy). Within a few days, I'd found the culprit (I thought).</div><div><br></div><div>I installed rack timeout and this started throwing errors for a couple of the functions used by this end-point. All related with MySQL (actually MariaDB 5.5). </div><div><br></div><div><br></div><div>The naughty end-point also happens to call a separate db - used for our radius servers. In heavy use considering what we do. There were seemingly no issues with MySQL, no excess connections, no errors, nothing unusual. For good measure, we actually migrated the whole database to a new machine just to be sure.</div><div><br></div><div>The timeouts continued :(</div><div><br></div><div>I discovered we were using establish_connection in each of the 4 models that called this database. So, I refactored. Things got better (but weren't fixed).</div><div><br></div><div>class RadiusDatabase </div><div><div>  self.abstract_class = true</div><div>  establish_connection "radius_#{Rails.env}".to_sym</div></div><div>end</div><div><br></div><div>class Radacct < RadiusDatabase</div><div>end</div><div><br></div><div>Then I decreased our database pool from 20 to 5 and added a wait_timeout of 5 (since there seems to be some discrepancies with this). Things got much better (but weren't fixed).</div><div><br></div><div>I tried querying differently, including using <span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:12px;line-height:22.4px;white-space:pre-wrap">connection_pool.with_connection. </span>I've tried closing the connections manually and also used ActiveRecord::Base.clear_active_connections! periodically. No joy.</div><div><br></div><div>By this point, we were running 2-4 instances - handling around very little traffic in total (about 50rpm). Every few hours, they'd block, all of them. At the same time, we'd see a load of rack timeouts - same DB. I've checked the connections - they were each opening only a few to MySQL and MySQL was looking good.</div><div><br></div><div>One day, by chance, I reduced the 4 instances to 1. <b>And the problem is solved!!! WHAT</b>? Obviously the problem isn't solved, we can only use a single server. </div><div><br></div><div>I don't know what's going on here. Have I been staring at this for too long (yes)?</div><div><br></div><div><div>Our other servers are chugging along happily now, using a connection pool of 20, no errors, no timeouts (different db though).</div></div><div><br></div><div>Has anyone got any suggestions / seen this? Is there something fundamentally wrong with the way we're establishing a connection to the external dbs? Surely this is MySQL related</div><div><br></div><div>Thanks for listening, </div><div><br></div><div>S</div><div><br></div><div><br></div><div><div>Simon Morley<br><span style="font-family:arial;font-size:small"><br></span></div><div><div><div>Got an unlicensed Meraki? Set it free with Cucumber</div></div></div></div><div><a href="http://cucumberwifi.io/meraki" target="_blank">cucumberwifi.io/meraki</a></div><div><br></div></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On 15 January 2016 at 13:58, Gerhard Lazu <span dir="ltr"><<a href="mailto:gerhard@lazu.co.uk" target="_blank">gerhard@lazu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The understanding of difficult problems/bugs and the learning that comes with it cannot be rushed. Each and every one of us has his / her own pace, and all "speeds" are perfectly fine. The only question that really matters is whether it's worth it (a.k.a. the cost of lost opportunity). If the answer is yes, plough on. If not, look for alternatives.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Not everyone likes or wants to run their own infrastructure. The monthly savings on the PaaS, IaaS advertised costs are undisputed, but few like to think - never mind talk - about how many hours / days / weeks have been spent debugging obscure problems which "solve themselves" on a managed environment. Don't get me started on those that are building their own Docker-based PaaS-es without even realising it...</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">As a side-note, I've been dealing with a similar TCP-related problem for a while now, so I could empathise with your struggles the second I've seen your post. One of us is bound to solve it first, and I hope it will be you ; )</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Have a good one, Gerhard.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 10:01 AM, Simon Morley <span dir="ltr"><<a href="mailto:simon@polkaspots.com" target="_blank">simon@polkaspots.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">You must be more patient that I am. It's been a long month - having said that, I'm excited to find the cause.<div><br></div><div>I misunderstood you re. file descriptors. We checked the kernel limits / files open on the systems before and during and there's nothing untoward. </div><div><br></div><div>Since writing in, it's not happened as before - no doubt it'll take place during our forthcoming office move today.</div><div><br></div><div>I ran a strace (thanks for that suggestion John) on a couple of processes yesterday and saw redis blocking. Restarted a few redis servers to see if that helped. Can't be certain yet.</div><div><br></div><div>As soon as it's on, I'll run a tcpdump. How I'd not thought about that I don't know...</div><div><br></div><div>Actually, this is one thing I dislike about Rails - it's so nice and easy to do everything, one forgets we're dealing with the real servers / components / connections. It's too abstract in ways, but that's a whole other debate :)</div><span><font color="#888888"><div><br></div><div>S</div></font></span></div><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div><br></div><div><div>Simon Morley<br><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small">Big Chief</span> | PolkaSpots Supafly Wi-Fi<div>Bigger Chief | Cucumber Tony</div><div><br><div><span style="font-size:small;font-family:arial">simon@PolkaSpots.com</span><br style="font-size:small;font-family:arial"><div style="font-size:small;font-family:arial">Linkedin: I'm on it again and it still sucks</div><div style="font-size:small;font-family:arial"><a href="tel:020%207183%201471" value="+442071831471" target="_blank">020 7183 1471</a></div></div></div></div></div><div style="font-size:small;font-family:arial"><br></div><div><font face="arial" size="2">🚀💥</font><br></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On 15 January 2016 at 06:53, Gerhard Lazu <span dir="ltr"><<a href="mailto:gerhard@lazu.co.uk" target="_blank">gerhard@lazu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">File descriptors, for traditional reasons, include TCP connections.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Are you logging all requests to a central location? When the problem occurs, it might help taking a closer look at the type of requests you're receiving.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Depending on how long the mischief lasts, a tcpdump to pcap, then wireshark might help. Same for an strace on the Puma processes, similar to what John suggested . Those are low level tools though, verbose, complex and complete, it's easy to get lost unless you know what you're looking for.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In summary, CLOSE_WAITs piling up from haproxy (client role) to Puma (server role) indicates the app not closing connections in time (or maybe ever) - why? It's a fun one to troubleshoot ; )</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 11:35 PM, Simon Morley <span dir="ltr"><<a href="mailto:simon@polkaspots.com" target="_blank">simon@polkaspots.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Right now, none of the servers have any issues. No close_waits. <div><br>All is well. Seemingly.</div><div><br></div><div>When it occurs ALL the servers end up going. Sometimes real fast. That's why I thought we had a db bottleneck. It happens pretty quickly, randomly, no particular times.</div><div><br></div><div>We don't ever really get spikes of traffic, there's an even load inbound throughout.</div><div><br></div><div>I thought we had someone running a slow loris style attack on us. So I added some rules to HA Proxy and Cloudflare ain't seen nofin honest guv.</div><div><br></div><div>Will find a way to chart it and send a link over.</div><div><br></div><div>Will see if we're not closing any files - not much of that going on. There's some manual gzipping happening - we've had that in place for over a year though - not sure why it'd start playing up now. Memory usage is high but consistent and doesn't increase.</div><span><font color="#888888"><div><br></div><div>S</div></font></span></div><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div><br></div><div><div>Simon Morley<br><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small">Big Chief</span> | PolkaSpots Supafly Wi-Fi<div>Bigger Chief | Cucumber Tony</div><div><br><div><span style="font-size:small;font-family:arial">simon@PolkaSpots.com</span><br style="font-size:small;font-family:arial"><div style="font-size:small;font-family:arial">Linkedin: I'm on it again and it still sucks</div><div style="font-size:small;font-family:arial"><a href="tel:020%207183%201471" value="+442071831471" target="_blank">020 7183 1471</a></div></div></div></div></div><div style="font-size:small;font-family:arial"><br></div><div><font face="arial" size="2">🚀💥</font><br></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On 14 January 2016 at 22:14, Gerhard Lazu <span dir="ltr"><<a href="mailto:gerhard@lazu.co.uk" target="_blank">gerhard@lazu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">That sounds like a file descriptor leak. Are the CLOSE_WAITs growing over time?</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">You're right, New Relic is too high level, this is a layer 4-5 issue.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The simplest thing that can plot some graphs will work. Throw the dirtiest script together that curls the data out if it comes easy, it doesn't matter how you get those metrics as long as you have them.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This is a great blog post opportunity ; )</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 8:40 PM, Simon Morley <span dir="ltr"><<a href="mailto:simon@polkaspots.com" target="_blank">simon@polkaspots.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>I would ordinarily agree with you about the connection however they hang around for hours sometimes. </div><div><br></div><div>The 500 in the hyproxy config was actually left over from a previous experiment. Realistically I know they won't cope with that.</div><div><br></div><div>Using another server was to find any issues with puma. I'm still going to try unicorn just in case. <br><br>Will up the numbers too - thanks for that suggestion. </div><div><br></div><div>I'll look at a better monitoring tool too. So far new relic hasn't helped much. </div><div><br></div><div>Thanks</div><div><br></div><div>S</div><div><span><br><div style="font-family:Helvetica;font-size:medium">Simon Morley</div><div style="font-family:Helvetica;font-size:medium">Big Chief | PolkaSpots Supafly Wi-Fi</div><div style="font-family:Helvetica;font-size:medium"><br></div><div style="font-family:Helvetica;font-size:medium"><br></div><div style="font-family:Helvetica;font-size:medium"><br></div></span><div style="font-family:Helvetica;font-size:medium">I'm doing it with Cucumber Tony. Are you?</div></div><div><div><div><br>On 14 Jan 2016, at 20:30, Gerhard Lazu <<a href="mailto:gerhard@lazu.co.uk" target="_blank">gerhard@lazu.co.uk</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Simon,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">CLOSE_WAIT suggests that Puma is not closing connections fast enough. The client has asked for the connection to be closed, but Puma is busy.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Quickest win would be to increase your Puma instances. Unicorn won't help - or any other Rack web server for the matter.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Based on your numbers, start with 10 Puma instances. Anything more than 100 connections for a Rails instance is not realistic. I would personally go with 50, just to be safe. I think I saw 500 conns in your haproxy config, which is way too optimistic.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><font face="arial, helvetica, sans-serif" size="2">You want metrics for detailed CPU usage by process, connections open with state by process, and memory usage, by process. Without these, you're flying blind. Any suggestions anyone makes without real metrics - including myself - are just guesses. You'll get there, but you're making it far too difficult for yourself.</font></div><div dir="ltr"><font face="arial, helvetica, sans-serif" size="2"><br></font></div><div dir="ltr"><font face="arial, helvetica, sans-serif" size="2">Let me know how it goes, Gerhard.</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 3:16 PM, Simon Morley <span dir="ltr"><<a>simon@polkaspots.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello All<div><br></div><div>We've been battling with Puma for a long while now, I'm looking for some help / love / attention / advice / anything to prevent further hair loss.</div><div><br></div><div>We're using it in a reasonably typical Rails 4 application behind Nginx. <br clear="all"><div><div><div dir="ltr"><div dir="ltr"><div><br></div><div>Over the last 3 months, our requests have gone from 500 rpm to a little over 1000 depending on the hour. Over this period, we've been seeing weird CLOSE_WAIT conns appearing in netstat, which eventually kill the servers.</div><div><br></div><div>We have 3 Rails servers behind Haproxy running things. Load is generally even.</div><div><br></div><div>Running netstat on the servers shows a pile of connections in the CLOSE_WAIT state with varying recv-q values as so:<br></div><div><br></div><div><div>tcp      2784    0 localhost:58786         localhost:5100          CLOSE_WAIT</div><div>tcp      717      0 localhost:35794         localhost:5100          CLOSE_WAIT</div><div>tcp      784      0 localhost:55712         localhost:5100          CLOSE_WAIT<br></div><div>tcp        0        0 localhost:38639         localhost:5100          CLOSE_WAIT</div></div><div><br></div><div><div>That's just a snippet. A wc reveals over 400 of these on each server.</div></div><div><br></div><div>Puma is running on port 5100 btw. We've tried puma with multiple threads and a single one - same result. Latest version as of today.</div><div><br></div><div>I've checked haproxy and don't see much lingering around.</div><div><br></div><div>Only a kill -9 can stop Puma - otherwise, it says something like 'waiting for requests to finish'</div><div><br></div><div>I ran GDB to see if I could debug the process however I can't claim I knew what I was looking at. The processes that seemed apparent were event machine and mongo.</div><div><br></div><div>We then ditched EM (we were using the AMQP gem) in favour of Bunny. That made zero difference.</div><div><br></div><div>So we upgraded Mongo and Mongoid to the latest versions, neither of which helped.</div><div><br></div><div>I thought we might have a bottleneck somewhere - Mongo, ES or MySQL. But, none of those services seem to have any issues / latencies.</div><div><br></div><div>It's also 100% random. Might happen 10 times in an hour, then not at all for a week.</div><div><br></div><div>The puma issues on github don't shed much light.</div><div><br></div><div>I don't really know where to turn at the moment or what to do next? I was going to resort back to Unicorn but I don't think the issue is that side and I wanted to fix the problem, not just patch it up.</div><div><br></div><div>It's starting to look like a nasty in my code somewhere but I don't want to go down that route just yet...</div><div><br></div><div>Sorry for the long email, thanks in advance. Stuff.</div><div><br></div><div>I hope someone can help!</div><div><br></div><div>S</div><div><br></div><div><div>Simon Morley<br><span style="font-family:arial;font-size:small"><br></span></div><div><span style="font-family:arial;font-size:small">Big Chief</span> | PolkaSpots Supafly Wi-Fi<div>Bigger Chief | Cucumber Tony</div><div><br><div><span style="font-size:small;font-family:arial"><a href="mailto:simon@polkaspots.com" target="_blank">simon@PolkaSpots.com</a></span><br style="font-size:small;font-family:arial"><div style="font-size:small;font-family:arial">Linkedin: I'm on it again and it still sucks</div><div style="font-size:small;font-family:arial"><a href="tel:020%207183%201471" value="+442071831471" target="_blank">020 7183 1471</a></div></div></div></div></div><div style="font-size:small;font-family:arial"><br></div><div><font face="arial" size="2">🚀💥</font><br></div></div></div></div></div>
</div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a>Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Chat mailing list</span><br><span><a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a></span><br><span>Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a></span><br><span>Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a></span><br><span>List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></span><br></div></blockquote></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div></div></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>