https://launchpad.net/~ahasenack/+archive/ubuntu/squid- smp-1815852/+packages has test packages for cosmic with both fixes (#1816006 and #1815852).
** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. + + [Test Case] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. + + [Regression Potential] + + * discussion of how regressions are most likely to manifest as a result + of this change. + + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. + + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: - * spin up fresh cosmic or bionic instance/machine + * spin up fresh cosmic or bionic instance/machine - * install squid + * install squid - * configure 'workers 5' or enable the Rock Store cache storage type + * configure 'workers 5' or enable the Rock Store cache storage type - * reboot instance + * reboot instance - * try start up squid. + * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] - * An explanation of the effects of the bug on users and + * An explanation of the effects of the bug on users and - * justification for backporting the fix to the stable release. + * justification for backporting the fix to the stable release. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. [Test Case] + * install squid + sudo apt update && sudo apt install squid -y - * detailed instructions how to reproduce the bug + * verify there is no /var/run/squid directory + $ sudo ls -la /var/run/squid + ls: cannot access '/var/run/squid': No such file or directory - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + * Due to bug #1815852, squid won't work correctly even after that + directory is created, so let's consider the above enough to confirm this + bug here. + + With the updated packages, the directory exists, and, due to the restart done by the upgade, it is populated: + $ sudo ls -la /var/run/squid + total 0 + drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . + drwxr-xr-x 22 root root 820 Feb 28 18:35 .. + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc + srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc + + * and the proxy works: + $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null + --2019-02-28 18:35:59-- http://www.ubuntu.com/ + Resolving localhost (localhost)... 127.0.0.1 + Connecting to localhost (localhost)|127.0.0.1|:3128... connected. + Proxy request sent, awaiting response... 302 Found + Location: https://www.ubuntu.com/ [following] + --2019-02-28 18:36:00-- https://www.ubuntu.com/ + Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 + Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. + HTTP request sent, awaiting response... 200 OK + Length: unspecified [text/html] + Saving to: ‘/dev/null’ + + /dev/null [ <=> + ] 129.75K 148KB/s in 0.9s + + 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] + + $ echo $? + 0 [Regression Potential] - * discussion of how regressions are most likely to manifest as a result + * discussion of how regressions are most likely to manifest as a result of this change. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] - - * An explanation of the effects of the bug on users and - - * justification for backporting the fix to the stable release. - - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + Squid in SMP mode, when "workers <N>" is set in squid.conf, uses /var/run/squid for several ipc sockets. This directory is not created by the packaging/service and as a result squid doesn't work in this situation. [Test Case] * install squid sudo apt update && sudo apt install squid -y * verify there is no /var/run/squid directory $ sudo ls -la /var/run/squid ls: cannot access '/var/run/squid': No such file or directory * Due to bug #1815852, squid won't work correctly even after that directory is created, so let's consider the above enough to confirm this bug here. With the updated packages, the directory exists, and, due to the restart done by the upgade, it is populated: $ sudo ls -la /var/run/squid total 0 drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . drwxr-xr-x 22 root root 820 Feb 28 18:35 .. srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc * and the proxy works: $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null --2019-02-28 18:35:59-- http://www.ubuntu.com/ Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 302 Found Location: https://www.ubuntu.com/ [following] --2019-02-28 18:36:00-- https://www.ubuntu.com/ Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 129.75K 148KB/s in 0.9s 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] $ echo $? 0 [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] Squid in SMP mode, when "workers <N>" is set in squid.conf, uses /var/run/squid for several ipc sockets. This directory is not created by the packaging/service and as a result squid doesn't work in this situation. [Test Case] * install squid sudo apt update && sudo apt install squid -y * verify there is no /var/run/squid directory $ sudo ls -la /var/run/squid ls: cannot access '/var/run/squid': No such file or directory * Due to bug #1815852, squid won't work correctly even after that directory is created, so let's consider the above enough to confirm this bug here. - With the updated packages, the directory exists, and, due to the restart done by the upgade, it is populated: + With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgade, it is populated: $ sudo ls -la /var/run/squid total 0 drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . drwxr-xr-x 22 root root 820 Feb 28 18:35 .. srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc * and the proxy works: $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null --2019-02-28 18:35:59-- http://www.ubuntu.com/ Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 302 Found Location: https://www.ubuntu.com/ [following] --2019-02-28 18:36:00-- https://www.ubuntu.com/ Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 129.75K 148KB/s in 0.9s 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] $ echo $? 0 [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] Squid in SMP mode, when "workers <N>" is set in squid.conf, uses /var/run/squid for several ipc sockets. This directory is not created by the packaging/service and as a result squid doesn't work in this situation. [Test Case] * install squid sudo apt update && sudo apt install squid -y * verify there is no /var/run/squid directory $ sudo ls -la /var/run/squid ls: cannot access '/var/run/squid': No such file or directory * Due to bug #1815852, squid won't work correctly even after that directory is created, so let's consider the above enough to confirm this bug here. - With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgade, it is populated: + With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgrade, it is populated: $ sudo ls -la /var/run/squid total 0 drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . drwxr-xr-x 22 root root 820 Feb 28 18:35 .. srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc * and the proxy works: $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null --2019-02-28 18:35:59-- http://www.ubuntu.com/ Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 302 Found Location: https://www.ubuntu.com/ [following] --2019-02-28 18:36:00-- https://www.ubuntu.com/ Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 129.75K 148KB/s in 0.9s 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] $ echo $? 0 [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] Squid in SMP mode, when "workers <N>" is set in squid.conf, uses /var/run/squid for several ipc sockets. This directory is not created by the packaging/service and as a result squid doesn't work in this situation. [Test Case] * install squid sudo apt update && sudo apt install squid -y * verify there is no /var/run/squid directory $ sudo ls -la /var/run/squid ls: cannot access '/var/run/squid': No such file or directory * Due to bug #1815852, squid won't work correctly even after that directory is created, so let's consider the above enough to confirm this bug here. - With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgrade, it is populated: + With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgrade, is populated already: $ sudo ls -la /var/run/squid total 0 drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . drwxr-xr-x 22 root root 820 Feb 28 18:35 .. srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc * and the proxy works: $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null --2019-02-28 18:35:59-- http://www.ubuntu.com/ Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 302 Found Location: https://www.ubuntu.com/ [following] --2019-02-28 18:36:00-- https://www.ubuntu.com/ Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 129.75K 148KB/s in 0.9s 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] $ echo $? 0 [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory ** Description changed: [Impact] Squid in SMP mode, when "workers <N>" is set in squid.conf, uses /var/run/squid for several ipc sockets. This directory is not created by the packaging/service and as a result squid doesn't work in this situation. [Test Case] * install squid sudo apt update && sudo apt install squid -y * verify there is no /var/run/squid directory $ sudo ls -la /var/run/squid ls: cannot access '/var/run/squid': No such file or directory * Due to bug #1815852, squid won't work correctly even after that directory is created, so let's consider the above enough to confirm this bug here. With the updated packages, which also fix #1815852, the directory exists, and, due to the restart done by the upgrade, is populated already: $ sudo ls -la /var/run/squid total 0 drwxr-xr-x 2 proxy proxy 160 Feb 28 18:35 . drwxr-xr-x 22 root root 820 Feb 28 18:35 .. srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-coordinator.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-1.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-2.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-3.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-4.ipc srwxr-x--- 1 proxy proxy 0 Feb 28 18:35 squid-kid-5.ipc * and the proxy works: $ http_proxy=http://localhost:3128/ wget http://www.ubuntu.com -O /dev/null --2019-02-28 18:35:59-- http://www.ubuntu.com/ Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3128... connected. Proxy request sent, awaiting response... 302 Found Location: https://www.ubuntu.com/ [following] --2019-02-28 18:36:00-- https://www.ubuntu.com/ Resolving www.ubuntu.com (www.ubuntu.com)... 91.189.89.115 Connecting to www.ubuntu.com (www.ubuntu.com)|91.189.89.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 129.75K 148KB/s in 0.9s 2019-02-28 18:36:02 (148 KB/s) - ‘/dev/null’ saved [132866] $ echo $? 0 [Regression Potential] - - * discussion of how regressions are most likely to manifest as a result - of this change. - - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + The fix tells systemd to create the runtime directory /run/squid (to which /var/run is a symlink) via the tmpfiles.d mechanism, a solution used by many other services already as can be seen in "ls -la /usr/lib/tmpfiles.d". This only works for systemd systems, which is the case of cosmic and disco. + The fix is already in disco, but going through migration at the moment. [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + Not at this time. [Original Description] Hi, On squid service start up in Bionic, /var/run/squid is created by /etc/init.d/squid (create_run_dir()). This doesn't happen in Cosmic nor Disco and probably is related to the migration to systemd. Squid needs to create the squid-kid-*.ipc UNIX sockets in /var/run/squid to function on SMP set ups (workers X). Steps to reproduce: * spin up fresh cosmic or bionic instance/machine * install squid * configure 'workers 5' or enable the Rock Store cache storage type * reboot instance * try start up squid. Logging shows this: | 2019/02/15 04:46:58 kid1| commBind Cannot bind socket FD 28 to [::]: (2) No such file or directory -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1816006 Title: /var/run/squid (run_dir) no longer created on start up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid/+bug/1816006/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
