/var/log/openproject/web-1.log
chroot: invalid group `Domain'
chroot: invalid group `Users'
chroot: invalid group `Domain'
chroot: invalid group `Users'
chroot: invalid group `Domain'
chroot: invalid group `Users'
chroot: invalid group `Domain'
chroot: invalid group `Users'
chroot: invalid group `Domain'
chroot: invalid group `Users'
Let me know if you should need more info.
thanx
Sascha
docker ps --all
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
224d93632a93 docker.software-univention.de/ucs-appbox-amd64:4.1-4 "/sbin/init" 12 days ago Up 12 hours 0.0.0.0:40001->80/tcp compassionate_shaw
your log shows that your Apache tries to connect to port 6000 whereas OpenProject should be running on Port 40001. Then again, your netstat output doesn’t show a service listening on either port.
Is your netstat output complete? Let’s try this command instead: lsof -PniTCP:40001 -sTCP:LISTEN
It looks like your Apache configuration files are not up to date. Please run the following:
My guess is that you modified the templates for the Apache configuration files and you didn’t migrate those changes to the new versions of the templates created during the upgrade.
Ah. Your openproject user is member of the Domain Users group, which isn’t the default (compared to one of my test systems). It looks like one of the start scripts cannot deal with group names with spaces in them.
My guess is the following:
You created a user called openproject in your UCS. That user’s primary group is Domain Users, or he’s a member of the Domain Users LDAP group.
Inside the Docker container there’s a local user also called openproject (as well as a local group called openproject).
The Docker container’s user & group management is LDAP-enabled, meaning the local and LDAP user & group information will be merged.
During the start of the unicorn process the group information is used, probably for changing ownership or ensuring access to certain files and folders. That’s most likely implemented as a shell script, or as a script that executes certain commands via the shell, and in those commands user & group names aren’t escaped properly — leading to errors that there’s no group named Domain and no group named Users.
If that’s correct and you don’t need that LDAP user openproject, simply delete it and restart the Docker container.
Hi,
well, yes, there is a user openproject in LDAP:
Sure it’s safe to delete? Nobody created this one manually i was told…
But i just looked it up in our test environment, and it seems you’re right…we don’t have any openproject user here.
Maybe it’s a remnant from an installation of a previous OpenProject version where adding such a user was still part of the installation process. I’m pretty sure it isn’t needed for the Dockerized OpenProject app. Therefore it should be safe to remove.
don’t know what exactly triggered it, but we have that error again now.
Openproject is not reachable, because of the openproject-web-1 service is not running.
The user “openproject” that caused the service to start before is unexistant now, so i don’t really know what i should do.
Here’s what i was able to see inside the openproject docker:
root@openp-89848117:/# service openproject status
openproject-web-1 is not running
tail -f /var/log/apache2/error.log
[Mon Oct 01 18:09:57 2018] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:6000 (127.0. 0.1) failed
[Mon Oct 01 18:09:57 2018] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Mon Oct 01 18:09:57 2018] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:6000 (127.0. 0.1) failed
[Mon Oct 01 18:09:57 2018] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Mon Oct 01 18:09:57 2018] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:6000 (127.0. 0.1) failed
[Mon Oct 01 18:09:57 2018] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Mon Oct 01 18:09:57 2018] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:6000 (127.0. 0.1) failed
[Mon Oct 01 18:09:57 2018] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[Mon Oct 01 18:10:48 2018] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:6000 (127.0. 0.1) failed
[Mon Oct 01 18:10:48 2018] [error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
tail -f /var/log/openproject/worker-1.log
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/lib/bundler/cli.rb:20:in `dispatch'
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/lib/bundler/vendor/thor/lib/thor/base.rb:444:in `start'
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/lib/bundler/cli.rb:10:in `start'
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/exe/bundle:35:in `block in <top (required)>'
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/lib/bundler/friendly_errors.rb:121:in `with_friendly_errors'
/opt/openproject/vendor/bundle/ruby/2.4.0/gems/bundler-1.15.1/exe/bundle:27:in `<top (required)>'
/opt/openproject/bin/bundle:3:in `load'
/opt/openproject/bin/bundle:3:in `<main>'
Tasks: TOP => jobs:work => jobs:environment_options => environment:full
(See full trace by running task with --trace)
Update:
After restarting the complete UCS openproject is now up and running again.
Note that i did try to restart the openproject services in the docker before, but they refused to do so.
when you post log files, please post the full error messages. Simply calling tail on the log files doesn’t suffice as stack traces are often very long. For most programming languages the important part can usually be found at the start of the stack trace, not at the end (with the notable exception of Python — but this is Ruby, not Python).
