SSL SYSCALL错误:带有postgres和Celery的Heroku上的文件描述符错误

时间:2016-08-25 16:45:00

标签: django postgresql heroku celery

我已经成功地在Heroku上使用了一个Django网站,但是它刚刚开始生成下面的错误,这会阻止它运行。它看起来像是在使用postgres时遇到了麻烦,但是考虑到它的Celery而不是我的代码存在问题,我很难解决它的问题(我认为。 ..)。

我使用CloudAMPQ作为代理,我的Django设置包括:

CELERYBEAT_SCHEDULER = 'djcelery.schedulers.DatabaseScheduler'

这是来自Heroku日志的追溯:

Traceback (most recent call last):
  File "/app/.heroku/python/lib/python3.5/site-packages/kombu/utils/__init__.py", line 323, in __get__
    return obj.__dict__[self.__name__]
KeyError: 'scheduler'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
    return self.cursor.execute(sql, params)
psycopg2.OperationalError: SSL SYSCALL error: Bad file descriptor


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/.heroku/python/lib/python3.5/site-packages/billiard/process.py", line 292, in _bootstrap
    self.run()
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/beat.py", line 553, in run
    self.service.start(embedded_process=True)
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/beat.py", line 470, in start
    humanize_seconds(self.scheduler.max_interval))
  File "/app/.heroku/python/lib/python3.5/site-packages/kombu/utils/__init__.py", line 325, in __get__
    value = obj.__dict__[self.__name__] = self.__get(obj)
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/beat.py", line 512, in scheduler
    return self.get_scheduler()
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/beat.py", line 507, in get_scheduler
    lazy=lazy)
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/utils/imports.py", line 53, in instantiate
    return symbol_by_name(name)(*args, **kwargs)
  File "/app/.heroku/python/lib/python3.5/site-packages/djcelery/schedulers.py", line 151, in __init__
    Scheduler.__init__(self, *args, **kwargs)
  File "/app/.heroku/python/lib/python3.5/site-packages/celery/beat.py", line 185, in __init__
    self.setup_schedule()
  File "/app/.heroku/python/lib/python3.5/site-packages/djcelery/schedulers.py", line 158, in setup_schedule
    self.install_default_entries(self.schedule)
  File "/app/.heroku/python/lib/python3.5/site-packages/djcelery/schedulers.py", line 251, in schedule
    self._schedule = self.all_as_schedule()
  File "/app/.heroku/python/lib/python3.5/site-packages/djcelery/schedulers.py", line 164, in all_as_schedule
    for model in self.Model.objects.enabled():
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/models/query.py", line 258, in __iter__
    self._fetch_all()
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/models/query.py", line 1074, in _fetch_all
    self._result_cache = list(self.iterator())
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/models/query.py", line 52, in __iter__
    results = compiler.execute_sql()
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/models/sql/compiler.py", line 848, in execute_sql
    cursor.execute(sql, params)
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
    return self.cursor.execute(sql, params)
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/utils.py", line 95, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/app/.heroku/python/lib/python3.5/site-packages/django/utils/six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "/app/.heroku/python/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
    return self.cursor.execute(sql, params)
django.db.utils.OperationalError: SSL SYSCALL error: Bad file descriptor

1 个答案:

答案 0 :(得分:0)

我现在已经解决了这个问题...我的Django代码中有一行过去曾导致内部服务器错误 - 我认为,早在Django启动时,它就试图访问在创建模型的迁移运行之前的模型。

我已经解决了这个问题,但注意到这些" SSL SYSCALL错误" s大约在同一时间启动。所以我删除了那行代码,Celery又重新启动了。

这可能是巧合。而且我不明白为什么这个固定的东西。

理想情况下,我仍然希望了解上面的错误意味着什么,以便我将来有更好的机会修复此类事情。