[Bug 1816006] Re: /var/run/squid (run_dir) no longer created on start up
Andreas Hasenack
andreas at canonical.com
Thu Feb 28 18:44:26 UTC 2019
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
More information about the Ubuntu-server-bugs
mailing list