passenger: passenger-config fails with "too long unix socket path" on Ubuntu 18.04 LTS
Issue report
When running Passenger on hosts upgraded from Ubuntu 16.04 LTS to 18.04 LTS, passenger-config fails with
Traceback (most recent call last):
9: from /usr/bin/passenger-config:37:in `<main>'
8: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/main.rb:79:in `run!'
7: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/restart_app_command.rb:46:in `run'
6: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/restart_app_command.rb:144:in `select_app_group_name'
5: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/restart_app_command.rb:174:in `select_app_group_name_interactively'
4: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/restart_app_command.rb:164:in `query_group_names'
3: from /usr/lib/ruby/vendor_ruby/phusion_passenger/config/restart_app_command.rb:255:in `query_pool_xml'
2: from /usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:95:in `http_request'
1: from /usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:95:in `new'
/usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:95:in `initialize': too long unix socket path (116bytes given but 108bytes max) (ArgumentError)
Question 1: What is the problem?
- What is the expected behavior?
Running passenger-config is possible.
- What is the actual behavior?
passenger-config fails with the above stack trace. Debugging shows that the UNIX socket path Passenger tries to use is something like
/tmp/systemd-private-673f3b327552487c9d5cc4d934decaf-apache2.service-GfIBRc/tmp/passenger.UqAQsAS/agents.s/core_api
which is over the system limit.
- How can we reproduce it?
I have not tried on a vanilla 18.04, but there seems to be additional evidence here, with no solution:
Your answer:
Question 2: Passenger version and integration mode:
Your answer:
Ubuntu libapache2-mod-passenger 1:6.0.12-1~bionic1
Question 3: OS or Linux distro, platform (including version):
Your answer:
Ubuntu 18.04.6 LTS
Question 4: Passenger installation method:
Your answer:
4.15.0-162-generic #170-Ubuntu SMP Mon Oct 18 11:38:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[] RubyGems + Gemfile [ ] RubyGems, no Gemfile [x] Phusion APT repo [ ] Phusion YUM repo [ ] OS X Homebrew [ ] source tarball [ ] Other, please specify:
Question 5: Your app’s programming language (including any version managers) and framework (including versions):
Your answer:
System Ruby is ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]
Question 6: Are you using a PaaS and/or containerization? If so which one?
Your answer:
No, plain VM
Question 7: Anything else about your setup that we should know?
Your answer:
As mentioned before, the system was upgraded from Ubuntu 16.04 LTS.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Comments: 18 (6 by maintainers)
I’m confused why this got closed, honestly? This, to me, is a bug that needs to be fixed, not band-aided by adjusting apache2’s systemd file. This package, including the one compatible with Ubuntu 20.04 is effectively broken straight out of the box.
@CamJN is there any chance that Phusion would take this back to the drawing board or raise an issue upstream with systemd?
Thanks for the pointers @CamJN !
For posterity, I resolved this by turning off the systemd private tmp feature by commenting out the line
in
/etc/systemd/system/multi-user.target.wants/apache2.serviceand then executingNow
passenger-controlhas been restored to its former glory.For Ubuntu 18+ I’d recommend doing this instead of altering the systemd file
/usr/lib/tmpfiles.d/passenger.confwithd /var/run/passenger-instreg root rootPassengerInstanceRegistryDir /var/run/passenger-instregorpassenger_instance_registry_dir /var/run/passenger-instregas appropriate for your apache/nginx configuration.This should work ok as the passenger tooling looks there as one of it’s default paths for the instance registry