On Wed, Jun 13, 2018, 22:29 Thomas De Schampheleire < [email protected]> wrote:
> 2018-06-13 20:39 GMT+02:00 Matey Chopov <[email protected]>: > > Hi, > > > > It looks like it happens with a specific .pdf manual, I tested it with > another .pdf file and the exception didn't occur, the file got pushed > correctly. > > > > Here's the line in the trace I think is the most interesting: > > > > DatabaseError: (DatabaseError) file is encrypted or is not a database > u'SELECT ui.ui_id AS ui_ui_id, ui.ui_section AS ui_ui_section, ui.ui_key AS > ui_ui_key, ui.ui_value AS ui_ui_value, ui.ui_active AS ui_ui_active \nFROM > ui \nWHERE ui.ui_key = ?' ('push_ssl',) > > 2018-06-13 11:07:04.946 ERROR [waitress] Exception when servicing > <waitress.channel.HTTPChannel connected 0.0.0.0:12756 at 0x7f06c5923e90> > > > > I have uploaded the surrounding log on pastebin: > https://pastebin.com/n9fY4xae > > > > So the problematic pdf that I though wasn't encrypted, was actually > encrypted with RC4, the weird thing is that in Git Extensions you can still > see the file contents in the "diff" section. > > > > Apparently, pdf readers automatically decrypt such files if there is no > password (which is the current case). > > > > I used qpdf to decrypt the file (with no password) which gave another > valid .pdf file with no encryption (at least that's what I get when I > analyze the file with pdfinfo). > > > > Tried pushing that file too, but it still failed. > > > > I played with the pdf headers, changed the Creator and Producer values > to the ones of a .pdf file I know could be uploaded. Same error. > > > > I tried converting the file from pdf1.3 to pdf1.4, same issue. > > > > So, what finally worked for me was converting from pdf to ps, then to > text, then from the text file, to ps, and then to pdf. The indexing table > got screwed, but that doesn't really bother me. Finally, pushed the new pdf > file to the git repo with success. > > > > Commands: > > > > pdftops test.pdf test.ps > > ps2txt test.ps test.txt > > > > enscript -B --margins=10:10 -o test.ps -f [email protected]/1 test.txt > > ps2pdf test.ps test_last.pdf > > > > Your log also shows: > > Traceback (most recent call last): > File "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/task.py", > line 74, in handler_thread > task.service() > File > "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/channel.py", > line 368, in service > request._close() > File > "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/parser.py", > line 249, in _close > body_rcv.getbuf()._close() > File > "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py", > line 303, in _close > buf._close() > File > "/opt/Kallithea/local/lib/python2.7/site-packages/waitress/buffers.py", > line 110, in _close > self.file.close() > IOError: [Errno 9] Bad file descriptor > > > which reminds me of following two open issues: > > > https://bitbucket.org/conservancy/kallithea/issues/219/waitress-exception-when-serving-file > https://bitbucket.org/conservancy/kallithea/issues/229/bad-file-descriptor > > > > Is the PDF on which you see the issue something you could share? > Or could you create another PDF with dummy data that also exhibits the > issue? > > If at all it would be possible, could you test with the default branch > of Kallithea, instead of 0.3.5 ? > Note that it doesn't make sense to me that the contents of the file would matter. I think it is more likely about the file size. Could you check the file sizes of the different files you tested with? Also, the reporter of issue #219 reported back that his issue was gone when switching away from waitress to another web server, in his case uwsgi. Could you try that too ? Thanks, Thomas
_______________________________________________ kallithea-general mailing list [email protected] https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
