منذ الترقية من 1.6.x إلى 2.1.x ، لاحظنا عدم سحب الرسائل بعد الآن. هذا عندما لاحظنا أن المجدول يواجه خطأ في اتصاله بـ PostgreSQL.
channel is active but not fetched for 1 hour
channel is active but not fetched for 1 hour
channel is active but not fetched for 1 hour
channel is active but not fetched for 1 hour
scheduler not running
==> /var/log/zammad/scheduler_err.log <==
ActiveRecord::StatementInvalid: PG::ConnectionBad: PQconsumeInput() could not receive data from server: Bad file descriptor
: SELECT "delayed_jobs".* FROM "delayed_jobs"
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `async_exec'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `block in exec_no_cache'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:590:in `block in log'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.0.5/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:583:in `log'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in `exec_no_cache'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:585:in `execute_and_clear'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql/database_statements.rb:103:in `exec_query'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/database_statements.rb:377:in `select_prepared'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/database_statements.rb:39:in `select_all'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/query_cache.rb:95:in `select_all'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/querying.rb:39:in `find_by_sql'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:702:in `exec_queries'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:583:in `load'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:260:in `records'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation/delegation.rb:38:in `each'
/opt/zammad/app/models/scheduler.rb:78:in `cleanup'
/opt/zammad/app/models/scheduler.rb:24:in `threads'
script/scheduler.rb:66:in `block in <top (required)>'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons/application.rb:266:in `block in start_proc'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons/application.rb:275:in `start_proc'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons/application.rb:296:in `start'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons/controller.rb:56:in `run'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons.rb:197:in `block in run_proc'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons/cmdline.rb:92:in `catch_exceptions'
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.2.4/lib/daemons.rb:196:in `run_proc'
script/scheduler.rb:49:in `<top (required)>'
==> /var/log/zammad/scheduler_out.log <==
bundler: failed to load command: script/scheduler.rb (script/scheduler.rb)
إن PostgreSQL قابل للاتصال ويعمل بشكل جيد.
يحدث هذا عادة عندما لا توجد مساحة متبقية في temp أو مخزن البيانات. لا أعتقد أن هذا متعلق بزماد. تتبع الارتداد مباشرة من
سجل نشط
أقترح التحقق من نظام الملفات (الفراغ و inodes) وإجراء فحص لقاعدة بيانات PG.
يحرر:
ماذا يحدث عند إعادة تشغيل كل من المجدول و Postgresql؟
ملحوظة:
من فضلك لا تستخدم فرع التطوير في الإنتاج! 2.0 مستقر
نظام الملفات لا يبدو في أي مكان قريبًا من الامتلاء.
hexa<strong i="6">@tickets</strong>:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 20G 6.2G 13G 34% /
udev 10M 0 10M 0% /dev
tmpfs 502M 45M 457M 9% /run
tmpfs 1.3G 16K 1.3G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.3G 0 1.3G 0% /sys/fs/cgroup
tmpfs 251M 0 251M 0% /run/user/2000
hexa<strong i="7">@tickets</strong>:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 1310720 97329 1213391 8% /
udev 314738 268 314470 1% /dev
tmpfs 320664 313 320351 1% /run
tmpfs 320664 5 320659 1% /dev/shm
tmpfs 320664 3 320661 1% /run/lock
tmpfs 320664 13 320651 1% /sys/fs/cgroup
tmpfs 320664 4 320660 1% /run/user/2000
لا يبدو أن PostgreSQL لديها أي ميكانيكي فحص داخلي. إعادة تشغيل كلاهما لا يغير الوضع.
أفهم عدم استخدام فرع التطوير ، لكننا احتجنا أن نبدأ بـ 1.6 لأننا طلبنا LDAP ثم ننسى تثبيت الإصدار.
كما أن PostgreSQL متاح بشكل واضح ويمكن الوصول إليه. يعمل هذا أيضًا مع بيانات الاعتماد المحددة في /opt/zammad/config/database.yml
.
root<strong i="7">@tickets</strong>:/home/hexa# sudo -u postgres psql
psql (9.4.13)
Type "help" for help.
postgres=# \connect zammad
You are now connected to database "zammad" as user "postgres".
zammad=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------------------------------+-------+--------
public | activity_streams | table | zammad
public | ar_internal_metadata | table | zammad
public | authorizations | table | zammad
public | avatars | table | zammad
public | calendars | table | zammad
public | channels | table | zammad
public | chat_agents | table | zammad
public | chat_messages | table | zammad
public | chat_sessions | table | zammad
public | chat_topics | table | zammad
public | chats | table | zammad
public | cti_caller_ids | table | zammad
public | cti_logs | table | zammad
public | delayed_jobs | table | zammad
public | email_addresses | table | zammad
public | external_credentials | table | zammad
public | external_syncs | table | zammad
public | groups | table | zammad
public | groups_users | table | zammad
public | histories | table | zammad
public | history_attributes | table | zammad
public | history_objects | table | zammad
public | history_types | table | zammad
public | http_logs | table | zammad
public | import_jobs | table | zammad
public | jobs | table | zammad
public | karma_activities | table | zammad
public | karma_activity_logs | table | zammad
public | karma_users | table | zammad
public | link_objects | table | zammad
public | link_types | table | zammad
public | links | table | zammad
public | locales | table | zammad
public | macros | table | zammad
public | network_categories | table | zammad
public | network_categories_moderator_users | table | zammad
public | network_category_subscriptions | table | zammad
public | network_category_types | table | zammad
public | network_item_comments | table | zammad
public | network_item_plus | table | zammad
public | network_item_subscriptions | table | zammad
public | network_items | table | zammad
public | network_privacies | table | zammad
public | networks | table | zammad
public | notifications | table | zammad
public | oauth_access_grants | table | zammad
public | oauth_access_tokens | table | zammad
public | oauth_applications | table | zammad
public | object_lookups | table | zammad
public | object_manager_attributes | table | zammad
public | online_notifications | table | zammad
public | organizations | table | zammad
public | organizations_users | table | zammad
public | overviews | table | zammad
public | overviews_groups | table | zammad
public | overviews_roles | table | zammad
public | overviews_users | table | zammad
public | package_migrations | table | zammad
public | packages | table | zammad
public | permissions | table | zammad
public | permissions_roles | table | zammad
public | postmaster_filters | table | zammad
public | recent_views | table | zammad
public | report_profiles | table | zammad
public | roles | table | zammad
public | roles_groups | table | zammad
public | roles_users | table | zammad
public | schedulers | table | zammad
public | schema_migrations | table | zammad
public | sessions | table | zammad
public | settings | table | zammad
public | signatures | table | zammad
public | slas | table | zammad
public | stats_stores | table | zammad
public | store_files | table | zammad
public | store_objects | table | zammad
public | store_provider_dbs | table | zammad
public | stores | table | zammad
public | tag_items | table | zammad
public | tag_objects | table | zammad
public | tags | table | zammad
public | taskbars | table | zammad
public | templates | table | zammad
public | templates_groups | table | zammad
public | text_modules | table | zammad
public | text_modules_groups | table | zammad
public | ticket_article_flags | table | zammad
public | ticket_article_senders | table | zammad
public | ticket_article_types | table | zammad
public | ticket_articles | table | zammad
public | ticket_counters | table | zammad
public | ticket_flags | table | zammad
public | ticket_priorities | table | zammad
public | ticket_state_types | table | zammad
public | ticket_states | table | zammad
public | ticket_time_accountings | table | zammad
public | tickets | table | zammad
public | tokens | table | zammad
public | translations | table | zammad
public | triggers | table | zammad
public | type_lookups | table | zammad
public | user_devices | table | zammad
public | users | table | zammad
(103 rows)
اليوم لدي نفس الشيء على نظام التشغيل Mac OS 10.12.6 (لكنه كان يعمل في الأيام السابقة 🤥) مع تطوير (Zammad 2.1). كل شيء يعمل (القضبان ج ، القضبان ، ...) متوقعًا المجدول.
لدي نفس الترقية من 1.5 إلى 2.0 100٪ استخدام وحدة المعالجة المركزية وهذا الخطأ
الذيل: Scheduler_err.log: Datei abgeschnitten
ActiveRecord :: StatementInvalid: PG :: ConnectionBad: تعذر على PQconsumeInput () تلقي البيانات من الخادم: واصف ملف تالف
: حدد "delayed_jobs". * من "delayed_jobs"
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:inasync_exec' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in
block in exec_no_cache '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:590:inblock in log' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.0.5/lib/active_support/notifications/instrumenter.rb:21:in
device '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract_adapter.rb:583:inlog' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:598:in
exec_no_cache '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql_adapter.rb:585:inexecute_and_clear' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/postgresql/database_statements.rb:103:in
exec_query '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/database_statements.rb:377:inselect_prepared' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/database_statements.rb:39:in
select_all '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/connection_adapters/abstract/query_cache.rb:95:inselect_all' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/querying.rb:39:in
find_by_sql '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:702:inexec_queries' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:583:in
load '
/opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation.rb:260:inrecords' /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.0.5/lib/active_record/relation/delegation.rb:38:in
لكل '
/opt/zammad/app/models/scheduler.rb:78:incleanup' /opt/zammad/app/models/scheduler.rb:24:in
thread '
script / Scheduler.rb: 66: في `block in
Hagelsturm أي نظام التشغيل؟ وما هي العملية التي تستغرق 100٪؟
في حالتنا هو script/scheduler.rb start -t
.
في حالتنا هو
script/scheduler.rb start -t
هذا أيضًا من جانبي. يعمل المجدول عادةً في الوضع الخفي ( script/scheduler.rb start
أو script/scheduler.rb stop
).
عادة ما يستخدم script/scheduler.rb start -t
للمطورين فقط لأن المجدول لا يعمل في الخلفية (كخفي).
mweinelt سؤال بالنسبة لي هو ، لماذا تستخدم -t
؟
JFI: برنامج الجدولة يعمل بشكل جيد بالنسبة لي في الخلفية (كخفي).
أنا أستخدم 2.1.1-1505985142.807a1d88.jessie
لأنني نسيت التثبيت في إصدار ثابت. يجب أن يأتي الخيار -t
من ملفات الخدمة ، ولم أقم بتغيير أي شيء في هذا الصدد.
root<strong i="8">@tickets</strong>:/opt/zammad# grep -ri "scheduler.rb start" *
contrib/systemd/zammad-scheduler.service:ExecStart=/bin/bash -l -c "${BUNDLE_BINARY} exec script/scheduler.rb start -t"
Procfile:worker: bundle exec script/scheduler.rb start -t
Procfile.frontend:worker: bundle exec ruby script/scheduler.rb start -t
script/init-script-normal-user-rvm-fedora: script/scheduler.rb start &> /dev/null && echo_success || echo_failure
script/init.d/zammad: execute "RAILS_ENV=production script/scheduler.rb start $SCHEDULER_OPTS"
script/build/test_startup.sh:bundle exec script/scheduler.rb start
script/local_browser_tests.sh:script/scheduler.rb start
vendor/pkgr/processes/worker:exec bundle exec script/scheduler.rb start -t $@
أستخدم Debian 8 بالأمس وأنا أجرب الإصدار 9 أيضًا
لكن الخطأ هو نفسه
أنا لا أقوم بتعديل أي شيء -t جاء من العبوة وليس مني
العملية بنسبة 100٪ هي روبي
النصي / جدولة. rb بدء -t
كل مرة تبدأ وتتحطم
من Scheduler.rb - Help:
ربما لكن المجدول يتعطل طوال الوقت
هل تعتقد أن السبب هو المعلمة ontop؟
تضمين التغريدة
لا ، أردت فقط توضيح ما يفعله. لم أر إجابة مارتيني.
يتم تنفيذ عملية الشيطان بواسطة systemd لذلك لا توجد مشكلة في العادة.
@مارتيني
إذا كنت أتذكر أن "-t" الصحيح يُستخدم لأن systemd يعتقد أن برنامج الجدولة قد فشل وتوقف عندما ينتقل إلى backround من ملف الوحدة.
تضمين التغريدة
إذا كنت تستخدم 2.1.1 فأنت في وضع الريبو.
لا توجد طريقة لتثبيت حزمة مستقرة هناك.
استخدم الريبو الثابت للحصول على حزم مستقرة: https://packager.io/gh/zammad/zammad/builds/2414/install/debian-8
تضمين التغريدة
يجب أن يسمح إعداد Type=forking
بالبدء بدون -t
إذا لم أكن مخطئًا.
فيما يتعلق بالرجوع إلى إصدار مستقر (2.0.x):
سأضطر إلى التراجع عن بعض عمليات الترحيل إذا لم يكن لدي نسخة احتياطية حديثة ، أليس كذلك؟
شكرا للتلميح. سنحاول تغييره لاحقا. لست متأكدًا مما إذا كان ذلك ممكنًا في packager.io.
حسنًا ، أستخدم الإصدار 2.0 الآن
ولكن لدي الآن مشكلة في قناة البريد الإلكتروني
البريد الإلكتروني :: لا يمكن للإخطار استخدام القناة :: برنامج التشغيل :: Smtp: # <: econnrefused: i = "6">
لا أستطيع التحقق من الإعدادات لأن الحساب فارغ :-(
القناة نشطة ولكن لم يتم جلبها لمدة ساعة واحدة
القناة: البريد الإلكتروني :: Notification out لا يمكن استخدام القناة :: Driver :: Smtp: # <: econnrefused: i = "7">
كيف يمكن ضبط جديد على CLI؟
Hagelsturm حاول التحقق من إعدادات smtp ، ربما لا توجد معلمة مضيف لـ SMTP في إعدادات قناة بريدك الإلكتروني. أيضًا ، بما أن مشكلتك مشكلة جديدة ، يجب عليك إنشاء عدد جديد؟
أهلا! نفس المشكلة هنا. لقد وصلت إلى هنا من # 1473. لقد قمت بتثبيت الإصدار 2.0 ولكن لم أتمكن من إضافة حساب بريد إلكتروني جديد على تكوين قناة البريد الإلكتروني ، ربما يتعلق بالتعليق الأخير منHagelsturm.
سأضطر إلى التراجع عن بعض عمليات الترحيل إذا لم يكن لدي نسخة احتياطية حديثة ، أليس كذلك؟
mweinelt آسف ، لم أر هذه التعليقات. في الوقت الحالي ، لا توجد عمليات ترحيل لقاعدة البيانات بين الاستقرار والتطوير. لذا يمكنك الآن التبديل بين المستقر / الرئيسي والتطوير دون مشاكل.
على أي حال ، يبدو أنني حصلت على مشكلة "واصف ملف تالف في PGConsumeInput" تم إصلاحها. لذلك إذا قمت بالتحديث ، فإن التطوير أولاً (قبل التبديل مرة أخرى إلى الوضع الثابت) سيكون جيدًا!
شكرا لملاحظاتك!
-مارتن
Hagelsturm JFI فعله مع مشكلة المجدول هذه. قضية أخرى ستكون جيدة لذلك.
martini يمكنني أن أؤكد أن التحديث فعل الحيلة. شكرا جزيلا!
سنحاول الرجوع إلى إصدار 2.0 قليلاً.
التعليق الأكثر فائدة
martini يمكنني أن أؤكد أن التحديث فعل الحيلة. شكرا جزيلا!
سنحاول الرجوع إلى إصدار 2.0 قليلاً.