[Ubuntu-ha] [Bug 1855140] Re: How to handle tmpfiles.d in non-systemd environments
This waits on systemd for a general approach/solution. Related discussions that happened already: - https://lists.debian.org/debian-devel/2020/01/msg00032.html - https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040911.html ** Tags removed: server-triage-discuss -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy 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 %MEMVSZ RSS TTY STAT START TIME COMMAND root10 0.1 0.0 18616 3416 pts/0Ss 15:42 0:00 /bin/bash root32 0.0 0.0 34400 2900 pts/0R+ 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 # 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
[Ubuntu-ha] [Bug 1855140] Re: How to handle tmpfiles.d in non-systemd environments
> 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 High Availability Team, which is subscribed to haproxy 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 %MEMVSZ RSS TTY STAT START TIME COMMAND root10 0.1 0.0 18616 3416 pts/0Ss 15:42 0:00 /bin/bash root32 0.0 0.0 34400 2900 pts/0R+ 15:45
[Ubuntu-ha] [Bug 1855140] Re: How to handle tmpfiles.d in non-systemd environments
Hi Christian According to https://www.debian.org/vote/2019/vote_002#outcome the decision was to use "Systemd but we support exploring alternatives". >From the proposal: "Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include." >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. Given the (still rising) popularity of Docker/Kubernetes containers, it would indeed by very nice that the affected packages (such as haproxy) do adjust for a non-systemd environment. -- You received this bug notification because you are a member of Ubuntu High Availability Team, which is subscribed to haproxy 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 %MEMVSZ RSS TTY STAT START TIME COMMAND root10 0.1 0.0 18616 3416 pts/0Ss 15:42 0:00 /bin/bash root32 0.0 0.0 34400 2900 pts/0R+ 15:45 0:00 \_ ps auxf root 1
[Ubuntu-ha] [Bug 1855140] Re: How to handle tmpfiles.d in non-systemd environments
I reworded the bug Description to be the general discussion that it is. Waiting for: - Debian GR [1] to complete as its decision has direct impact on how to handle this in packages - Ubuntu systemd maintainers to chime in as this might have been discussed in other bugs before [1]: https://www.debian.org/vote/2019/vote_002 ** Summary changed: - haproxy package misses creation of default stats socket path in Docker container + How to handle tmpfiles.d in non-systemd environments ** Description changed: + 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] + + [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 %MEMVSZ RSS TTY STAT START TIME COMMAND root10 0.1 0.0 18616 3416 pts/0Ss 15:42 0:00 /bin/bash root32 0.0 0.0 34400 2900 pts/0R+ 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 # 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. Suggest