> From my understanding this means that supporting an alternative init
system is optional ("Packages may include support for alternate init
systems besides systemd"). So basically this is up to the package
maintainer whether or not the package should support an alternative init
system.I'm not sure that the Docker use case was intended to be within the scope of the Debian GR. But nevertheless, I think that in Debian it's still up to package maintainers to decide to what extent to support the Docker use case as it always has been. The Debian GR was relevant in that it didn't end up mandating an alternative to tmpfiles.d for example which might have affected any technical solution to this general problem. For Ubuntu, I think it makes sense to support it and to send Debian package maintainers patches as appropriate. The question is: how, technically, can we resolve this particular issue? I think it would be best if it could be done centrally somehow, rather than tweaking each affected package individually. Could the systemd tmpfiles.d mechanism somehow be used by Docker image builds as a machine-readable list of temporary directories to arrange to be handled automatically? If so, then that one solution could fix this entire class of problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1855140 Title: How to handle tmpfiles.d in non-systemd environments Status in haproxy package in Ubuntu: Opinion Status in systemd package in Ubuntu: New Bug description: This is a general issue about systemd features like tmpfiles.d which won't run in some environments like docker containers. Packages more and more rely on that with haproxy being the example that opened the bug, but clearly not the only one. I wanted to add tasks for all affected, but a qucik check showed that there are almost to many. $ apt-file search tmpfiles.d | cut -d':' -f 1 | sort | uniq 129 at the moment and probably increasing. List of affected as of Dec 2019: acmetool anytun apt-cacher-ng bacula-common bind9 binkd bley bzflag-server ceph-common certmonger cockpit-ws colord connman courier-authdaemon courier-imap courier-ldap courier-mlm courier-mta courier-pop cryptsetup-bin cyrus-common dbus dhcpcanon diaspora-common dnssec-trigger ejabberd fail2ban firebird3.0-server freeipa-client freeipa-server glusterfs-server gvfs-common haproxy hddemux heartbeat htcondor i2pd inn inspircd iodine knot knot-resolver krb5-otp laptop-mode-tools lemonldap-ng-fastcgi-server libreswan lighttpd lirc lvm2 mailman mailman3 mailman3-web man-db mandos memcached mon mpd munge munin-common myproxy-server nagios-nrpe-server ngircd nrpe-ng nscd nsd nullmailer nut-client nut-server opencryptoki opendkim opendmarc opendnssec-enforcer opendnssec-signer opennebula opennebula-sunstone opensips open-vm-tools-desktop openvpn passwd pesign php7.2-fpm pidentd ploop postgresql-common prads prelude-correlator prelude-lml prelude-manager puppet pushpin resource-agents rkt rpcbind rsyslog samba-common-bin screen shairport-sync shibboleth-sp2-utils slurmctld slurmd slurmdbd sogo spice-vdagent sqwebmail sslh sudo sudo-ldap systemd systemd-container tcpcryptd tinyproxy tuned ulogd2 uptimed vrfydmn vsftpd w1retap-doc wdm wesnoth-1.12-server x2goserver-common xpra yadifa zabbix-agent zabbix-java-gateway zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3 zabbix-server-mysql zabbix-server-pgsql Handling of these heavily Depends on the recent Debian GR [1]. I'd suggest we wait how that turns out and then need to consider how (if?) to handle it in a central place, probably systemd or a derivative tool as started to be discussed in [2] If possible I'd avoid fixes in individual packages as it encourages growth of various workarounds for a problem that needs a general solution. [1]: https://www.debian.org/vote/2019/vote_002 [2]: https://lists.debian.org/debian-devel/2019/12/msg00060.html --- Original report below --- When installing the haproxy package from the current Ubuntu 18.04 Bionic repos, the package does not install the directory /run/haproxy. This directory is mentioned in the default config file /etc/haproxy/haproxy.cfg: stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners Starting HAProxy manually will show the following error: # /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg [ALERT] 337/154339 (24) : Starting frontend GLOBAL: cannot bind UNIX socket [/run/haproxy/admin.sock] After manual creation of the directory, the start works: # mkdir /run/haproxy # /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg # ps auxf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 10 0.1 0.0 18616 3416 pts/0 Ss 15:42 0:00 /bin/bash root 32 0.0 0.0 34400 2900 pts/0 R+ 15:45 0:00 \_ ps auxf root 1 0.0 0.0 18376 3016 ? Ss 15:40 0:00 bash /root/entrypoint.sh haproxy 31 0.0 0.0 54284 1252 ? Ss 15:45 0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg This can be reproduced with a simple Docker container the following Dockerfile: ---------------------------------------------- FROM ubuntu:18.04 MAINTAINER Claudio Kuenzler <c...@claudiokuenzler.com> # install packages RUN apt-get update \ && apt-get install -y -qq haproxy CMD ["/usr/sbin/haproxy","-f","/etc/haproxy/haproxy.cfg"] ---------------------------------------------- Checking the haproxy package for the run directory shows nothing: # dpkg -L haproxy | grep run ; date Wed Dec 4 15:58:52 UTC 2019 ******************************************* Update: After analysis of the haproxy package (see https://www.claudiokuenzler.com/blog/917/haproxy-ubuntu-18.04-docker- image-not-starting-cannot-bind-unix-socket), it turns out that the /run/haproxy directory is defined in debian/haproxy.tmpfile. However tmpfile's are only considered in systems with SystemD. As Docker containers run without Systemd, this directory is never created. Suggestion: Do not rely on Systemd to create /run/haproxy. Maybe use debian/haproxy.dirs? However the permissions are not set in this case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
