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.