Skip to content

Conversation

@daipom
Copy link
Contributor

@daipom daipom commented Oct 2, 2025

We should exclude /tmp/fluentd-lock-* directory.
If /tmp/fluentd-lock-* is cleaned up while Fluentd is running:

  • out_file can fail flushing.
  • out_secondary can fail flushing.
  • The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

q /tmp 1777 root root 10d

This can delete directories under /tmp if they are not used for more than 10 days.

We don't need to protect the old lock files under
/tmp/fluentd-lock-*/, so use X instead of x.

In configs where lock files are not used, there is no problem even if this directory is deleted.
In configurations that do use lock files, it’s unlikely that this directory would not be updated for more than 10 days. Therefore, the cases where this actually becomes an issue should be quite limited.
If only out_secondary_file uses lock files, this can become an issue.

@daipom daipom added the backport to v5.0 Need to be backported LTS label Oct 2, 2025
We should exclude `/tmp/fluentd-lock-*` directory.
If `/tmp/fluentd-lock-*` is cleaned up while Fluentd is running:

* out_file can fail flushing.
* out_secondary can fail flushing.
* The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

    q /tmp 1777 root root 10d

This can delete directories under `/tmp` if they are not used
for more than 10 days.

We don't need to protect the old lock files under
`/tmp/fluentd-lock-*/`, so use `X` instead of `x`.

In configs where lock files are not used, there is no problem
even if this directory is deleted.
In configurations that do use lock files, it’s unlikely that
this directory would not be updated for more than 10 days.
Therefore, the cases where this actually becomes an issue should
be quite limited.
If only out_secondary_file uses lock files, this can become an
issue.

Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
@daipom daipom force-pushed the ensure-the-tmp-dir-for-lockfiles-is-not-cleaned-up-by-tmpfiles.d branch from d4fbe06 to c9cb698 Compare October 2, 2025 05:43
@daipom daipom added the backport to v6.0 Need to be backported LTS label Oct 2, 2025
@daipom daipom added this to the v6.1.0 milestone Oct 2, 2025
@daipom daipom marked this pull request as ready for review October 2, 2025 07:30
@daipom
Copy link
Contributor Author

daipom commented Oct 2, 2025

Tests for tmpfiles have passed.
It seems the failing tests are not related to this fix.

@daipom daipom requested a review from Watson1978 October 2, 2025 07:32
Copy link
Contributor

@Watson1978 Watson1978 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

@Watson1978 Watson1978 merged commit dd39211 into fluent:master Oct 3, 2025
431 of 478 checks passed
Watson1978 pushed a commit that referenced this pull request Oct 3, 2025
We should exclude `/tmp/fluentd-lock-*` directory.
If `/tmp/fluentd-lock-*` is cleaned up while Fluentd is running:

* out_file can fail flushing.
* out_secondary can fail flushing.
* The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

    q /tmp 1777 root root 10d

This can delete directories under `/tmp` if they are not used for more
than 10 days.

We don't need to protect the old lock files under
`/tmp/fluentd-lock-*/`, so use `X` instead of `x`.

In configs where lock files are not used, there is no problem even if
this directory is deleted.
In configurations that do use lock files, it’s unlikely that this
directory would not be updated for more than 10 days. Therefore, the
cases where this actually becomes an issue should be quite limited.
If only out_secondary_file uses lock files, this can become an issue.

Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
Signed-off-by: Shizuo Fujita <fujita@clear-code.com>
Watson1978 pushed a commit that referenced this pull request Oct 3, 2025
We should exclude `/tmp/fluentd-lock-*` directory.
If `/tmp/fluentd-lock-*` is cleaned up while Fluentd is running:

* out_file can fail flushing.
* out_secondary can fail flushing.
* The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

    q /tmp 1777 root root 10d

This can delete directories under `/tmp` if they are not used for more
than 10 days.

We don't need to protect the old lock files under
`/tmp/fluentd-lock-*/`, so use `X` instead of `x`.

In configs where lock files are not used, there is no problem even if
this directory is deleted.
In configurations that do use lock files, it’s unlikely that this
directory would not be updated for more than 10 days. Therefore, the
cases where this actually becomes an issue should be quite limited.
If only out_secondary_file uses lock files, this can become an issue.

Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
Signed-off-by: Shizuo Fujita <fujita@clear-code.com>
daipom added a commit that referenced this pull request Oct 3, 2025
…d up (#921) (#925)

Backport #921

We should exclude `/tmp/fluentd-lock-*` directory. If
`/tmp/fluentd-lock-*` is cleaned up while Fluentd is running:

* out_file can fail flushing.
* out_secondary can fail flushing.
* The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

    q /tmp 1777 root root 10d

This can delete directories under `/tmp` if they are not used for more
than 10 days.

We don't need to protect the old lock files under
`/tmp/fluentd-lock-*/`, so use `X` instead of `x`.

In configs where lock files are not used, there is no problem even if
this directory is deleted.
In configurations that do use lock files, it’s unlikely that this
directory would not be updated for more than 10 days. Therefore, the
cases where this actually becomes an issue should be quite limited. If
only out_secondary_file uses lock files, this can become an issue.

Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
Signed-off-by: Shizuo Fujita <fujita@clear-code.com>
Co-authored-by: Daijiro Fukuda <fukuda@clear-code.com>
@Watson1978 Watson1978 added the backported Already backported to LTS branch (e.g. fluent-package-v5) label Oct 3, 2025
daipom added a commit that referenced this pull request Oct 3, 2025
…d up (#921) (#924)

Backport #921

We should exclude `/tmp/fluentd-lock-*` directory. If
`/tmp/fluentd-lock-*` is cleaned up while Fluentd is running:

* out_file can fail flushing.
* out_secondary can fail flushing.
* The supervisor process exit abnormally when Fluentd stops.

At least, RHEL 8 has the following default conf for tmpfiles.d:

/usr/lib/tmpfiles.d/tmp.conf

    q /tmp 1777 root root 10d

This can delete directories under `/tmp` if they are not used for more
than 10 days.

We don't need to protect the old lock files under
`/tmp/fluentd-lock-*/`, so use `X` instead of `x`.

In configs where lock files are not used, there is no problem even if
this directory is deleted.
In configurations that do use lock files, it’s unlikely that this
directory would not be updated for more than 10 days. Therefore, the
cases where this actually becomes an issue should be quite limited. If
only out_secondary_file uses lock files, this can become an issue.

---------

Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
Signed-off-by: Shizuo Fujita <fujita@clear-code.com>
Co-authored-by: Daijiro Fukuda <fukuda@clear-code.com>
@daipom daipom deleted the ensure-the-tmp-dir-for-lockfiles-is-not-cleaned-up-by-tmpfiles.d branch November 4, 2025 03:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport to v5.0 Need to be backported LTS backport to v6.0 Need to be backported LTS backported Already backported to LTS branch (e.g. fluent-package-v5)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants