mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > No Prime Left Behind

Reply
 
Thread Tools
Old 2020-01-10, 10:22   #540
unconnected
 
unconnected's Avatar
 
May 2009
Russia, Moscow

23·3·101 Posts
Default

https://dev.mysql.com/doc/refman/5.7...-recovery.html
Or follow rebirther's link but start with innodb_force_recovery = 1
Recovering InnoDB databases isn't easy, possibly the simpliest way is to completely drop database and restore from latest backup if you have any.

Last fiddled with by unconnected on 2020-01-10 at 10:24
unconnected is offline   Reply With Quote
Old 2020-01-10, 21:02   #541
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2×5×1,013 Posts
Default

I am trying Rebirther's suggested link. I was able to stop the SQL server in step 1. But I am unable to do steps 2 or 3 because I do not have permissions.

I get the following message:
You do not have the permissions necessary to open the file.

How do I get permissions to read, copy, write, or open these files?

I know it has something to do with having to be the root user but I cannot figure out how to do that.

One more thing: The my.cnf file is in /etc/mysql/my.cnf (not /etc/my.cnf).
gd_barnes is offline   Reply With Quote
Old 2020-01-10, 21:18   #542
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

29×197 Posts
Default

Quote:
Originally Posted by gd_barnes View Post
I am trying Rebirther's suggested link. I was able to stop the SQL server in step 1. But I am unable to do steps 2 or 3 because I do not have permissions.

I get the following message:
You do not have the permissions necessary to open the file.

How do I get permissions to read, copy, write, or open these files?

I know it has something to do with having to be the root user but I cannot figure out how to do that.

One more thing: The my.cnf file is in /etc/mysql/my.cnf (not /etc/my.cnf).
Use "chown" or "chmod" to get access.
rogue is offline   Reply With Quote
Old 2020-01-10, 21:49   #543
yoyo
 
yoyo's Avatar
 
Oct 2006
Berlin, Germany

10658 Posts
Default

Yes, rebirther's link are the steps todo. Start with recovery=1 and check if the db starts.

You must be root, e.g. by "sudo bash" or "su -" to backup the IB files.
yoyo is offline   Reply With Quote
Old 2020-01-10, 22:55   #544
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2·5·1,013 Posts
Default

Using the link in Reb's post as a reference.

I was able to log in as root and backup the files in step #2.

Per step #3 I edited /etc/mysql/my.cnf to have the command:
innodb_force_recovery = 1

I'm now to step 4.

I stopped MySQL with:
sudo service mysql stop

Message said it stopped successfully.

I attempted to restart MySQL with:
sudo service mysql start

I got the following message:
* Starting MySQL database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query

This is the same message that I got before.

I then did an SQL status with this command:
sudo service mysql status

Output was this:
Code:
 * /usr/bin/mysqladmin  Ver 8.41 Distrib 5.0.75, for debian-linux-gnu on x86_64
Copyright (C) 2000-2006 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version        5.0.75-0ubuntu10.5
Protocol version    10
Connection        Localhost via UNIX socket
UNIX socket        /var/run/mysqld/mysqld.sock
Uptime:            1 sec

Threads: 1  Questions: 2  Slow queries: 0  Opens: 12  Flush tables: 1  Open tables: 6  Queries per second avg: 2.000
My question is: Do I continue with step 5 by dumping all the tables? Or is the above error a problem that keeps me from continuing until it is fixed? I was hoping that the recovery line in my.cnf would correct this.

Last fiddled with by gd_barnes on 2020-01-10 at 22:56
gd_barnes is offline   Reply With Quote
Old 2020-01-11, 01:42   #545
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2·5·1,013 Posts
Default

So...after doing steps 2 and 3 and running into that previous error on step 4...I thought I would try step 5 with the following command:

root@jeepford:/etc/mysql# mysqldump -u gary -p prpnet1300 > dump1300.sql

It then made me enter my root password, which I did. It then gave the following message:

mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect

I cannot seem to get away from that message.

Note that I only tried to dump one of the servers. It would not allow me to use the -A command as specified in the instructions for #5.

Somehow we need to get it to correctly connect to the DB so that it can be dumped.

Help!

Last fiddled with by gd_barnes on 2020-01-11 at 01:43
gd_barnes is offline   Reply With Quote
Old 2020-01-11, 04:26   #546
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

4508 Posts
Default

I ran into this issue with my home server's previous OS install (Ubuntu 17.10 IIRC). I ended up reinstalling the OS (since I couldn't reinstall MySQL without killing my PIM setup), but this script may help get the server running so you can dump the contents (bypassing the permissions; make sure it's not publicly accessible):

Code:
#!/bin/sh

sudo mkdir /var/run/mysqld
sudo chown -R mysql /var/run/mysqld/
sudo mysqld --skip-grant-tables

Last fiddled with by Happy5214 on 2020-01-11 at 04:28
Happy5214 is offline   Reply With Quote
Old 2020-01-11, 06:05   #547
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

2·5·1,013 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
I ran into this issue with my home server's previous OS install (Ubuntu 17.10 IIRC). I ended up reinstalling the OS (since I couldn't reinstall MySQL without killing my PIM setup), but this script may help get the server running so you can dump the contents (bypassing the permissions; make sure it's not publicly accessible):

Code:
#!/bin/sh

sudo mkdir /var/run/mysqld
sudo chown -R mysql /var/run/mysqld/
sudo mysqld --skip-grant-tables
This did not work. I got the following gibberish:

Code:
gary@jeepford:~$ sudo mysqld --skip-grant-tables
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
200111  0:04:20  InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
200111  0:04:33  InnoDB: ERROR: We were only able to scan the log up to
InnoDB: 65 3180301824, but a checkpoint was at 65 3180302287.
InnoDB: It is possible that the database is now corrupt!
200111  0:04:33  InnoDB: Error: page 1 log sequence number 65 3182452991
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 4 log sequence number 65 3181673642
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 6 log sequence number 65 3182821206
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 49172 log sequence number 65 3186685478
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 49153 log sequence number 65 3186345244
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 202272 log sequence number 65 3186682578
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 196609 log sequence number 65 3181146735
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 330293 log sequence number 65 3186631187
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 327681 log sequence number 65 3184275303
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 344075 log sequence number 65 3181039382
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 344065 log sequence number 65 3182245162
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 212993 log sequence number 65 3182730042
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 147457 log sequence number 65 3185010846
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 5 row operations to undo
InnoDB: Trx id counter is 0 2825215232
200111  0:04:33  InnoDB: Error: page 0 log sequence number 65 3182821206
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Cleaning up trx with id 0 2825225248
200111  0:04:33  InnoDB: Rollback of non-prepared transactions completed
200111  0:04:33  InnoDB: Error: page 311297 log sequence number 65 3183278764
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Error: page 114689 log sequence number 65 3181146898
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:33  InnoDB: Started; log sequence number 65 3180302287
InnoDB: !!! innodb_force_recovery is set to 1 !!!
200111  0:04:33 [Note] mysqld: ready for connections.
Version: '5.0.75-0ubuntu10.5'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
200111  0:04:34  InnoDB: Error: page 278529 log sequence number 65 3182822051
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 294913 log sequence number 65 3182821788
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 131073 log sequence number 65 3183083236
InnoDB: is in the future! Current system log sequence number 65 3180302287.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 65537 log sequence number 65 3181343415
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 163841 log sequence number 65 3181146680
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 229377 log sequence number 65 3181075900
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 32769 log sequence number 65 3186349072
InnoDB: is in the future! Current system log sequence number 65 3180302358.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 192040 log sequence number 65 3180871058
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 180225 log sequence number 65 3181147455
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
200111  0:04:34  InnoDB: Error: page 43376 log sequence number 65 3181145698
InnoDB: is in the future! Current system log sequence number 65 3180302379.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.
InnoDB: Error: trying to access page number 1768430057 in space 0,
InnoDB: space name ./ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
200111  0:04:34InnoDB: Assertion failure in thread 139684868266320 in file fil0fil.c line 3959
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
200111  0:04:34 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=134217728
read_buffer_size=6291456
max_used_connections=0
max_connections=200
threads_connected=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
frame pointer is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
I tried it both with MySQL stopped and then again with it started. No luck.

Last fiddled with by gd_barnes on 2020-01-11 at 06:06
gd_barnes is offline   Reply With Quote
Old 2020-01-11, 06:59   #548
yoyo
 
yoyo's Avatar
 
Oct 2006
Berlin, Germany

5×113 Posts
Default

First enable mysql logging. I have in [mysql]
log_error = /var/log/mysql/error.log

After you restarted mysql, check with e.g. "ps -ef | grep mysql" if mysql is running and with some sql command if you can access a table. You can also try to run an mysqldump. Check also the mysql error log. If mysql crashes you would see some segmentation fault of memory dumps.

If mysql is not running, set recovery=2 and try again.
And so on.
At least with recovery=5 mysql should start and report some error in error log.
But now you can run mysqldump.
yoyo is offline   Reply With Quote
Old 2020-01-11, 10:17   #549
gd_barnes
 
gd_barnes's Avatar
 
May 2007
Kansas; USA

279216 Posts
Default

With all of your help I've made quite a bit of progress.

I changed the recovery command to:
innodb_force_recovery = 5

That successfully started MySQL and allowed me to dump the databases.

When doing the dump with the -A command of course it dumps them all in one file. But I got a new database error message after a long time of dumping. I had a strong suspicion which database was corrupt on my machine. It is my personal server prpnet1470. Suspecting this I dumped only prpnet1470 and there it was with the same error message! All of the other databases dumped just fine.

Here is the message that I am getting for database prpnet1470 when I try to dump it:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `CandidateTestResult` at row: 251210

So if I follow Reb's link's instructions I'm going to be dumping all the databases, dropping them all, removing some files, restarting MySQL, and restoring all of the databases from the dump.

At this point, that seems like overkill.

My question is:
Should I just dump and drop prpnet1470? If so do I want to do step 8 which is: Remove /var/lib/mysql/ib*

I'm afraid to remove all of the ib* files from that library if I am dropping only one database.

I guess what I need is more specific instructions on fixing the one database that I know is corrupt, which is causing problems for MySQL.

I could even just permanently delete prpnet1470 and not restore it. I was able to do enough select statements to know where I'm at in my testing so there would be no data loss. It would be nice to keep it intact but if it is too much of a problem to do so there are other personal servers that I could use.

Last fiddled with by gd_barnes on 2020-01-11 at 10:31
gd_barnes is offline   Reply With Quote
Old 2020-01-11, 13:23   #550
rebirther
 
rebirther's Avatar
 
Sep 2011
Germany

17×139 Posts
Default

If you know the lib name of the affected database remove only the name of the lib file not all.
rebirther is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
What exactly is sent to the server? paul0 NFS@Home 2 2015-03-12 23:00
Server bug -- new? Christenson Information & Answers 5 2011-07-12 21:44
Server Down? Grant Information & Answers 13 2008-11-24 19:37
New ECM-server available andi314 Factoring 3 2003-08-31 11:22
New Server Hardware and price quotes, Funding the server Angular PrimeNet 32 2002-12-09 01:12

All times are UTC. The time now is 10:03.

Wed Jun 3 10:03:09 UTC 2020 up 70 days, 7:36, 2 users, load averages: 1.45, 1.42, 1.45

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.