I am having a problem with my SpamSnake 12.04. The server is running Django/Nginx/uWSGI. uWSGI keeps giving me the error mentioned in the title: "Error opening file for reading: Permission denied' I believe it may be related to the following bug: https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1031718 I am not sure how to resolve the issue. Can anyone help? uWSGI Logs: [uWSGI] getting INI configuration from /usr/share/uwsgi/conf/default.ini [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/baruwa.ini Wed May 22 22:04:16 2013 - option "module" found in plugin python_plugin.so Wed May 22 22:04:16 2013 - *** Starting uWSGI 1.0.3-debian (32bit) on [Wed May 22 22:04:16 2013] *** Wed May 22 22:04:16 2013 - compiled with version: 4.6.3 on 17 July 2012 02:24:04 Wed May 22 22:04:16 2013 - current working directory: / Wed May 22 22:04:16 2013 - writing pidfile to /run/uwsgi/app/baruwa/pid Wed May 22 22:04:16 2013 - detected binary path: /usr/bin/uwsgi-core Wed May 22 22:04:16 2013 - setgid() to 33 Wed May 22 22:04:16 2013 - setuid() to 33 Wed May 22 22:04:16 2013 - your memory page size is 4096 bytes Wed May 22 22:04:16 2013 - uwsgi socket 0 bound to UNIX address /run/uwsgi/app/baruwa/socket fd 5 Wed May 22 22:04:16 2013 - Python version: 2.7.3 (default, Aug 1 2012, 05:27:35) [GCC 4.6.3] Wed May 22 22:04:16 2013 - Python main interpreter initialized at 0x9dcccb0 Wed May 22 22:04:16 2013 - your server socket listen backlog is limited to 100 connections Wed May 22 22:04:16 2013 - *** Operational MODE: preforking *** Wed May 22 22:04:16 2013 - WSGI application 0 (mountpoint='') ready on interpreter 0x9dcccb0 pid: 14026 (default app) Wed May 22 22:04:16 2013 - *** uWSGI is running in multiple interpreter mode *** Wed May 22 22:04:16 2013 - spawned uWSGI master process (pid: 14026) Wed May 22 22:04:16 2013 - spawned uWSGI worker 1 (pid: 14038, cores: 1) Wed May 22 22:04:16 2013 - spawned uWSGI worker 2 (pid: 14039, cores: 1) Error opening file for reading: Permission denied
Same problem here Hi, I have the same exact problem as jrossi90. I wonder if a furture ubuntu patch will solve the problem ? Any thoughts other than a future patch to sole the issue ? Thanks
LinuxUser81 - I solved my problem. After much testing, I realized that although those uwsgi error messages were a nuisance, they were not what were causing the timeout. It ended up being that the Celery worker was starting up before the message broker. I had to run (assuming you are wokring with a SpamSnake) Code: update-rc.d -f baruwa remove update-rc.d baruwa defaults 91 to fix it. If the uwsgi messages really bother you, Ubuntu addressed it in 12.10. Upgrading from 12.04 to 12.10 will get rid of them. -jrossi90
In exactly the same situation with these timeout issues and have hit a brick wall. Everything was working perfectly until I patched 12.04 LTS at the weekend now I get the same timeouts. Have tried all suggestions above and no joy. No errors are reported anywhere in any logs other than the infamous 'Error opening file for reading'. Seems a shame to scrap everything when this is the only thing not working. I have been using Rocky's excellent guides since the early days, never had a problem before. Any tips or help appreciated.
FIXED: Strange one this- OK so I could train HAM/SPAM/Release/Delete from anywhere except the message details screen which would cause a hang and timeout. Most times I would have to restart uwsgi. I poured over this for hours and implemented everything jrossi90 appeared to find out about this problem, I also conversed with jrossi90 yesterday but we hit a dead end. Thanks for the help by the way. There was little in the logs to help, but seeing the release mechanism work everywhere but this screen I knew it could not be permissions of interactions with MailScanner/SpamAssassin/Baruwa. As other have I saw this in the uwsgi log files: /usr/lib/python2.7/dist-packages/djcelery/managers.py:173: TxIsolationWarning: Polling results with transaction isolation level repeatable After some research I found this: https://code.djangoproject.com/ticket/13906 And after inserting the following into /etc/baruwa/settings.py: # Recommended for MySQL. See http://code.djangoproject.com/ticket/13906 'OPTIONS': {'init_command': 'SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED'}, In the section starting: DATABASES = { 'default': { I rebooted and everything is working! No idea why other than the 'not returning error code' is a possible reason as to why the session was hanging. I really hope this helps others, this problem was a nightmare. I have rebooted several times and thus far it appears fixed.
