Cannot connect to zammad after new install in Debain LXC

Infos:

  • Used Zammad version: 3.0 beta
  • Used Zammad installation source: (source, package, …): package
  • Operating system: Debian 9
  • Browser + version: Chrome Latest

Expected behavior:

  • Access zammad server on its local ip

Actual behavior:

  • 502 Bad Gateway

Steps to reproduce the behavior:

  • Install Zabbad in Debian 9 LXC (Under Proxmox VE) per the documentation @ https://docs.zammad.org/en/latest/install-debian.html

  • Modify server_name for nginx site config file, and set it to 10.5.0.30 (also tried with a DNS host override)

  • Attempt to connect to zammad server, and get 502 Bad Gateway

root@zammad:~# cat /var/log/nginx/zammad.error.log
2019/07/03 03:59:31 [error] 375#375: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 10.5.0.105, server: 10.5.0.30, request: “GET / HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “10.5.0.30”
root@zammad:~# telnet localhost 3000
Trying ::1…
Trying 127.0.0.1…
telnet: Unable to connect to remote host: Connection refused

Looks like your Zammad isn’t running or your firewall blocking access to localhost.
Ensure Zammad is running~

Thanks for the reply.

I checked that before posting, and now again, and zammad appears to be running:

systemctl status zammad

● zammad.service
Loaded: loaded (/etc/systemd/system/zammad.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-07-04 12:28:53 UTC; 18min ago
Main PID: 69 (sleep)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/zammad.service
└─69 /bin/sleep infinity

Jul 04 12:28:53 zammad systemd[1]: zammad.service: Failed to set invocation ID on control group /sys
Jul 04 12:28:53 zammad systemd[1]: Started zammad.serv>ice.

The logs in /var/log/zammad are essentially empty.

Clearly, however, something should be listening on 3000, and the other port, yet isn’t.

Only sleep is running…

Main PID: 69 (sleep)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/zammad.service
└─69 /bin/sleep infinity

I’m not familiar with the Debian packages, but I think something is very wrong here.

Nah this looks fine, here’s mine:

root@lx-zammad:/home/zammad# systemctl status zammad
â zammad.service
   Loaded: loaded (/etc/systemd/system/zammad.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-06-27 16:31:49 CEST; 6 days ago
 Main PID: 6683 (sleep)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/zammad.service
           ââ6683 /bin/sleep infinity

What’s interesting is maybe that part:

Jul 04 12:28:53 zammad systemd[1]: zammad.service: Failed to set invocation ID on control group /sys
Jul 04 12:28:53 zammad systemd[1]: Started zammad.serv>ice.

It might be worth mentioning that it seems to be taking up way to much CPU. 4 cores are at 70% usage right now.

Also, there seems to be some issue with postgres (not to state the obvious).

If I check the scheduler_error.log at just the right time, i see this:

PG::ConnectionBad: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/pg-0.21.0/lib/pg.rb:56:in `initialize'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/pg-0.21.0/lib/pg.rb:56:in `new'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/pg-0.21.0/lib/pg.rb:56:in `connect'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:705:in `connect'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:229:in `initialize'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:46:in `new'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:46:in `postgresql_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:761:in `new_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:805:in `checkout_new_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:784:in `try_to_checkout_new_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:745:in `acquire_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:502:in `checkout'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:376:in `connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:933:in `retrieve_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_handling.rb:116:in `retrieve_connection'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activerecord-5.1.7/lib/active_record/connection_handling.rb:88:in `connection'
  /opt/zammad/config/initializers/db_preferences_postgresql.rb:14:in `<top (required)>'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:286:in `load'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:286:in `block in load'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:258:in `load_dependency'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.7/lib/active_support/dependencies.rb:286:in `load'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/engine.rb:655:in `block in load_config_initializer'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/activesupport-5.1.7/lib/active_support/notifications.rb:168:in `instrument'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/engine.rb:654:in `load_config_initializer'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/engine.rb:612:in `block (2 levels) in <class:Engine>'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/engine.rb:611:in `each'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/engine.rb:611:in `block in <class:Engine>'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:30:in `instance_exec'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:30:in `run'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:59:in `block in run_initializers'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:228:in `block in tsort_each'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:422:in `block (2 levels) in each_strongly_connected_component_from'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:431:in `each_strongly_connected_component_from'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:421:in `block in each_strongly_connected_component_from'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:48:in `each'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:48:in `tsort_each_child'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:415:in `call'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:415:in `each_strongly_connected_component_from'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:349:in `block in each_strongly_connected_component'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:347:in `each'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:347:in `call'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:347:in `each_strongly_connected_component'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:226:in `tsort_each'
  /opt/zammad/vendor/ruby-2.4.4/lib/ruby/2.4.0/tsort.rb:205:in `tsort_each'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/initializable.rb:58:in `run_initializers'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/railties-5.1.7/lib/rails/application.rb:353:in `initialize!'
  /opt/zammad/config/environment.rb:5:in `<top (required)>'
  script/scheduler.rb:58:in `require'
  script/scheduler.rb:58:in `block in <top (required)>'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons/application.rb:275:in `block in start_proc'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons/application.rb:284:in `start_proc'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons/application.rb:305:in `start'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons/controller.rb:56:in `run'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons.rb:199:in `block in run_proc'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons/cmdline.rb:121:in `catch_exceptions'
  /opt/zammad/vendor/bundle/ruby/2.4.0/gems/daemons-1.3.1/lib/daemons.rb:198:in `run_proc'
  script/scheduler.rb:54:in `<top (required)>'

… and if I check a second later, for whatever reason, it’s gone.

Postgres seems to be happily chugging along however:

# systemctl status postgresql.service 
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2019-07-04 12:28:53 UTC; 37min ago
  Process: 62 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 62 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/postgresql.service

Jul 04 12:28:53 zammad systemd[1]: postgresql.service: Failed to reset devices.list: Operation not p
Jul 04 12:28:53 zammad systemd[1]: postgresql.service: Failed to set invocation ID on control group 
Jul 04 12:28:53 zammad systemd[1]: Starting PostgreSQL RDBMS...
Jul 04 12:28:53 zammad systemd[1]: Started PostgreSQL RDBMS.
Jul 04 12:28:53 zammad systemd[1]: postgresql.service: Failed to reset devices.list: Operation not p
Jul 04 12:28:53 zammad systemd[1]: postgresql.service: Failed to set invocation ID on control group 

The errors in the output are apparently expected for LXC deployments. Many services show similar ones.

Next, I’m going to take a look at the DB and see if it imported OK. However, while I’m pretty familiar with MySQL/MariaDB, I’m not at all familiar with postgres, so I’ll have to come back to this in a couple of hours.

Ah, the zammad unit might be a “pseudo” unit that itself does nothing and depends on multiple others units for the scheduler/websocket/railsserver?

That’s not the real postgres unit, that one is definitely just a pseudo unit that doesn’t actually do anything. Check your postgresql@x.y-z unit, where x.y is the version number and z is the cluster name. Could be postgresql@9.6-main or something like that. Better yet, just run systemctl and scroll through the list and look for any broken units highlighted in red.

By having a look at zammad.service i’d say you’re kinda on the right track ;D

[Unit]
StopWhenUnneeded=true

[Service]
# this service is just a placeholder
ExecStart=/bin/sleep infinity

[Install]
WantedBy=multi-user.target

This seems to be the source of the problem.

There is a postgresql@ unit, but no template within that.

I tried manually starting the service with postgresql@3.0-main, but no luck:

systemctl start postgresql@3.0-main
root@zammad:~# systemctl status postgresql.service 
root@zammad:~# systemctl status postgresql@3.0-main
● postgresql@3.0-main.service - PostgreSQL Cluster 3.0-main
   Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

I’m following the guide here:

https://docs.zammad.org/en/latest/install-debian.html

I don’t see what I could have skipped. The openvpn service uses templates similarly, but in that case the %i variable is set by the name of the server configuration file.

In this case, I’m not clear what it wants.

Any help is appreciated.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.