** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. + If haproxy is running when rsyslog is restarted, haproxy will stop + logging requests due to an apparmor denial message: - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + [Tue Mar 3 14:00:54 2026] audit: type=1400 audit(1772546453.881:137): + apparmor="DENIED" operation="sendmsg" class="file" info="Failed name + lookup - disconnected path" error=-13 profile="rsyslogd" + name="var/lib/haproxy/dev/log" pid=5137 comm="haproxy" + requested_mask="r" denied_mask="r" fsuid=0 ouid=0 + + This happens because haproxy is using dev/log from inside a chroot, to + which rsyslog listens to (via /etc/rsyslog.d/49-haproxy.conf installed + by the haproxy package). This needs the apparmor flag + attach_disconnected. + + What makes this more critical is that anytime a config snippet is + installed in /etc/rsyslog.d/*, that will trigger an rsyslog restart (via + dpkg-triggers). This makes the bug potentially more frequent, and it + also affects haproxy upgrades themselves. + [ Test Plan ] - * detailed instructions how to reproduce the bug + This update includes a new autopkgtest called haproxy-logging which will + trigger the bug and verify that it is fixed. - * 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. + Therefore, the test plan for this SRU is to verify that the new haproxy- + logging autopackagetest succeeded: - * if other testing is appropriate to perform before landing this - update, this should also be described here. + 1318s autopkgtest [18:42:29]: test haproxy-logging: [----------------------- + 1318s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile + 1319s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. + 1319s ## Requesting http://localhost:8080/autopkgtest1392 + 1322s + 1322s ## Checking logs for GET /autopkgtest1392 + 1322s 2026-03-10T18:44:15.878187+00:00 autopkgtest haproxy[1405]: 127.0.0.1:49456 [10/Mar/2026:18:44:12.871] test-front test-back/test-1 0/0/-1/-1/3006 503 216 - - SC-- 1/1/0/0/3 0/0 "GET /autopkgtest1392 HTTP/1.1" + 1322s ## All tests passed! + 1322s autopkgtest [18:42:33]: test haproxy-logging: -----------------------] + 1323s autopkgtest [18:42:34]: test haproxy-logging: - - - - - - - - - - results - - - - - - - - - - + 1323s haproxy-logging PASS + + Here is an example where the test was run with an unpatched rsyslog: + + 137s autopkgtest [14:19:48]: test haproxy-logging: [----------------------- + 138s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile + 138s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. + 138s ## Requesting http://localhost:8080/autopkgtest8961 + 141s + 141s ## Checking logs for GET /autopkgtest8961 + 141s ## Something failed + 141s + 141s ## Getting last 100 of haproxy unit logs + ... + 141s ## Last 100 of /var/log/haproxy.log + 141s 2026-03-10T17:19:52.917606+00:00 n-rsyslog-dep8 haproxy[8974]: [ALERT] (8974) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) + [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + * Think about what the upload changes in the software. Imagine the + change is wrong or breaks something else: how would this show up? - * 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 must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + * This must never be "None" or "Low", or entirely an argument as to why + your upload is low risk. - * 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 + * Anything else you think is useful to include - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. + * Make sure to explain any deviation from the norm, to save the SRU + reviewer from having to infer your reasoning, possibly incorrectly. + This should also help reduce review iterations, particularly when the + reason for the deviation is not obvious. - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance - + * Anticipate questions from users, SRU, +1 maintenance, security teams + and the Technical Board and address these questions in advance [ Original Description ] After reloading haproxy with systemctl reload or after package upgrades, haproxy stops logging requests. The system logs show the following error messages: ``` kernel: audit: type=1400 audit(1768805529.843:1866): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="var/lib/haproxy/dev/log" pid=713657 comm="haproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ALERT] (713657) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) ``` Restarting haproxy with systemctl restart fixes the issue. This started happening with noble. jammy works fine.
** Description changed: [ Impact ] If haproxy is running when rsyslog is restarted, haproxy will stop logging requests due to an apparmor denial message: [Tue Mar 3 14:00:54 2026] audit: type=1400 audit(1772546453.881:137): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="var/lib/haproxy/dev/log" pid=5137 comm="haproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 This happens because haproxy is using dev/log from inside a chroot, to which rsyslog listens to (via /etc/rsyslog.d/49-haproxy.conf installed by the haproxy package). This needs the apparmor flag attach_disconnected. What makes this more critical is that anytime a config snippet is installed in /etc/rsyslog.d/*, that will trigger an rsyslog restart (via dpkg-triggers). This makes the bug potentially more frequent, and it also affects haproxy upgrades themselves. - [ Test Plan ] This update includes a new autopkgtest called haproxy-logging which will trigger the bug and verify that it is fixed. Therefore, the test plan for this SRU is to verify that the new haproxy- logging autopackagetest succeeded: 1318s autopkgtest [18:42:29]: test haproxy-logging: [----------------------- 1318s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile 1319s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. 1319s ## Requesting http://localhost:8080/autopkgtest1392 - 1322s + 1322s 1322s ## Checking logs for GET /autopkgtest1392 1322s 2026-03-10T18:44:15.878187+00:00 autopkgtest haproxy[1405]: 127.0.0.1:49456 [10/Mar/2026:18:44:12.871] test-front test-back/test-1 0/0/-1/-1/3006 503 216 - - SC-- 1/1/0/0/3 0/0 "GET /autopkgtest1392 HTTP/1.1" 1322s ## All tests passed! 1322s autopkgtest [18:42:33]: test haproxy-logging: -----------------------] 1323s autopkgtest [18:42:34]: test haproxy-logging: - - - - - - - - - - results - - - - - - - - - - 1323s haproxy-logging PASS Here is an example where the test was run with an unpatched rsyslog: 137s autopkgtest [14:19:48]: test haproxy-logging: [----------------------- 138s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile 138s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. 138s ## Requesting http://localhost:8080/autopkgtest8961 - 141s + 141s 141s ## Checking logs for GET /autopkgtest8961 141s ## Something failed - 141s + 141s 141s ## Getting last 100 of haproxy unit logs ... 141s ## Last 100 of /var/log/haproxy.log 141s 2026-03-10T17:19:52.917606+00:00 n-rsyslog-dep8 haproxy[8974]: [ALERT] (8974) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) - [ Where problems could occur ] - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + The fix is adding a flag to the rsyslog apparmor profile. Risks include: + - User has made local changes to /etc/apparmor.d/usr.sbin.rsyslogd (instead of /etc/apparmor.d/local/usr.sbin.rsyslogd) and didn't accept the updated config file from the updated package, or it's an automated update mechanism that will always preserve the old config file. + - The flag was added incorrectly to the profile, causing a syntax error after the update. The test plan covers this. + - Old apparmor somehow still running doesn't understand the new flag. The test plan covers current apparmor in each respective ubuntu release, and if the user has something older, that is out of scope. + - User has disabled apparmor. In this case, they would not be experiencing the bug, and will get a no-op download. + - The disconnected_path flag diminishes the protection rsyslog gets from apparmor. From what I can see and asked around, it's the best choice for such a case, and this flag is present in many other apparmor profiles shipped by ubuntu. - * 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 must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * 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 * Make sure to explain any deviation from the norm, to save the SRU reviewer from having to infer your reasoning, possibly incorrectly. This should also help reduce review iterations, particularly when the reason for the deviation is not obvious. * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board and address these questions in advance [ Original Description ] After reloading haproxy with systemctl reload or after package upgrades, haproxy stops logging requests. The system logs show the following error messages: ``` kernel: audit: type=1400 audit(1768805529.843:1866): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="var/lib/haproxy/dev/log" pid=713657 comm="haproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ALERT] (713657) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) ``` Restarting haproxy with systemctl restart fixes the issue. This started happening with noble. jammy works fine. ** Description changed: [ Impact ] If haproxy is running when rsyslog is restarted, haproxy will stop logging requests due to an apparmor denial message: [Tue Mar 3 14:00:54 2026] audit: type=1400 audit(1772546453.881:137): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="var/lib/haproxy/dev/log" pid=5137 comm="haproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 This happens because haproxy is using dev/log from inside a chroot, to which rsyslog listens to (via /etc/rsyslog.d/49-haproxy.conf installed by the haproxy package). This needs the apparmor flag attach_disconnected. What makes this more critical is that anytime a config snippet is installed in /etc/rsyslog.d/*, that will trigger an rsyslog restart (via dpkg-triggers). This makes the bug potentially more frequent, and it also affects haproxy upgrades themselves. [ Test Plan ] This update includes a new autopkgtest called haproxy-logging which will trigger the bug and verify that it is fixed. Therefore, the test plan for this SRU is to verify that the new haproxy- logging autopackagetest succeeded: 1318s autopkgtest [18:42:29]: test haproxy-logging: [----------------------- 1318s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile 1319s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. 1319s ## Requesting http://localhost:8080/autopkgtest1392 1322s 1322s ## Checking logs for GET /autopkgtest1392 1322s 2026-03-10T18:44:15.878187+00:00 autopkgtest haproxy[1405]: 127.0.0.1:49456 [10/Mar/2026:18:44:12.871] test-front test-back/test-1 0/0/-1/-1/3006 503 216 - - SC-- 1/1/0/0/3 0/0 "GET /autopkgtest1392 HTTP/1.1" 1322s ## All tests passed! 1322s autopkgtest [18:42:33]: test haproxy-logging: -----------------------] 1323s autopkgtest [18:42:34]: test haproxy-logging: - - - - - - - - - - results - - - - - - - - - - 1323s haproxy-logging PASS Here is an example where the test was run with an unpatched rsyslog: 137s autopkgtest [14:19:48]: test haproxy-logging: [----------------------- 138s Enforcing the /etc/apparmor.d/usr.sbin.rsyslogd apparmor profile 138s Setting /etc/apparmor.d/usr.sbin.rsyslogd to enforce mode. 138s ## Requesting http://localhost:8080/autopkgtest8961 141s 141s ## Checking logs for GET /autopkgtest8961 141s ## Something failed 141s 141s ## Getting last 100 of haproxy unit logs ... 141s ## Last 100 of /var/log/haproxy.log 141s 2026-03-10T17:19:52.917606+00:00 n-rsyslog-dep8 haproxy[8974]: [ALERT] (8974) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) [ Where problems could occur ] The fix is adding a flag to the rsyslog apparmor profile. Risks include: - User has made local changes to /etc/apparmor.d/usr.sbin.rsyslogd (instead of /etc/apparmor.d/local/usr.sbin.rsyslogd) and didn't accept the updated config file from the updated package, or it's an automated update mechanism that will always preserve the old config file. - The flag was added incorrectly to the profile, causing a syntax error after the update. The test plan covers this. - Old apparmor somehow still running doesn't understand the new flag. The test plan covers current apparmor in each respective ubuntu release, and if the user has something older, that is out of scope. - User has disabled apparmor. In this case, they would not be experiencing the bug, and will get a no-op download. - The disconnected_path flag diminishes the protection rsyslog gets from apparmor. From what I can see and asked around, it's the best choice for such a case, and this flag is present in many other apparmor profiles shipped by ubuntu. - [ Other Info ] - * Anything else you think is useful to include - - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. - - * 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 ] After reloading haproxy with systemctl reload or after package upgrades, haproxy stops logging requests. The system logs show the following error messages: ``` kernel: audit: type=1400 audit(1768805529.843:1866): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="rsyslogd" name="var/lib/haproxy/dev/log" pid=713657 comm="haproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ALERT] (713657) : sendmsg()/writev() failed in logger #1: Permission denied (errno=13) ``` Restarting haproxy with systemctl restart fixes the issue. This started happening with noble. jammy works fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2138647 Title: haproxy stops logging after reload with permission denied error To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/2138647/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
