In response to George's post #553, I have tried resubmitting the results manually and the server states that these have already been submitted. The results are listed in the exponent status page as unverified. George, I will PM you the results from work on Monday.

[QUOTE=richs;381240]In response to George's post #553, I have tried resubmitting the results manually and the server states that these have already been submitted. The results are listed in the exponent status page as unverified. George, I will PM you the results from work on Monday.[/QUOTE]

That's odd, I cleaned out the LL data manually from your first submission. When you PM the results, also include the userid I should submit the results for.

Manual pages broken.
Following error message shows up at the top of the page as soon as you open it:

error: [Microsoft][ODBC SQL Server Driver][SQL Server]The transaction log for database 'PrimeNet' is full due to 'LOG_BACKUP'. , SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\userid_session_state.inc.php on line 30

[QUOTE=lycorn;381343]Manual pages broken.
Following error message shows up at the top of the page as soon as you open it:

error: [Microsoft][ODBC SQL Server Driver][SQL Server]The transaction log for database 'PrimeNet' is full due to 'LOG_BACKUP'. , SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\userid_session_state.inc.php on line 30[/QUOTE]

It actually appears on EVERY page.

A manual check in gives this

Warning: odbc_exec(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]The transaction log for database 'PrimeNet' is full due to 'LOG_BACKUP'. , SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\v5server\0.96_database.inc.php on line 342
Error in obtaining cpuid for manual testing computer.
Error code: 11, error text: Update t_cpus failed, cpu_id: 926763

Just displaying the home page shows this at the top of the screen

SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]The transaction log for database 'PrimeNet' is full due to 'LOG_BACKUP'. , SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\userid_session_state.inc.php on line 30

.

She's still dead gove'nor! Or at least the automatic reports...

[CODE]c(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]
The transaction log for database 'PrimeNet' is full due to 'LOG_BACKUP'. ,
SQL state 37000 in SQLExecDirect in C:\inetpub\www\2013\userid_session_state.inc.php on line 30
[/CODE]Edit: couldn't report anything today (thai time). Misfit logs say:
[code]WARNING: ODBC_EXEC(): SQL ERROR: [MICROSOFT][ODBC SQL SERVER DRIVER][SQL SERVER]COULD NOT ALLOCATE A NEW PAGE FOR DATABASE 'TEMPDB' BECAUSE OF INSUFFICIENT DISK SPACE IN FILEGROUP 'PRIMARY'. CREATE THE NECESSARY SPACE BY DROPPING OBJECTS IN THE FILEGROUP, ADDING ADDITIONAL FILES TO THE FILEGROUP, OR SETTING AUTOGROWTH ON FOR EXISTING FILES IN THE FILEGROUP., SQL STATE 37000 IN SQLEXECDIRECT IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 130

WARNING: ODBC_FETCH_ROW() EXPECTS PARAMETER 1 TO BE RESOURCE, BOOLEAN GIVEN IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 131

WARNING: ODBC_FETCH_ROW() EXPECTS PARAMETER 1 TO BE RESOURCE, BOOLEAN GIVEN IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 132

WARNING: ODBC_FREE_RESULT() EXPECTS PARAMETER 1 TO BE RESOURCE, BOOLEAN GIVEN IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 136

WARNING: ODBC_EXEC(): SQL ERROR: [MICROSOFT][ODBC SQL SERVER DRIVER][SQL SERVER]THE TRANSACTION LOG FOR DATABASE 'PRIMENET' IS FULL DUE TO 'LOG_BACKUP'. , SQL STATE 37000 IN SQLEXECDIRECT IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 284
PROCESSING_VALIDATION:UNKNOWN_USER_OR_ERROR_OBTAINING_MANUAL_TESTING_COMPUTER_SUBMISSION_REJECTED.
ERROR CODE: 13, ERROR TEXT: CREATION OF MANUAL TESTING COMPUTER FAILED
[/code]

and:

[code]WARNING: ODBC_EXEC(): SQL ERROR: [MICROSOFT][ODBC SQL SERVER DRIVER][SQL SERVER]THE TRANSACTION LOG FOR DATABASE 'PRIMENET' IS FULL DUE TO 'LOG_BACKUP'. , SQL STATE 37000 IN SQLEXECDIRECT IN C:\INETPUB\WWW\2013\V5SERVER\0.96_DATABASE.INC.PHP ON LINE 342
PROCESSING_VALIDATION:UNKNOWN_USER_OR_ERROR_OBTAINING_MANUAL_TESTING_COMPUTER_SUBMISSION_REJECTED.
ERROR CODE: 11, ERROR TEXT: UPDATE T_CPUS FAILED, CPU_ID: 532256 [/code]

PHP Error Reporting, or any kind of script errors, should never be forwarded onto the live website. It makes the wrong kind of people aroused and brings the bad idea to fiddle with the information given.

[I]Meral Harbes escapes from the server room - filled with (because of his obvious statement) at him raging admins - trough the closing, 1cm thick metal security door.[/I]

[Sun Aug 24 18:53:32 2014 - ver 28.5]
Updating computer information on the server
Sending expected completion date for M35776079: Aug 29 2014
Sending expected completion date for M35498161: Sep 06 2014
Sending expected completion date for M36158659: Aug 29 2014
Sending expected completion date for M35533789: Sep 06 2014
Sending expected completion date for M36342563: Aug 29 2014
Sending expected completion date for M36680023: Aug 29 2014
[Mon Aug 25 06:33:39 2014 - ver 28.5]
Getting assignment from server
PrimeNet error 9: Access denied
Untrusted program versions currently excluded by PrimeNet
[Mon Aug 25 07:43:42 2014 - ver 28.5]
Getting assignment from server
PrimeNet error 11: Server database malfunction
Update t_cpus failed, cpu_id: 991563
[Mon Aug 25 08:53:44 2014 - ver 28.5]
Getting assignment from server
PrimeNet error 11: Server database malfunction
Update t_cpus failed, cpu_id: 991563

[B]EDIT:[/B]I posted at 9:59 and it was fixed by 10:03. What great support!!

[QUOTE=Meral Harbes;381361]PHP Error Reporting, or any kind of script errors, should never be forwarded onto the live website. It makes the wrong kind of people aroused and brings the bad idea to fiddle with the information given.

[I]Meral Harbes escapes from the server room - filled with (because of his obvious statement) at him raging admins - trough the closing, 1cm thick metal security door.[/I][/QUOTE]

You got that right.

Meanwhile, looks like the SQL log grew to an astounding 22 GB overnight for some reason. Time to shrink it.

The drive for the log files actually does have more room, but we're temporarily storing backups of the original database from the old server as a "just in case", and that takes up quite a bit of room.

I'm on the case... we'll get this figured out.

[QUOTE=Madpoo;381367]I'm on the case... we'll get this figured out.[/QUOTE]

Please let me know if GPU72's spidering is contributing to these problems in any way.

So you (and everyone) knows, the "observation spider" runs every ten minutes (except at HH:00 (the top of the hour)), looking for completed TF and LL/DC assignments. These queries should only result in reads and no writes for the DB -- and in fact this spider has continued to successfully run during this outage.

The "recycled fetching spider" runs every five minutes (except at HH:00 nor HH:05), and attempts to reserve 10 P-1 assignments, 10 Cat3 assignments, and 20 Cat4 assignments to capture anything not appropriately TF'ed. It then "throws back" anything not of interest. This spider has NOT successfully run since 20140825_075509 UTC (not surprising since these actions will result in DB writes).

The latter spider can be turned off (or its frequency reduced) if it is a problem. It would only mean that we don't capture all expired candidates not fully TF'ed; not the end of the world.

Oh, and just now both spiders started returning results again. Thanks Madpoo!

[QUOTE=chalsall;381368]Please let me know if GPU72's spidering is contributing to these problems in any way.

So you (and everyone) knows, the "observation spider" runs every ten minutes (except at HH:00 (the top of the hour)), looking for completed TF and LL/DC assignments. These queries should only result in reads and no writes for the DB -- and in fact this spider has continued to successfully run during this outage.

The "recycled fetching spider" runs every five minutes (except at HH:00 nor HH:05), and attempts to reserve 10 P-1 assignments, 10 Cat3 assignments, and 20 Cat4 assignments to capture anything not appropriately TF'ed. It then "throws back" anything not of interest. This spider has NOT successfully run since 20140825_075509 UTC (not surprising since these actions will result in DB writes).

The latter spider can be turned off (or its frequency reduced) if it is a problem. It would only mean that we don't capture all expired candidates not fully TF'ed; not the end of the world.

Oh, and just now both spiders started returning results again. Thanks Madpoo![/QUOTE]

Thanks for letting me know it's working again. I trunc'd the logfile to shrink it down.

The issue did start showing up at 8:01 AM UTC today so that corresponds to when you saw your thing start failing, give or take.

I'm not sure what caused the log to grow... if you're just doing things that result in reads from the DB then it shouldn't be logging squat, but maybe there's something internally I don't know about where maybe it "touches" a timestamp in some table resulting in excessive writing... I have no idea really.

I guess I'll keep an eye on the log today and see if it recurs and maybe dig through the IIS logs to see if there were any odd patterns leading up to the issue.