evilhero / mylar

An automated Comic Book downloader (cbr/cbz) for use with SABnzbd, NZBGet and torrents
GNU General Public License v3.0
977 stars 172 forks source link

Odd Error - Non-Posic-compliant windows feature? #128

Closed necromancyr closed 7 years ago

necromancyr commented 11 years ago

Getting PAGES of the following on continuous scroll in my shell window (in Windows) every once and awhile. Seems to happen when I do a refresh...or anything else. Seems tied to some odd inability to open the log file...don't know why it is occuring.

ValueError: I/O operation on closed file Logged from file logger.py, line 79 Traceback (most recent call last): File "C:\Python27\lib\logging\handlers.py", line 77, in emit if self.shouldRollover(record): File "C:\Python27\lib\logging\handlers.py", line 151, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file Logged from file logger.py, line 81 04-Jan-2013 22:54:39 - INFO :: CP Server Thread-7 : I've found 64 / 208 issues. Traceback (most recent call last): File "C:\Python27\lib\logging\handlers.py", line 77, in emit if self.shouldRollover(record): File "C:\Python27\lib\logging\handlers.py", line 151, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file Logged from file logger.py, line 81

evilhero commented 11 years ago

can you paste the last few lines of your mylar.log file ( or at least showing what the last line is before the error)...

evilhero commented 11 years ago

Based on some quick research, it's a problem with the rotatinglogger. Same exact issue was logged with Headphones over a year ago by an individual...the solution was to shutdown the program, delete the log file (mylar.log) and the db (mylar.db) and everything should return to normal.

DGMayor commented 11 years ago

I get this too - I remember seeing the issue a while ago (almost a year) with Sickbeard, but they ended up fixing it. http://code.google.com/p/sickbeard/issues/detail?id=1456&can=1&q=logger&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars

I'm trying to find the fix on github just to see if it might apply, but I can't seem to find the darn thing.

necromancyr commented 11 years ago

Evilhero - that's the thing...the log file has NOTHING in it. It stops updating when the errors start flowing in.

Also, and it may be related to this, but I'm 90% certain that mylar's causing a system crash on my WHS'11 server. I'm testing out NewzNab and Mylar now and when both are running, crash within 18-20hrs. (complete system freeze or a self-reboot). W/just newznab I've been running for an extended period of time (>24hrs) w/out any crash. In the log file, there's nothing from pre-crash indicating an issue (just normal items) but it could have something to do with this preventing log entries from being made.

DGMayor commented 11 years ago

I can't speak to his crashes but I can confirm I'm experiencing the same issue. When this occurs Mylar starts taking forever to do anything. So for example this occurred after removing and re-adding x-factor this morning. It occurred just as the file check started. The file check finished but it took almost 20 minutes. Restarting doesn't fix it. I have to kill the process and then reload it.

evilhero commented 11 years ago

I'm betting it has something to do with all the verbosity expanding the size of logs and not being able to roll over into a new log file properly. I lowered the verbosity on issue scanning in the last commit so that migt allow the rotator to properly initialize and flow the logs through to additional files if need be.

evilhero commented 9 years ago

Concurrent Rotational Log Handler has been added to Mylar - development build. If you are running on Windows it will automatically try to enable it. The only requirement is that it needs Python Extensions for Windows installed ( http://sourceforge.net/projects/pywin32/ ). Once installed, Mylar will automatically switch to the Concurrent one, which should (it's supposed to) stop the deadlocks on the logging file.