| 2019-10-16 11:21:50 |
Dr. Jens Harbott |
bug |
|
|
added bug |
| 2019-10-28 15:12:28 |
Launchpad Janitor |
auditd (Ubuntu): status |
New |
Confirmed |
|
| 2019-12-01 19:30:27 |
Scott Herren |
bug |
|
|
added subscriber Scott Herren |
| 2020-04-15 19:46:54 |
Kodiak Firesmith |
bug |
|
|
added subscriber Kodiak Firesmith |
| 2020-10-13 11:07:24 |
Markus Muehlberger |
bug |
|
|
added subscriber Markus Muehlberger |
| 2021-01-08 16:49:17 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2021-01-08 17:00:18 |
Andreas Hasenack |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1587995 |
|
| 2021-01-08 18:37:57 |
Andreas Hasenack |
auditd (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-01-08 18:38:57 |
Andreas Hasenack |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962451 |
|
| 2021-01-08 18:38:57 |
Andreas Hasenack |
bug task added |
|
audit (Debian) |
|
| 2021-01-08 18:40:12 |
Andreas Hasenack |
affects |
auditd (Ubuntu) |
audit (Ubuntu) |
|
| 2021-01-08 19:15:19 |
Bug Watch Updater |
audit (Debian): status |
Unknown |
New |
|
| 2021-01-08 20:31:06 |
Andreas Hasenack |
description |
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
[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.
[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?
* 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
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
|
| 2021-01-08 20:54:51 |
Andreas Hasenack |
description |
[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.
[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?
* 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
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification.
Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of the problem
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be looking for that message in the logs. It won't be there anymore after this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is present in Focal and later.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
|
| 2021-01-08 20:57:33 |
Andreas Hasenack |
description |
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification.
Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of the problem
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be looking for that message in the logs. It won't be there anymore after this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is present in Focal and later.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification.
Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of the problem
- similarly, as is usual with updates that restart services, it's possible than an incorrect configuration for auditd is present, but was never loaded before. The restart will load the config, and will fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be looking for that message in the logs. It won't be there anymore after this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is present in Focal and later.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
|
| 2021-01-08 21:16:25 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/audit/+git/audit/+merge/396028 |
|
| 2021-01-11 15:04:31 |
Andreas Hasenack |
description |
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification.
Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of the problem
- similarly, as is usual with updates that restart services, it's possible than an incorrect configuration for auditd is present, but was never loaded before. The restart will load the config, and will fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be looking for that message in the logs. It won't be there anymore after this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is present in Focal and later.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification.
Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of the problem
- similarly, as is usual with updates that restart services, it's possible than an incorrect configuration for auditd is present, but was never loaded before. The restart will load the config, and will fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be looking for that message in the logs. It won't be there anymore after this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is present in Focal and later.
The real fix for this bug is just dropping the audit_msg() call in the signal handler code. But the original reporter of the bug, who is also who came up with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) stated that with the 3 changes in the patch the startup hang didn't happen to him anymore. Since this bug is difficult to reproduce elsewhere (either you have it, or you don't), I chose to keep the 3 changes instead of just the removal of the audit_msg() call.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most installations work successfully, though. Re-running the install also fixes the issue, but the failure breaks our automation. The log from the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: /sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 9703 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process exited, code=killed status=9
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 'timeout'.
Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing Service.
dpkg: error processing package auditd (--configure):
installed auditd package post-installation script subprocess returned error exit status 1 |
|
| 2021-01-11 15:53:44 |
Scott Herren |
removed subscriber Scott Herren |
|
|
|
| 2021-01-11 19:00:17 |
Andreas Hasenack |
audit (Ubuntu): status |
Confirmed |
In Progress |
|
| 2021-01-13 17:31:46 |
Robie Basak |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-01-13 17:31:46 |
Robie Basak |
bug task added |
|
audit (Ubuntu Bionic) |
|
| 2021-01-13 17:31:52 |
Robie Basak |
audit (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-01-13 17:32:28 |
Robie Basak |
audit (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2021-01-13 17:32:30 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-01-13 17:32:32 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-01-13 17:32:36 |
Robie Basak |
tags |
|
verification-needed verification-needed-bionic |
|
| 2021-01-15 17:53:49 |
Pedro Principeza |
bug |
|
|
added subscriber Pedro Principeza |
| 2021-01-18 17:57:23 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic |
verification-done-bionic verification-needed |
|
| 2021-01-22 12:08:17 |
Robie Basak |
tags |
verification-done-bionic verification-needed |
verification-needed verification-needed-bionic |
|
| 2021-01-25 12:45:48 |
Andreas Hasenack |
attachment added |
|
audit-sru-1848330.tar.xz https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+attachment/5456640/+files/audit-sru-1848330.tar.xz |
|
| 2021-01-25 12:46:04 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic |
verification-done-bionic verification-needed |
|
| 2021-01-25 13:53:38 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-01-25 14:03:41 |
Launchpad Janitor |
audit (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
