| Summary: |
missing EPOLL_DEL causes logstorm when changing system time very early |
| Product: |
systemd
|
Reporter: |
Enrico Scholz <bugs-freedesktop> |
| Component: |
general | Assignee: |
systemd-bugs |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
systemd-bugs |
| Severity: |
major
|
|
|
| Priority: |
medium
|
|
|
| Version: |
unspecified | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
| Attachments: |
quick patch to fix time change related logstorm
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 75789 [details] quick patch to fix time change related logstorm When system time is changed very early there can be created thousands/millions of messages like | Mar 02 17:20:47 gkar systemd[1]: systemd-tmpfiles-clean.timer: time change, recalculating next elapse. | Mar 02 17:20:47 gkar systemd[1]: Time has been changed | ... | Mar 02 17:20:49 gkar systemd-journal[1058]: Missed 91079 kernel messages | Mar 02 17:20:49 gkar systemd[1]: systemd-tmpfiles-clean.timer: time change, recalculating next elapse. This happens because the 'm->time_change_watch.fd' is closed in the hope that it gets removed from the epoll-fd too. This removal does not happen here because forked processes (udevd?) hold an instance of the old timer fd which triggers epoll over and over again. There should happen an explicit EPOLL_DEL before close_nointr_nofail(m->time_change_watch.fd). For me, it causes problems with the time_changed_watch.fd only. But a quick look it seems that other code was written under the same wrong assumption and must be fixed too.