[Toolserver-l] Burnbridges question

[Russell Blau]

I wanted to clear out the files of an MMP (named dpl), so I used
"become" to switch to the project's account, then ran "burnbridges." 
This generated a nice, red message saying "You do not have an .htaccess
with Redirects to wmflabs.org !!! "

So, I checked:

dpl@nightshade:~$ cat public_html/.htaccess
Redirect permanent /~dpl http://tools.wmflabs.org/dplbot

Should I just ignore the message and complete burnbridges anyway?

-- 
  Russell Blau
  russb...@imapmail.org

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] MySQL problems?

[Russell Blau]

MySQL servers seem to be unresponsive.  On willow, both "mysql -h
sql-s1-user" and "mysql -h sql-s1-rr" hang for extremely long times.


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] SQL S1

[Russell Blau]

On Jun 3, 2013, at 6:21 PM, "DaB."  wrote:

> Hello,
> At Monday 03 June 2013 16:20:52 DaB. wrote:
>> I am getting a ERROR 2003 (HY000): when trying to connect.
> 
> fixed. Tested also the other connections and found no problems there.

russell@willow:~$ mysql -h sql-s1-userERROR 
2003 (HY000): Can't connect to MySQL server on 'sql-s1-user' (146)

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] Running Pywikipedia (rewrite) bots on Tools Labs

[Russell Blau]

For any users interested in migrating Pywikipedia-based bots from the
Toolserver to the new Labs platform, or just interested in using Labs to
run bots, I've written a page[1] describing the steps I took to get my
bots running under the rewrite branch.

If someone who uses trunk has gotten their bot(s) running on Labs, feel
free to add instructions for that process, too.

[1]
https://wikitech.wikimedia.org/wiki/User:Russell_Blau/Using_pywikibot_on_Labs

-- 
  Russell Blau
  russb...@imapmail.org

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Status of the toolserver

[Russell Blau]

On Mon, May 13, 2013, at 05:01 PM, DaB. wrote:
> The repairing of the ha-nodes has top priority, so everything else will
> be delayed (linux-update, database-reimports, account-creation (for VERY 
> important ones send me a mail), etc.).
> 
> If you have questions, please send them to the ML.

Is the current outage of replication on sql-s1-user (now approaching 48
hours) related to this ha-node problem?  At least some other dbs seem to
still have replication working.

-- 
  Russell Blau
  russb...@imapmail.org

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] enwiki_p

[Russell Blau]

On Sat, Mar 23, 2013, at 01:31 PM, DaB. wrote:
> 
> While we speak of enwiki: The import of commons on the new server is
> done. By 
> Sunday or Monday evening we should have a complete and up2date sql-s1-rr 
> again.

Is there any update on this?  AFAICT, sql-s1-rr is still pointing to
rosemary (same as sql-s1-user).

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] S1

[Russell Blau]

On Sat, Nov 17, 2012, at 05:32 PM, DaB. wrote:
> Hello,
> At Saturday 17 November 2012 23:23:34 DaB. wrote:
> > do we have an updated ETA on a non-corrupt s1?
> 
> we were not able to reach Mark or someone from the datacenter yet for a
> reboot of thyme. When thyme is rebooted we have to announce the 
> read-only-switch
> of s1 ~24h in advantage. Than it will take a unknown time to dump and import
> the user-databases.

Any further news on this?

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] s1 replag update, suggestion, and question

[Russell Blau]

On Fri, Aug 10, 2012, at 03:42 PM, Carl (CBM) wrote:
> 
> Just to see if it makes any difference I killed the running WP 1.0
> process on thyme.  Right now the replag seems to be decreasing at a
> tiny rate, less than 10 minutes per hour.  There are 411 hours of
> replag.
> 

Carl, that is a good idea and I've stopped all the scheduled dpl project
jobs that usually run on thyme, for 24 hours, to see if that helps.  If
anyone else could temporarily shut down their tools to help reduce the
load on the server, maybe we can all help improve the recovery rate.
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] s1 replag update, suggestion, and question

[Russell Blau]

On Wed, Aug 8, 2012, at 11:59 AM, Platonides wrote:
> 
> Depending on the insert speed without queries, another option would be
> the time needed for copying the db from rosemary to thyme.
> (I'm assuming it would be much slower than the downtime moving user
> dbs but it's just a guess, if it weren't this could replace that
> move).
> 
Well, based on the overwhelming response to my last message, I guess
nobody but me cares if thyme is lagged by three or four or five
weeks

Thyme finished processing the updates in the second block a few hours
ago, but the replag is continuing to increase. This is very worrisome,
and possibly there is something else going on there that the SHA-1
updates have been masking.  All the TS admins seem to be on summer
holiday; is there anyone around who has mysql root access and can look
for problems on thyme?

-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] s1 replag update, suggestion, and question

[Russell Blau]

On Wed, Aug 8, 2012, at 11:35 AM, Daniel Schwen wrote:
> I'm a little confused as to which DB server we are talking about. I
> need access to
> 
> enwiki-p.db.toolserver.org
> hap-s1-user.esi.toolserver.org.
> 
> is that sql-s1-user or sql-s1-rr or what?
> 
> Daniel

Daniel - there are two copies of enwiki-p; see [1] for details.  If you
need access to any database whose name starts with "u_" or "p_", you
need the sql-s1-user copy.  If you *don't* need access to those
databases, you ought be using the sql-s1-rr copy and you are degrading
the performance of your application if you don't.

The address "enwiki-p.db.toolserver.org" points to the sql-s1-user copy,
and is deprecated; you ought to be using either
"enwiki-p.rrdb.toolserver.org" or "enwiki-p.userdb.toolserver.org"
instead.

[1] https://wiki.toolserver.org/view/Database_access
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] s1 replag update, suggestion, and question

[Russell Blau]

(TL;DR? Skip down three paragraphs to the possible workaround)  Last
month, I reported on the progress of SHA-1 updates from the WMF servers,
and noted that s1 replag was likely to continue to be a problem for a
number of weeks.  As I said then, the WMF was using (at least) three
processes to populate the SHA-1 field on three separate blocks of
revision records.  All these changes then were being replicated to the
Toolserver's copies of the databases, and this flood of updates was
causing the replag.

The three blocks were being populated at different rates (for reasons
that are beyond my knowledge). On July 23 at about 15:00 UTC, rosemary
(sql-s1-rr) completed updating the first of the three blocks. The other
blocks continued to be populated (and at some point the WMF started
another process to help finish off the slowest block), but the rate of
updates was somewhat less, and rosemary actually caught up on its
backlog and reached zero replag within about a day after this milestone.

The situation on thyme (sql-s1-user) is less favorable, as we all know.
The replag on that server got much higher to start with, and thyme
didn't even reach the end of the first block until Sunday August 5 at
about 12:00 UTC. Unlike the situation with rosemary, the reduced load
after this event did not make any noticeable difference to the replag,
which has continued to increase for the past three days at much the same
rate as before.  The next milestone will be completion of the second
major block, which looks like it will occur either late on Friday August
9 or early on Saturday August 10 UTC, barring any other major problems
(like the WMF server outage on Monday which caused replication at the TS
end to stop for several hours).  At that point, the load from SHA-1
updates should be roughly about 30% of what it had been during July. One
would think that would allow the replag to drop, but since the events of
this week, I can't be confident of that.

There is a possible workaround.  The TS could treat this like a server
outage; copy user databases from thyme to rosemary and then point
sql-s1-user to rosemary, which currently has no replag. Rosemary would
then have to handle twice the load, but thyme should start to recover
very quickly with no user-generated queries hitting it. Once thyme has
recovered, point sql-s1-rr to it.

Downsides: (1) this would require several hours of downtime for
sql-s1-user while the user databases are copied; all tools that require
access to user databases would be offline entirely for this period. (2)
it would have to wait until our volunteer TS admins have time to do it.
(3) the added load on rosemary could cause replag to grow there,
although I doubt it would come anywhere near the 14+ days replag we are
dealing with now on thyme. (4) this could all be unnecessary since thyme
might recover on its own once the SHA-1 update load is reduced, although
I don't know any way of forecasting that and experience so far has not
been encouraging.

Question for those of you who operate and/or use tools that access s1
(enwiki):  would you be willing to accept several hours of service
outage and the other downsides in exchange for getting rid of the 14-day
replag?
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] s1 replag, some observations

[Russell Blau]

On Thu, Jul 12, 2012, at 01:29 AM, Platonides wrote:
> On 11/07/12 16:14, Russell Blau wrote:
> > I'm glad to know that the appearance was deceiving.  Having data from
> > rosemary now,
> > I come up with an estimated completion date there of July 30, assuming
> > that the rate at which updates are received from WMF does not change.
> 
> I thought it would be worse. How are you measuring the sha1-populated
> boundaries?

I do a series of queries in the form "SELECT rev_sha1 FROM revision
WHERE rev_id = NNN", with the NNN's selected by a binary search
algorithm, to find the lowest rev_id for which rev_sha1 is "".

Of course, this was preceded by some other queries to establish that
there are, in fact, three consecutive blocks of unpopulated revisions,
and that the upper boundaries of these blocks have not changed.
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] s1 replag, some observations

[Russell Blau]

On Tue, Jul 10, 2012, at 04:39 PM, DaB. wrote:
> Hello,
> At Tuesday 10 July 2012 16:36:29 russblau wrote:
> > It appears that
> > the server on rosemary is receiving millions of database updates each
> > day from WMF and throwing them in the bit bucket.
> 
> I'm not sure what "throwing them in the bit bucket." means, but I guess 
> something like "throwing away";

"bit bucket" == /dev/null   :-)

> this is not the case, the field was just not 
> visible for users – I change that now. 

I'm glad to know that the appearance was deceiving.  Having data from
rosemary now,
I come up with an estimated completion date there of July 30, assuming
that the
rate at which updates are received from WMF does not change.
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] s1 replag, some observations

[Russell Blau]

As most of us already know, replag on enwiki has been going up and up
since about 30 June. As it says on status.toolserver.org, "Hight replag
because of inserting of many SHA1-hashes."  (Note to DaB.: the first
word should be spelled "High".)

I asked DaB. on IRC how long this might go on, and he replied one to two
weeks.  However, I've since done some independent investigation that
suggests that his estimate might be a little low.

It turns out that there are three large blocks of consecutive entries in
the revision database that need to be populated with SHA1 hashes. 
Apparently there are three processes running in parallel on the WMF
servers that are filling in each of these blocks from the bottom, by
numerical order of rev_id.  Knowing this, we can estimate how many
revisions still need to be populated at any given point; and, taking
such estimates at various points in time, can estimate how long the
process will take.  (Needless to say, this is only an estimate since the
rate at which database changes are processed on the toolserver side is
variable; also, the blocks of rev_ids are not actually consecutive due
to deletions, but we can assume for our purposes that the deleted
revisions are distributed uniformly throughout the database.)

It further turns out that it is only possible to compute this estimate
for sql-s1-user (thyme), because the enwiki_p view on sql-s1-rr
(rosemary) does not have the rev_sha1 field at all (!).  It appears that
the server on rosemary is receiving millions of database updates each
day from WMF and throwing them in the bit bucket.

Anyway, based on four observations spaced at 6 hour intervals, it
appears that thyme is populating about 353,000 revisions per hour, or
8.5 million per day.  A simple trendline analysis shows that, at this
rate, completing the 230,000,000 remaining unpopulated revisions will
take about 27 more days (estimated completion Aug 6 at 17:48 UTC).

Anyone who relies on use of the enwiki_p database should expect a
prolonged continuation of degraded service and steadily increasing
replag.
-- 
  Russell Blau
  russb...@imapmail.org


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] SSH client for iPad

[Russell Blau]

SSH Term Pro works, too; I think it cost $4.99.

Sent from a handheld device.

On Jun 22, 2012, at 9:13 PM, Ja Ga  wrote:

> Hey does anyone know of an iPad app that successfully SSH's to Toolserver? 
> The freebies aren't working for me and I'd like to know it will work before I 
> plunk down cash for one.
> 
> - Jason
> ___
> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list: 
> https://wiki.toolserver.org/view/Mailing_list_etiquette
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Anoter SGE question

[Russell Blau]

On Sun, Jun 17, 2012, at 02:29 PM, Dr. Trigon wrote:
> 
> So why are some of my cronie-jobs or qcronsub calls (typically 1 per
> day) silently dropped?
> 
I have been having similar experiences lately, and opened a JIRA bug [1]
to report it.  So far, after more than a week, there have been no other
comments on the bug.  If other users are also having problems with cron
jobs not running, perhaps you could add your reports to this bug and
maybe this information will help the admins to diagnose the problem.

[1] https://jira.toolserver.org/browse/TS-1402

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] s1 replication question

[Russell Blau]

I note that MNT-1225, which was originally projected to take over 24 hours, 
is now closing in on 72 hours and there doesn't seem to be any meaningful 
way to project a completion time.  Nothing we can do about that now, of 
course.


But, I am wondering whether it was necessary to run these updates on *both* 
replicas of s1 (s1-sql-rr and s1-sql-user) at the same time?  This is really 
a naive question, as I don't know enough about mysql administration to even 
guess at the answer.  Perhaps someone more knowledgeable can enlighten us. 
(I do observe, however, that WMF seems to have managed to update all of its 
database slaves in some kind of sequential fashion that didn't impact access 
to enwiki.)


If, in fact, there is no technical requirement for updating both replicas at 
the same time, I would suggest that the next time a situation like this 
arises, it would make more sense to do the updates sequentially so that 
users (both toolserver users and tool users) are not deprived of access to 
this resource for such a long time.


Russ


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Data of s1 (enwiki) probably corrupted

[Russell Blau]

"DaB." on Wednesday, January 25, 2012 9:42 AM:


because of a wmf-master-change last week (when Nosy and I were in the
datacenter) and a mistake on our side, the data of s1 which were inserted
after 18. January are proberly defect or wrong.
I already requested a new dump and will inform you, when there is any 
progress

or news.


Is there any progress or news on this? 



___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Data of s1 (enwiki) probably corrupted

[Russell Blau]

I'll understand if you can't answer this yet, but is there any estimate of 
how long s1 replication will be unavailable (hours, days, weeks)?



___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Submitting Python jobs to SGE from cron

[Russell Blau]

I was never able to get cronsub to accept arguments to the Python script; 
perhaps I was doing it wrong, but this worked so I stopped worrying about 
it.

- Original Message - 
From: "River Tarnell" 
To: 
Sent: Thursday, January 06, 2011 1:39 PM
Subject: Re: [Toolserver-l] Submitting Python jobs to SGE from cron


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Russell Blau:
>> With these scripts in your home directly, you can then set up a cron job 
>> to
>> run any Python script using the following syntax in your crontab:
>
>>  30  9   *   *   *$HOME/pysub jobname $HOME/path/script.py arg1 arg2
>
> What feature(s) does this provide that cronsub doesn't?
>
> - river.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (FreeBSD)
>
> iEYEARECAAYFAk0mDFAACgkQIXd7fCuc5vJCaQCeO8xJQypYe6p4y08ijt7/2gl2
> wngAn0CbmLG4nie6bNqPs7EDJYc8clZZ
> =7wHw
> -END PGP SIGNATURE-
>
> ___
> Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l
> Posting guidelines for this list: 
> https://wiki.toolserver.org/view/Mailing_list_etiquette
> 


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

[Toolserver-l] Submitting Python jobs to SGE from cron

[Russell Blau]

Since a number of users seem to be struggling with the conversion to 
Solaris, I thought I would share the scripts I have been using to start my 
Python bots from Solaris cron using the job server.  If you want to use 
these, be sure to substitute your username for "username" in the last line 
of listing 1, and your python path (if you have one defined) in the third 
line of listing 2.

With these scripts in your home directly, you can then set up a cron job to 
run any Python script using the following syntax in your crontab:

 30  9   *   *   *$HOME/pysub jobname $HOME/path/script.py arg1 arg2

"jobname" is an arbitrary name to be given to the job.  Be sure to include 
$HOME/ in both places; replace /path/ with the path from your home directory 
to the Python script.

I don't know as much about bash as I do about Python, so it is very possible 
someone else can improve on these scripts.  :-)  But feel free to use them 
if they are helpful.

Russ

Listing 1: pysub

 #! /bin/ksh
 # like cronsub, but runs a python script instead of a shell script
 . /sge62/default/common/settings.sh
 [[ $# -ge 1 ]] || {
echo >&2 "usage: $0  

Re: [Toolserver-l] Set your default license

[Russell Blau]

River Tarnell:
> Russell Blau:
>> How does one know what their LDAP password is?
>
> You can set it by running "setpass".

Turns out it was already set.  Nightshade accepted my current password in 
'setlicense', but willow did not.

russell


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] Set your default license

[Russell Blau]

"River Tarnell"  wrote:

> Hi,
> 
> We have now introduced the concept of a default license for each
> account.  This is documented on the wiki:
> .
> 
> In the future, selecting a default license will be required at account
> creation time (for new account), and at the next account renewal time
> (for existing accounts).  I suggest people set their license now rather
> than leaving it until then.

How does one know what their LDAP password is?

russell

___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] nightshade was rebooted

[Russell Blau]

Yesterday I happened to be looking at http://status.toolserver.org/ and I
noticed that the timestamp was about 45 minutes in the future -- of course,
you will see this phenomenon only if you happen to load the page within an
hour after it has been edited, which is infrequent.  However, it seems to
indicate some consistent time-zone issue on one of the servers.

Russ 

> -Original Message-
> From: toolserver-l-boun...@lists.wikimedia.org 
> [mailto:toolserver-l-boun...@lists.wikimedia.org] On Behalf 
> Of James Hare
> Sent: Friday, October 23, 2009 8:50 PM
> To: toolserver-l@lists.wikimedia.org; 
> toolserver-annou...@lists.wikimedia.org
> Subject: Re: [Toolserver-l] nightshade was rebooted
> 
> 1:15 AM UTC on what date? It's only 0:50 AM UTC right now.
> 
> 
> On Fri, Oct 23, 2009 at 8:17 PM, River Tarnell 
>  wrote:
> 
> 
>   -BEGIN PGP SIGNED MESSAGE-
>   Hash: SHA1
>   
>   nightshade was rebooted at ~1:15AM UTC.
>   
>  - river.
>   -BEGIN PGP SIGNATURE-
>   Version: GnuPG v1.4.9 (HP-UX)
>   
>   iEYEARECAAYFAkriR6cACgkQIXd7fCuc5vLAGgCgjXoAAJ/egdSHcPBQJskEjk5p
>   HvQAoMHGeRU1wzWvdOQGAjZczAWLUbSq
>   =3Sox
>   -END PGP SIGNATURE-
>   
>   ___
>   Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
>   https://lists.wikimedia.org/mailman/listinfo/toolserver-l
>   Posting guidelines for this list: 
> https://wiki.toolserver.org/view/Mailing_list_etiquette
>   
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.423 / Virus Database: 270.14.29/2455 - Release 
> Date: 10/24/09 06:43:00
> 
> 
> 


___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list: 
https://wiki.toolserver.org/view/Mailing_list_etiquette

Re: [Toolserver-l] where's enwiki_p on s1?

[Russell Blau]

"Andrew Garrett" 

> This is totally unproductive, unwelcome and unnecessary. Please go
> away if this is the sum of your contribution to this list.
>
> You seem to be making sarcastic comments attacking toolserver admins
> for making an estimate an order of magnitude or two about how long the
> s1 reimport will take. I'm not sure how you could possibly think this
> is acceptable.
>
> I should remind you that we can't make the reimport run faster, that
> we are volunteers (at least, in our capacity as toolserver admins),
> and that when somebody asked how long was remaining, an up to date
> estimate was given within ten minutes. What more would you like?
>

No offense was intended.  I was trying to be lighthearted.

I did not see your response before posting.  Up until that point, there had 
been several other inquiries, both on the mailing list and on IRC, and all 
the responses had been rather curt references to the fact that a reimport 
was in progress, with no estimate of when it might be completed.

To put it in perspective, I provide professional services for a living.  If 
I told a client that a particular task would be done in a few hours, and 
several days later it was not done, and if the client then asked what was 
taking so long, and my response had the tone of the responses that 
Toolserver users had received *prior to yours* earlier this hour -- I'd be 
out looking for a new client.

Yes, I know that you are not doing this for pay (although both WMF and 
Wikimedia DE do actively solicit for monetary contributions from their loyal 
users), and that you cannot make it go any faster.  I think all the users 
want is to be kept informed if things are taking longer than originally 
anticipated.

Again, I was not intending to attack anyone, and if my comment was 
interpreted that way, I do apologize.


___
Toolserver-l mailing list
Toolserver-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/toolserver-l

Re: [Toolserver-l] where's enwiki_p on s1?

[Russell Blau]

"Carl Fürstenberg"  wrote:
>
> Sadly the status hasn't changed much in the last days, I think people
> wonder if you have an clue when it might be done, is it days, weeks or
> months we are talking about?

River Tarnell  wrote at Fri Jul 31 
20:42:13 UTC 2009:

> River Tarnell:
> > there will be a few hours of downtime while the new database is 
> > imported,
> > then some replication lag.
>
> this maintenance has now started; s1 will be offline until it finishes.
>
> - river.

Clearly, Carl, you are suffering from the same reading comprehension 
difficulty as me, and other Toolserver users.  We were told quite clearly, 
four and a half days ago, that s1 will be offline for "a few hours."  I'm 
not sure whether it was "few" or "hours" that tripped me up, but it seems 
certain that at least one of those words means something very different than 
what I thought it did.  I apologize for the misunderstanding.



___
Toolserver-l mailing list
Toolserver-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/toolserver-l