Bug 1165780 - Reduce the number of PID1 reloading triggered by btrfsmaintenance
Reduce the number of PID1 reloading triggered by btrfsmaintenance
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P2 - High : Normal with 1 vote (vote)
: ---
Assigned To: David Sterba
E-mail List
https://github.com/kdave/btrfsmainten...
:
Depends on:
Blocks: 1178874
  Show dependency treegraph
 
Reported: 2020-03-05 09:20 UTC by Franck Bui
Modified: 2022-06-10 23:26 UTC (History)
13 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
fbui: needinfo? (rgoldwyn)
santiago.zarate: needinfo? (sweiberg)
rtsvetkov: needinfo? (dsterba)


Attachments
before (3.25 MB, text/x-vhdl)
2020-04-17 09:55 UTC, Karl Mistelberger
Details
after (3.47 MB, text/x-vhdl)
2020-04-17 09:56 UTC, Karl Mistelberger
Details
erroneous activation of btrfsmaintenance-refresh (231.90 KB, text/x-vhdl)
2020-04-20 09:39 UTC, Karl Mistelberger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Franck Bui 2020-03-05 09:20:43 UTC
Apparently when btrfsmaintenance package is installed, the number of PID1 reloading increases from 0 to 4.

Reloading PID1 is a quite expensive operation therefore it would be nice if this number could be reduced at its minimum and thus helping improving the boot process.

Please note that enabling or disabling a unit implies a reload of PID1. If a batch of units needs to be enabled/disabled, it would be better to reload PID1 only at the end of the whole operation (see systemctl "--no-reload" option).

For the context: this has been noticed in bnc#1137373, where the batch of PID1 reloading triggered by btrfsmaintenance makes a systemd race easier to happen.
Comment 1 Franck Bui 2020-03-05 09:22:12 UTC
David, I'm assigning this bug to you as you're btrfsmaintenance maintainer. Please re-assign it accordingly if that was a wrong guess.

Thanks.
Comment 2 Fabian Vogt 2020-03-05 09:29:22 UTC
Alternative would be to move away from sysconfig for configuration and just keeping the systemd timer units, which can be configured using systemd directly.

Or using a generator for creating the timer (override) units based on sysconfig.
Comment 3 Karl Mistelberger 2020-03-16 06:22:42 UTC
btrfsmaintenance.path may start before /etc/sysconfig/btrfsmaintenance is available. Use After=local-fs.target for proper operation.
Comment 4 Karl Mistelberger 2020-03-16 06:30:01 UTC
Ment btrfsmaintenance-refresh.path: https://github.com/kdave/btrfsmaintenance/issues/78
Comment 5 Franck Bui 2020-04-16 08:40:23 UTC
In the hope to reach a broader audience and hence some people who are willing to improve this stuff, let's try to re-assign this bug to the kernel team.
Comment 6 Karl Mistelberger 2020-04-16 08:45:17 UTC
See also: https://en.opensuse.org/SDB:Fix_btrfsmaintenance-refresh
Comment 7 Michal Suchanek 2020-04-16 10:50:26 UTC
If you have a fix submit it to the package.

Also a summary of the issue would be helpful.
Comment 8 Karl Mistelberger 2020-04-16 11:05:14 UTC
Created a pull request: https://github.com/kdave/btrfsmaintenance/pull/79

But I am lost with: https://build.opensuse.org/package/show/filesystems/btrfsmaintenance?rev=48
Comment 9 Franck Bui 2020-04-16 12:49:34 UTC
(In reply to Karl Mistelberger from comment #8)
> Created a pull request: https://github.com/kdave/btrfsmaintenance/pull/79

Are you sure that this PR is addressing the current issue ?

AFAICS it doesn't reduce the number of PID1 reloading, does it ?
Comment 10 Fabian Vogt 2020-04-16 12:58:05 UTC
(In reply to Franck Bui from comment #9)
> (In reply to Karl Mistelberger from comment #8)
> > Created a pull request: https://github.com/kdave/btrfsmaintenance/pull/79
> 
> Are you sure that this PR is addressing the current issue ?
> 
> AFAICS it doesn't reduce the number of PID1 reloading, does it ?

AFAICT it moves the PID reloading to happen only after local-fs.target, which mitigates bug 1137373. It's mostly for symmetry to btrfsmaintenance-refresh.service, which already has After=local-fs.service.

It still reloads systemd at least three times during boot and when sysconfig changes.
Comment 11 Karl Mistelberger 2020-04-16 13:01:19 UTC
I checked on a machine running Tumbleweed. Before applying the patch,  btrfsmaintenance-refresh.path triggered btrfsmaintenance-refresh.service while  /etc/fstab processing was underway. Journalctl listed 4 reloads of systemd.

After applying the patch btrfsmaintenance-refresh.service wasn't triggered anymore. No reloads of systemd occured.

Additionally default state of units should be checked:

erlangen:~ # systemctl list-unit-files btrfsmaintenance-refresh.*
UNIT FILE                        STATE   
btrfsmaintenance-refresh.path    enabled 
btrfsmaintenance-refresh.service disabled

2 unit files listed.
erlangen:~ #
Comment 12 Franck Bui 2020-04-16 13:27:45 UTC
Hmm actually considering the fact that path units have After=sysinit.target as part of their default dependencies, I'm wondering how your change would help since local-fs.target has Before=sysinit.target.

That said even if your change helps, I think it is still interesting to minimize the number of PID1 reloading when the unit path fires up the service unit. That's what this bug is mainly about.
Comment 13 Franck Bui 2020-04-16 13:42:49 UTC
(In reply to Fabian Vogt from comment #10)
> AFAICT it moves the PID reloading to happen only after local-fs.target,
> which mitigates bug 1137373. It's mostly for symmetry to
> btrfsmaintenance-refresh.service, which already has After=local-fs.service.

Since both units (.path and .service) have the default dependencies both units don't need "After=local-fs.service" as it's already implied.

> It still reloads systemd at least three times during boot and when sysconfig
> changes.

This is what should be optimized IMHO.

That said the idea of automatically (re)starting a unit if a config file was changed is disputable, assuming it's the purpose of btrfsmaintenance-refresh.path. IMHO reloading a new config should be done explicitly like it's always been the case, and who knows the state of the contents of the config file when sysadmin is saving it.
Comment 14 Fabian Vogt 2020-04-16 13:58:38 UTC
(In reply to Franck Bui from comment #13)
> (In reply to Fabian Vogt from comment #10)
> That said the idea of automatically (re)starting a unit if a config file was
> changed is disputable, assuming it's the purpose of
> btrfsmaintenance-refresh.path.

The purpose of that unit is actually to read sysconfig and configure .timer units based on that by writing into /etc/systemd/system/btrfs-foo.timer.d/ and enabling/disabling them: https://github.com/kdave/btrfsmaintenance/blob/df43313e20745f14de7dcc9b1f5df1a6ace21ab7/btrfsmaintenance-refresh-cron.sh#L62

AFAICT there isn't really a reason to have this configured in sysconfig anymore and it should just be done by configuring the timers directly.
Comment 15 Karl Mistelberger 2020-04-16 15:12:17 UTC
(In reply to Franck Bui from comment #12)
> Hmm actually considering the fact that path units have After=sysinit.target
> as part of their default dependencies, I'm wondering how your change would
> help since local-fs.target has Before=sysinit.target.

Whether this claim holds or not there are the points I verified. Experiment contradicts theory.
Comment 16 Karl Mistelberger 2020-04-17 04:31:52 UTC
(In reply to Franck Bui from comment #13)
> (In reply to Fabian Vogt from comment #10)
> > AFAICT it moves the PID reloading to happen only after local-fs.target,
> > which mitigates bug 1137373. It's mostly for symmetry to
> > btrfsmaintenance-refresh.service, which already has After=local-fs.service.
> 
> Since both units (.path and .service) have the default dependencies both
> units don't need "After=local-fs.service" as it's already implied.

Yet another claim which is not supported by evidence. I reiterate: removing After=local-fs.target from unit btrfsmaintenance-refresh.path results in btrfsmaintenance-refresh.service being triggered before local-fs.target is reached. This has been verified on one of my machines and has been confirmed independently by several users at https://forums.opensuse.org/forum.php, e.g.:

https://forums.opensuse.org/showthread.php/539836-snapper-not-working?p=2932503#post2932503

https://forums.opensuse.org/showthread.php/539806-files-disappear-reappear-in-my-opt-folder-happening-on-2-machines-now?p=2932422#post2932422

https://forums.opensuse.org/showthread.php/539503-boot-efi-is-not-mounted?p=2930500#post2930500

> 
> > It still reloads systemd at least three times during boot and when sysconfig
> > changes.
> 
> This is what should be optimized IMHO.

https://github.com/kdave/btrfsmaintenance/pull/79 indeed fixes systemd reload during boot, but does not address factual changes of /etc/sysconfig/btrfsmaintenance.
Comment 17 Franck Bui 2020-04-17 08:31:36 UTC
(In reply to Karl Mistelberger from comment #16)
> Yet another claim which is not supported by evidence. I reiterate: removing
> After=local-fs.target from unit btrfsmaintenance-refresh.path results in
> btrfsmaintenance-refresh.serviceb being triggered before local-fs.target is
> reached. This has been verified on one of my machines and has been confirmed
> independently by several users at https://forums.opensuse.org/forum.php,

I didn't say that your workaround has no effect, I was just pointing out that it doesn't look correct.

So before considering merging your patch, it would be interesting to understand why btrfsmaintenance-refresh.service is triggered before local-fs.target.

Please attach the debug logs (output of journalctl -b -o short-monotonic) after making sure to revert your changes. To enable the debug logs please append the following options to the kernel command line "printk.devkmsg=on systemd.log_level=debug"
Comment 18 Franck Bui 2020-04-17 08:35:50 UTC
Also what's the point of enabling the service unit if the path unit is suposed to automatically trigger it ?
Comment 19 Karl Mistelberger 2020-04-17 09:55:55 UTC
Created attachment 836007 [details]
before
Comment 20 Karl Mistelberger 2020-04-17 09:56:36 UTC
Created attachment 836008 [details]
after
Comment 21 Karl Mistelberger 2020-04-17 10:08:30 UTC
(In reply to Franck Bui from comment #17)
> (In reply to Karl Mistelberger from comment #16)
> > Yet another claim which is not supported by evidence. I reiterate: removing
> > After=local-fs.target from unit btrfsmaintenance-refresh.path results in
> > btrfsmaintenance-refresh.service being triggered before local-fs.target is
> > reached. This has been verified on one of my machines and has been confirmed
> > independently by several users at https://forums.opensuse.org/forum.php,
> 
> I didn't say that your workaround has no effect, I was just pointing out
> that it doesn't look correct.

systemd was updated since I made the changes to btrfsmaintenance-refresh.path. Current  systemd-244-3.1 no longer reloads during boot.

Changes are now for btrfsmaintenance moved from sysconfig to default: 

erlangen:~ # systemd-delta -t overridden 
[OVERRIDDEN] /etc/systemd/system/btrfsmaintenance-refresh.path → /usr/lib/systemd/system/btrfsmaintenance-refresh.path

--- /usr/lib/systemd/system/btrfsmaintenance-refresh.path       2019-06-24 21:56:02.000000000 +0200
+++ /etc/systemd/system/btrfsmaintenance-refresh.path   2020-04-17 04:07:23.157871476 +0200
@@ -1,8 +1,9 @@
 [Unit]
-Description=Watch /etc/sysconfig/btrfsmaintenance
+Description=Watch /etc/default/btrfsmaintenance
+After=local-fs.target
 
 [Path]
-PathChanged=/etc/sysconfig/btrfsmaintenance
+PathChanged=/etc/default/btrfsmaintenance
 
 [Install]
 WantedBy=multi-user.target


With the above btrfsmaintenance-refresh.service runs only when /etc/default/btrfsmaintenance actually changes.
Comment 22 Karl Mistelberger 2020-04-17 12:31:40 UTC
(In reply to Franck Bui from comment #18)
> Also what's the point of enabling the service unit if the path unit is
> supposed to automatically trigger it ?

Settings are:

erlangen:~ # systemctl list-unit-files btrfsmaintenance-refresh.*
UNIT FILE                        STATE   
btrfsmaintenance-refresh.path    enabled 
btrfsmaintenance-refresh.service disabled

2 unit files listed.
erlangen:~ # 

btrfsmaintenance-refresh.path watches for changes of /etc/default/btrfsmaintenance and fires btrfsmaintenance-refresh.service if one is detected. IIRC defaults don't work.
Comment 23 Franck Bui 2020-04-20 08:56:59 UTC
(In reply to Karl Mistelberger from comment #19)
> Created attachment 836007 [details]
> before

btrfsmaintenance-refresh.service is not started before local-fs.target here, in fact it's not started at all...
Comment 24 Karl Mistelberger 2020-04-20 09:39:39 UTC
Created attachment 836104 [details]
erroneous activation of btrfsmaintenance-refresh

The attachment shows journal of rescue system (without debug enabled) with erroneous activation of btrfsmaintenance-refresh.service
Comment 25 Franck Bui 2020-04-20 09:56:41 UTC
Well, you're supposed to show us an example of a boot sequence where btrfsmaintenance service starts before local-fs.target.

So far none of the logs you provided did.
Comment 26 Karl Mistelberger 2020-04-20 11:19:46 UTC
With a fresh install of Tumbleweed 20200416 the problem no longer persists. Units
btrfsmaintenance-refresh.path and btrfsmaintenance-refresh.service indeed wait until local-fs.target is reached.

However due to btrfsmaintenance-refresh.service being enabled the unit runs during boot without /etc/sysconfig/btrfsmaintenance being changed:

Apr 20 12:59:51 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance.
Apr 20 12:59:51 systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance...
Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-scrub.sh for uninstall
Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-defrag.sh for uninstall
Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-balance.sh for uninstall
Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh script btrfs-trim.sh for uninstall
Apr 20 12:59:51 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-scrub for monthly
Apr 20 12:59:52 systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 20 12:59:52 systemd[1]: Started Defragment file data and/or directory metadata.
Apr 20 12:59:52 systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Apr 20 12:59:52 systemd[1]: Started Discard unused blocks on a mounted filesystem.
Apr 20 12:59:52 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-defrag for none
Apr 20 12:59:52 systemd[1]: btrfs-defrag.timer: Succeeded.
Apr 20 12:59:52 systemd[1]: Stopped Defragment file data and/or directory metadata.
Apr 20 12:59:53 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-balance for weekly
Apr 20 12:59:53 btrfsmaintenance-refresh-cron.sh[1089]: Refresh timer btrfs-trim for none
Apr 20 12:59:53 systemd[1]: btrfs-trim.timer: Succeeded.
Apr 20 12:59:53 systemd[1]: Stopped Discard unused blocks on a mounted filesystem.
Apr 20 12:59:53 systemd[1]: btrfsmaintenance-refresh.service: Succeeded.
Apr 20 12:59:53 systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.

Disabling btrfsmaintenance-refresh.service and enabling btrfsmaintenance-refresh.path fixes this:

Apr 20 13:08:44 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance.
Apr 20 13:08:45 systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 20 13:08:45 systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Apr 20 13:09:35 systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance...
Comment 27 Franck Bui 2020-04-20 12:02:49 UTC
(In reply to Karl Mistelberger from comment #26)
> With a fresh install of Tumbleweed 20200416 the problem no longer persists.
> Units
> btrfsmaintenance-refresh.path and btrfsmaintenance-refresh.service indeed
> wait until local-fs.target is reached.

That should have always been the case otherwise that would be a bug.

> 
> However due to btrfsmaintenance-refresh.service being enabled the unit runs
> during boot without /etc/sysconfig/btrfsmaintenance being changed:
> 
> [...]
> 
> Disabling btrfsmaintenance-refresh.service and enabling
> btrfsmaintenance-refresh.path fixes this:
> 

Which is the reason why I asked the point of enabling btrfsmaintenance service in comment #18.

Actually this service doesn't seem to need a [Install] section at all.
Comment 28 Karl Mistelberger 2020-04-20 12:08:35 UTC
(In reply to Franck Bui from comment #27)
> (In reply to Karl Mistelberger from comment #26)
> > With a fresh install of Tumbleweed 20200416 the problem no longer persists.
> > Units
> > btrfsmaintenance-refresh.path and btrfsmaintenance-refresh.service indeed
> > wait until local-fs.target is reached.
> 
> That should have always been the case otherwise that would be a bug.
> 

I ask users affected to report: https://forums.opensuse.org/showthread.php/539905-How-to-fix-btrfsmaintenance?p=2933726#post2933726


> > However due to btrfsmaintenance-refresh.service being enabled the unit runs
> > during boot without /etc/sysconfig/btrfsmaintenance being changed:
> > 
> > [...]
> > 
> > Disabling btrfsmaintenance-refresh.service and enabling
> > btrfsmaintenance-refresh.path fixes this:
> > 
> 
> Which is the reason why I asked the point of enabling btrfsmaintenance
> service in comment #18.
> 
> Actually this service doesn't seem to need a [Install] section at all.

I agree. However you may want to load it at boot:

erlangen:~ # systemctl cat btrfsmaintenance-refresh.service 
# /etc/systemd/system/btrfsmaintenance-refresh.service
[Unit]
Description=Update cron periods from /etc/sysconfig/btrfsmaintenance

[Service]
ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh systemd-timer
Type=oneshot

[Install]
WantedBy=multi-user.target
erlangen:~ #
Comment 29 Karl Mistelberger 2020-04-21 08:23:24 UTC
When duping to 20200417 I tested the following minimal units:

# /etc/systemd/system/btrfsmaintenance-refresh.path
[Unit]
Description=Watch /etc/sysconfig/btrfsmaintenance

[Path]
PathChanged=/etc/sysconfig/btrfsmaintenance

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/btrfsmaintenance-refresh.service
[Unit]
Description=Update cron periods from /etc/sysconfig/btrfsmaintenance

[Service]
ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh systemd-timer
Type=oneshot

UNIT FILE                        STATE   VENDOR PRESET
btrfsmaintenance-refresh.path    enabled disabled     
btrfsmaintenance-refresh.service static  enabled      

Apr 21 10:16:25 systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance.
Apr 21 10:16:40 systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 21 10:16:40 systemd[1]: Started Defragment file data and/or directory metadata.
Apr 21 10:16:40 systemd[1]: Started Scrub btrfs filesystem, verify block checksums.

Seems to work as intended.
Comment 30 Franck Bui 2020-04-21 09:07:42 UTC
(In reply to Karl Mistelberger from comment #29)
> 
> UNIT FILE                        STATE   VENDOR PRESET
> btrfsmaintenance-refresh.path    enabled disabled     
> btrfsmaintenance-refresh.service static  enabled      

That should be the other way around: .service should be disabled whereas .path should be enabled...

Anyway could you send a patch to remove [Install] section from .service ?

I think this change makes sense enough alone to be submitted.
Comment 31 Franck Bui 2020-04-21 09:22:35 UTC
(In reply to Franck Bui from comment #30)
> (In reply to Karl Mistelberger from comment #29)
> > 
> > UNIT FILE                        STATE   VENDOR PRESET
> > btrfsmaintenance-refresh.path    enabled disabled     
> > btrfsmaintenance-refresh.service static  enabled      
> 
> That should be the other way around: .service should be disabled whereas
> .path should be enabled...

Ah forget about this part of the comment, I misread the output of the units status, it's the preset stuff which still looks wrong but that's another issue.
Comment 32 Karl Mistelberger 2020-04-21 09:57:36 UTC
(In reply to Franck Bui from comment #30)
> Anyway could you send a patch to remove [Install] section from .service ?
> I think this change makes sense enough alone to be submitted.

I never submitted a patch. Do you refer to that:

https://openbuildservice.org/help/manuals/obs-user-guide/art.obs.bg.html#sec.obsbg.uc.patching
Comment 33 Franck Bui 2020-04-21 10:15:43 UTC
(In reply to Karl Mistelberger from comment #32)
> (In reply to Franck Bui from comment #30)
> > Anyway could you send a patch to remove [Install] section from .service ?
> > I think this change makes sense enough alone to be submitted.
> 
> I never submitted a patch. Do you refer to that:

No I was suggesting you to send a new patch that removes [Install] section from .service.
Comment 34 Franck Bui 2020-04-21 10:18:10 UTC
(In reply to Franck Bui from comment #31)
> Ah forget about this part of the comment, I misread the output of the units
> status, it's the preset stuff which still looks wrong but that's another
> issue.

Marcus, the preset stuff enables btrfsmaintenance-refresh.service by default. But that looks wrong, it should be the path unit, btrfsmaintenance-refresh.path, which should be enabled by default.

Can you please fix it ?
Comment 35 Karl Mistelberger 2020-04-21 10:54:12 UTC
(In reply to Franck Bui from comment #33)
> (In reply to Karl Mistelberger from comment #32)
> > (In reply to Franck Bui from comment #30)
> > > Anyway could you send a patch to remove [Install] section from .service ?
> > > I think this change makes sense enough alone to be submitted.
> > 
> > I never submitted a patch. Do you refer to that:
> 
> No I was suggesting you to send a new patch that removes [Install] section
> from .service.

https://github.com/karlmistelberger/btrfsmaintenance/pull/1
Comment 36 Karl Mistelberger 2020-04-21 11:08:34 UTC
(In reply to Franck Bui from comment #33)
> (In reply to Karl Mistelberger from comment #32)
> No I was suggesting you to send a new patch that removes [Install] section
> from .service.

https://github.com/kdave/btrfsmaintenance/pull/81
Comment 37 Franck Bui 2020-04-27 08:53:58 UTC
@Michal Suchanek, can you please deal with the PR ?
Comment 38 Michal Suchanek 2020-04-27 09:54:08 UTC
David, please merge the PR and submit to OBS.
Comment 39 David Sterba 2020-07-30 13:41:42 UTC
I've released 0.5 upstream, updated the devel project and submitted that to Factory.
Comment 41 Franck Bui 2020-08-24 13:23:25 UTC
The change doesn't seem to be available in TW, anything wrong happened ?
Comment 42 Fabian Vogt 2020-08-24 14:21:27 UTC
(In reply to Franck Bui from comment #41)
> The change doesn't seem to be available in TW, anything wrong happened ?

The sr got declined: https://build.opensuse.org/request/show/823587

For reference, this is my comment which lead to the decline:

> Deleting the [Install] section is a noop, it will only break later calls to "systemctl enable btrfsmaintenance-refresh.service". Existing systems will not be impacted by that. In fact, the removal of After=local-fs.target might even break it.
>
> Is that intentional?
>
> I recommend updating systemd-presets-common-SUSE instead to not explicitly enable btrfsmaintenance-refresh.service.

To double check, I just updated btrfsmaintenance to the 0.5 version from the devel prj in a VM and btrfsmaintenance-refresh.service still runs on boot as the .service file is still linked to /etc/systemd/system/multi-user.target.wants/.
Comment 43 Franck Bui 2020-08-24 15:58:12 UTC
IIRC this service is only useful when some BTRFS settings are changed somewhere in /etc/sysconfig. That's the reason why a path unit is used to monitor the relevant config file.

If so it seems there's no point in giving to the user the possibility to enable/disable the service unit and start the service on each boot even if nothing changed in the relevant config file, which is very likely.

At least I assumed that was correct since the maintainer accepted this change.

Regarding the use of After=local-fs.target, I think its usefulness was discussed in the previous comments.
Comment 44 Karl Mistelberger 2020-08-24 19:38:52 UTC
(In reply to Fabian Vogt from comment #42)
> (In reply to Franck Bui from comment #41)
> > The change doesn't seem to be available in TW, anything wrong happened ?
> 
> The sr got declined: https://build.opensuse.org/request/show/823587
> 
> For reference, this is my comment which lead to the decline:
> 
> > Deleting the [Install] section is a noop, it will only break later calls to "systemctl enable btrfsmaintenance-refresh.service". Existing systems will not be impacted by that. In fact, the removal of After=local-fs.target might even break it.
> >
> > Is that intentional?
> >
> > I recommend updating systemd-presets-common-SUSE instead to not explicitly enable btrfsmaintenance-refresh.service.
> 
> To double check, I just updated btrfsmaintenance to the 0.5 version from the
> devel prj in a VM and btrfsmaintenance-refresh.service still runs on boot as
> the .service file is still linked to
> /etc/systemd/system/multi-user.target.wants/.

btrfsmaintenance-refresh.service was NEVER INTENDED to be enabled or installed.

btrfsmaintenance-refresh.path triggers btrfsmaintenance-refresh.service upon changes of /etc/sysconfig/btrfsmaintenance

Correct settings are:

# systemctl list-unit-files btrfsmaintenance-refresh.*
UNIT FILE                        STATE   
btrfsmaintenance-refresh.path    enabled      
btrfsmaintenance-refresh.service static

# systemctl list-units btrfsmaintenance-refresh.*
  UNIT                          LOAD   ACTIVE SUB     DESCRIPTION                          
  btrfsmaintenance-refresh.path loaded active waiting Watch /etc/sysconfig/btrfsmaintenance

# systemctl cat btrfsmaintenance-refresh.service
# /etc/systemd/system/btrfsmaintenance-refresh.service
[Unit]
Description=Update cron periods from /etc/sysconfig/btrfsmaintenance

[Service]
ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh systemd-timer
Type=oneshot
Comment 45 Fabian Vogt 2020-08-25 14:23:41 UTC
(In reply to Karl Mistelberger from comment #44)
> (In reply to Fabian Vogt from comment #42)
> > (In reply to Franck Bui from comment #41)
> > > The change doesn't seem to be available in TW, anything wrong happened ?
> > 
> > The sr got declined: https://build.opensuse.org/request/show/823587
> > 
> > For reference, this is my comment which lead to the decline:
> > 
> > > Deleting the [Install] section is a noop, it will only break later calls to "systemctl enable btrfsmaintenance-refresh.service". Existing systems will not be impacted by that. In fact, the removal of After=local-fs.target might even break it.
> > >
> > > Is that intentional?
> > >
> > > I recommend updating systemd-presets-common-SUSE instead to not explicitly enable btrfsmaintenance-refresh.service.
> > 
> > To double check, I just updated btrfsmaintenance to the 0.5 version from the
> > devel prj in a VM and btrfsmaintenance-refresh.service still runs on boot as
> > the .service file is still linked to
> > /etc/systemd/system/multi-user.target.wants/.
> 
> btrfsmaintenance-refresh.service was NEVER INTENDED to be enabled or
> installed.
> 
> btrfsmaintenance-refresh.path triggers btrfsmaintenance-refresh.service upon
> changes of /etc/sysconfig/btrfsmaintenance

Yes, that is so far correct. The issue is, it IS enabled as that's what previous
versions did and so on existing systems it STAYS enabled because removing the
[Install] section does not run a call to systemctl disable.

As long as the service is still enabled in the preset, it will stay enabled.
It might be enough to remove it from https://build.opensuse.org/package/view_file/Base:System/systemd-presets-common-SUSE/default-SUSE.preset?expand=1&rev=29 (line 12), but I'd add a systemctl disable call in %post to be sure, in case someone enabled it manually.
Comment 46 Franck Bui 2020-08-25 20:46:00 UTC
(In reply to Fabian Vogt from comment #45)
> As long as the service is still enabled in the preset, it will stay enabled.
> It might be enough to remove it from
> https://build.opensuse.org/package/view_file/Base:System/systemd-presets-
> common-SUSE/default-SUSE.preset?expand=1&rev=29 (line 12),

See comment #34, that should be the path unit that should be enabled instead.

> but I'd add a
> systemctl disable call in %post to be sure, in case someone enabled it
> manually.

Indeed but playing with stuff in /etc during package update is usually not a good idea so I would be tempted to leave it unless the user is hit by the systemd race issue and in this case we can ask him to remove the symlink manually.
Comment 47 Karl Mistelberger 2020-08-26 05:54:49 UTC
> Indeed but playing with stuff in /etc during package update is usually not a
> good idea so I would be tempted to leave it unless the user is hit by the
> systemd race issue and in this case we can ask him to remove the symlink
> manually.

I fully agree on the above. However this is not a usual case. IIRC keeping the symlink and removing the install section will result in a runtime error for everybody updating.

As you never want to install the service for a good reason removing the symlink upon update would be fine.
Comment 48 Fabian Vogt 2020-08-26 09:21:14 UTC
The declined btrfsmaintenance 0.5 sr would not even work correctly on a fresh installation. The preset would enable the .service, but without an [Install] section nothing happens. The .path unit was only ever installed because of the Also=btrfsmaintenance-refresh.path in the [Install] section, which got dropped. Effectively it would've made no difference to existing installs and completely disable the refreshing on fresh installation.

I made the change to the preset and submitted it: sr 829721

Clean state: btrfsmaintenance-refresh.service + .path both enabled.
With just new btrfsmaintenance: no change, both .service and .path still enabled
With just new systemd-presets-common-SUSE: Works as expected, installation prints:
Resetting btrfsmaintenance-refresh.path to the new default: enable
Resetting btrfsmaintenance-refresh.service to the new default: disable
Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service.
First new systemd-presets-common-SUSE, then new btrfsmaintenance: Same as ^
First new btrfsmaintenance, then new systemd-presets-common-SUSE: Same as ^

Even if manually enabled, the new systemd-presets-common-SUSE disables the .service properly.

Downgrading of systemd-presets-common-SUSE also works, it prints:
Resetting btrfsmaintenance-refresh.path to the new default: disable
Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path.
Resetting btrfsmaintenance-refresh.service to the new default: enable
Created symlink /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service -> /usr/lib/systemd/system/btrfsmaintenance-refresh.service.
Created symlink /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path -> /usr/lib/systemd/system/btrfsmaintenance-refresh.path.

Downgrading systemd-presets-common-SUSE with btrfsmaintenance 0.5 results in the
broken "fresh install" case, which is expected.

So just systemd-presets-common-SUSE is enough to get the wanted behaviour and
the removal of [Install] in btrfsmaintenance-refresh.service is mostly a cleanup
and to avoid manual enabling in the future. Care has to be taken that this version
of btrfsmaintenance is not used together with old systemd-presets-common-SUSE, as
it results in a disabled .path unit.
Comment 49 Karl Mistelberger 2020-08-26 17:15:19 UTC
(In reply to Fabian Vogt from comment #48)
> I made the change to the preset and submitted it: sr 829721

Great! I am happy with what I asked for in comments #11, #22 and #29.

> the removal of [Install] in btrfsmaintenance-refresh.service is mostly a cleanup
and to avoid manual enabling in the future.

For me as a less experienced user the bogus preset and [Install] were extremely misleading and distracting. Making sure that btrfsmaintenance-refresh.service will never be enabled helps a lot.
Comment 50 Franck Bui 2020-08-26 19:51:06 UTC
(In reply to Karl Mistelberger from comment #47)
> I fully agree on the above. However this is not a usual case. IIRC keeping
> the symlink and removing the install section will result in a runtime error
> for everybody updating.

I don't think this is correct - there're various services which are 'statically' enabled.
Comment 51 Franck Bui 2020-08-26 19:56:11 UTC
(In reply to Fabian Vogt from comment #48)
> I made the change to the preset and submitted it: sr 829721

Thanks !

> So just systemd-presets-common-SUSE is enough to get the wanted behaviour and
> the removal of [Install] in btrfsmaintenance-refresh.service is mostly a
> cleanup and to avoid manual enabling in the future.

I wouldn't call that a clean up as it's only intended to be run via the path unit.

> Care has to be taken that this version of btrfsmaintenance is not used
> together with old systemd-presets-common-SUSE, as it results in a disabled
> .path unit.

Indeed.
Comment 52 владимир путин 2020-09-01 07:48:29 UTC
Can this btrfsmaintenance just be removed by default? It seem to cause more troubles than good. Besides, balancing of btrfs nowadays is not recommended, according to btrfs kernel wiki. And balancing with -susage=... is plain dangerous. Modern btrfs tools wont even allow to do it anymore unless you force it. And scrap won't help if you don't have redundant copy in some sort of raid.

So this package basically does a lot of troubles all around the system without any real benefit.
Comment 53 владимир путин 2020-11-01 11:35:47 UTC
I have removed the btrfsmaintenance from my system, yet after some time its back again. And doing scrub in the background, effectively locking the whole IO on the desktop. Which became unresponsive. 
I guess something installs it as a recommended dependency. Is it possible to not force this generally useless and quite harmful package on people?
Comment 55 Goldwyn Rodrigues 2020-11-12 16:24:42 UTC
How about enabling and starting the timer service only if /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue?

We will still have to check "systemctl is-enabled $SERVICE.timer" and "systemctl is-active $SERVICE.timer" and enable/start iff it returns false. Would that slow down the boot process?
Comment 56 Karl Mistelberger 2020-11-12 16:55:35 UTC
(In reply to asf from comment #53)
> I have removed the btrfsmaintenance from my system, yet after some time its
> back again. And doing scrub in the background, effectively locking the whole
> IO on the desktop. Which became unresponsive. 
> I guess something installs it as a recommended dependency. Is it possible to
> not force this generally useless and quite harmful package on people?

Turn off the timers you don't want to use:

:~ # grep PERIOD /etc/sysconfig/btrfsmaintenance
BTRFS_DEFRAG_PERIOD="weekly"
BTRFS_BALANCE_PERIOD="weekly"
BTRFS_SCRUB_PERIOD="monthly"
BTRFS_TRIM_PERIOD="none"
:~ #
Comment 57 владимир путин 2020-11-12 17:12:32 UTC
Thanks Karl. 
But what i'm trying to say, is they are all useless for general audience. So should not be forced on it. 
Im pretty sure there are many people not technical enough, to figure out why their desktop became unresponsive once a week or once a month. Coz of something, which is outdated and gives no benefits at all still intensively work in the background. Defaults should be sane and tied for general usecase.
And btw there is already fstrim timer in suse systemd enabled by default. So even the last one is useless. 

Those who maintain servers and happened to have redundant raid, can easily enable scrub themselves in just a line of cron. Just like i did.
And scrub is the only thing which could be potentially useful in some cases nowadays, out of the whole btrfsmaintenance package.

In other words: the package is long outdated Karl!
Comment 58 владимир путин 2020-11-12 17:16:26 UTC
and yeah, i forgot the instabilities in snapper work, as a bonus you may get to the btrfsmaintenance package.
Comment 59 Franck Bui 2020-11-13 09:05:33 UTC
(In reply to Goldwyn Rodrigues from comment #55)
> How about enabling and starting the timer service only if
> /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the
> $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue?

I think we already discussed about what is actually needed:

 1. btrfsmaintenance-refresh.service should not be enabled by default by the
    preset stuff but instead it should enable btrfsmaintenance-refresh.path
    On Factory this was dealt by sr#829721

 2. since btrfsmaintenance-refresh.service is not supposed to be run at boot
    the unit file should have an [Install] section. Not sure if this was
    fixed...

IIRC this was based on the fact that btrfsmaintenance-refresh.service needs to be started only when settings were changed in /etc/sysconfig/btrfsmaintenance.

But please note that this addresses new installations only.

For existing systems, the relevant symlink have to be changed manually because the presets stuff are only apply at installation time.

Ideally after an update we should have renamed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service to point to btrfsmaintenance-refresh.path instead.

AFAICS none of these changes has not been backported to *SLE*.
Comment 60 Franck Bui 2020-11-13 09:07:22 UTC
(In reply to asf from comment #57)
> Thanks Karl. 
> But what i'm trying to say, is they are all useless for general audience. So
> should not be forced on it. 

Which suggests that btrfsmaintenance.path should be enabled only for SLE and disabled for openSUSE distros...
Comment 61 Fabian Vogt 2020-11-13 09:16:49 UTC
(In reply to Franck Bui from comment #59)
> (In reply to Goldwyn Rodrigues from comment #55)
> > How about enabling and starting the timer service only if
> > /etc/systemd/system/$SERVICE.timer.d/schedule.conf does not match the
> > $PERIOD in /etc/sysconfig/btrfsmaintenance? Would that solve the issue?
> 
> I think we already discussed about what is actually needed:
> 
>  1. btrfsmaintenance-refresh.service should not be enabled by default by the
>     preset stuff but instead it should enable btrfsmaintenance-refresh.path
>     On Factory this was dealt by sr#829721
> 
>  2. since btrfsmaintenance-refresh.service is not supposed to be run at boot
>     the unit file should have an [Install] section. Not sure if this was
>     fixed...

It was part of https://build.opensuse.org/request/show/831373.

> IIRC this was based on the fact that btrfsmaintenance-refresh.service needs
> to be started only when settings were changed in
> /etc/sysconfig/btrfsmaintenance.
> 
> But please note that this addresses new installations only.
> 
> For existing systems, the relevant symlink have to be changed manually
> because the presets stuff are only apply at installation time.

Change 2 is enough and also affects existing installations properly,
see comment 48.

> Ideally after an update we should have renamed
> /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service
> to point to btrfsmaintenance-refresh.path instead.
> 
> AFAICS none of these changes has not been backported to *SLE*.

Backporting only sr#829721 should be sufficient.
Comment 62 Karl Mistelberger 2020-11-13 09:17:55 UTC
(In reply to Franck Bui from comment #59)
>  2. since btrfsmaintenance-refresh.service is not supposed to be run at boot
>     the unit file should have an [Install] section. Not sure if this was
>     fixed...

Should read "the unit file should have NO [Install] section. This is fixed in latest Tumbleweed.

> ... btrfsmaintenance.path should be enabled only for SLE and disabled for openSUSE distros...

Great. Documentation should address Btrfs maintenance toolbox properly. Currently coverage is pretty poor.
Comment 65 Franck Bui 2020-11-13 09:34:18 UTC
(In reply to Fabian Vogt from comment #61)
> Change 2 is enough and also affects existing installations properly,
> see comment 48.

You're right, I missed the fact that presets are also selectively applied at package updates.
Comment 66 Franck Bui 2020-11-13 09:34:48 UTC
(In reply to Karl Mistelberger from comment #62)
> (In reply to Franck Bui from comment #59)
> >  2. since btrfsmaintenance-refresh.service is not supposed to be run at boot
> >     the unit file should have an [Install] section. Not sure if this was
> >     fixed...
> 
> Should read "the unit file should have NO [Install] section. This is fixed
> in latest Tumbleweed.

+1, sorry for the confusion.
Comment 68 владимир путин 2020-11-13 14:18:29 UTC
(In reply to Franck Bui from comment #60)

> Which suggests that btrfsmaintenance.path should be enabled only for SLE and
> disabled for openSUSE distros...

It may still screw up snapper rollbacks there. Im not sure if thats exactly what you want for the enterprise customers.
Comment 69 Franck Bui 2020-11-16 09:57:06 UTC
(In reply to asf from comment #68)
> It may still screw up snapper rollbacks there. Im not sure if thats exactly
> what you want for the enterprise customers.

No indeed...

That said it's better to discuss this topic separately, can you please open another bug ?
Comment 71 владимир путин 2020-11-16 11:39:39 UTC
(In reply to Franck Bui from comment #69)

> That said it's better to discuss this topic separately, can you please open
> another bug ?

I'm talking about this one:
https://bugzilla.opensuse.org/show_bug.cgi?id=1174798
If you are sure that your proposed changes are going to fix it, then disregard my message.
Comment 75 Swamp Workflow Management 2021-03-23 17:19:58 UTC
SUSE-RU-2021:0926-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1083473,1112500,1115408,1165780,1183012
CVE References: 
JIRA References: 
Sources used:
SUSE MicroOS 5.0 (src):    systemd-presets-common-SUSE-15-8.3.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    systemd-presets-common-SUSE-15-8.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 76 Swamp Workflow Management 2021-03-26 20:16:40 UTC
openSUSE-RU-2021:0478-1: An update that has 5 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1083473,1112500,1115408,1165780,1183012
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.2 (src):    systemd-presets-common-SUSE-15-lp152.9.3.1
Comment 77 Oliver Kurz 2021-04-10 05:03:23 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: jeos-filesystem@64bit_virtio-2G
https://openqa.opensuse.org/tests/1694862

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed
Comment 78 Martin Loviska 2021-04-16 07:22:50 UTC
Hello, the problem seems to persist in sle15sp2 ( tested on QR3 JeOS candidate - sle-15-SP2-JeOS-for-kvm-and-xen-QR-x86_64-Build15.80 ).

* systemd package list:
util-linux-systemd-2.33.1-4.13.2.x86_64
libsystemd0-234-24.79.1.x86_64
systemd-presets-common-SUSE-15-8.3.1.noarch
systemd-presets-branding-SLE-15.1-20.5.1.noarch
systemd-234-24.79.1.x86_64
systemd-sysvinit-234-24.79.1.x86_64

/usr/lib/systemd/system-preset/90-default-SLE.preset still enables btrfsmaintenance-refresh.service.

/usr/lib/systemd/system-preset/90-default-SLE.preset:enable btrfsmaintenance-refresh.service
/usr/lib/systemd/system-preset/95-default-SUSE.preset:enable btrfs-balance.timer
/usr/lib/systemd/system-preset/95-default-SUSE.preset:enable btrfs-defrag.timer
/usr/lib/systemd/system-preset/95-default-SUSE.preset:enable btrfs-scrub.timer
/usr/lib/systemd/system-preset/95-default-SUSE.preset:enable btrfs-trim.timer
/usr/lib/systemd/system-preset/95-default-SUSE.preset:disable btrfsmaintenance-refresh.service
/usr/lib/systemd/system-preset/95-default-SUSE.preset:enable btrfsmaintenance-refresh.path

https://build.suse.de/package/view_file/SUSE:SLE-15-SP1:Update/systemd-presets-branding-SLE.15036/default-SLE.preset?expand=1
Comment 80 Michal Suchanek 2021-04-16 10:22:32 UTC
Is this needed in Leap/Factory as well?
Comment 81 Fabian Vogt 2021-04-16 10:26:05 UTC
(In reply to Michal Suchanek from comment #80)
> Is this needed in Leap/Factory as well?

In Factory it's fixed for a while. The fix was also submitted to 15 SP1, but needed another submission to actually be effective in SLE (comment 79). Leap didn't need that.
Comment 82 Santiago Zarate 2021-04-21 16:06:37 UTC
I wonder if the same fix is needed for SP3: https://openqa.suse.de/tests/5847309#step/btrfsmaintenance/20
Comment 83 Fabian Vogt 2021-04-22 07:27:32 UTC
(In reply to Santiago Zarate from comment #82)
> I wonder if the same fix is needed for SP3:
> https://openqa.suse.de/tests/5847309#step/btrfsmaintenance/20

That's because of

(In reply to Fabian Vogt from comment #81)
> (In reply to Michal Suchanek from comment #80)
> > Is this needed in Leap/Factory as well?
> 
> In Factory it's fixed for a while. The fix was also submitted to 15 SP1, but
> needed another submission to actually be effective in SLE (comment 79). Leap
> didn't need that.
Comment 84 Swamp Workflow Management 2021-04-30 10:21:06 UTC
SUSE-RU-2021:1449-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1165780
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    systemd-presets-branding-SLE-15.1-20.8.1
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    systemd-presets-branding-SLE-15.1-20.8.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 85 Martin Loviska 2021-05-05 12:22:43 UTC
Works for sle15sp3 ( tested on sle-15-SP3-JeOS-for-kvm-and-xen-x86_64-Build2.31)
https://openqa.suse.de/tests/5951943#step/btrfsmaintenance/18
Comment 86 Martin Loviska 2021-05-14 08:33:34 UTC
Unfortunately we can still see failures of caused by incorrect presets in sle15sp2.

https://openqa.suse.de/tests/5998504#step/btrfsmaintenance/20
Comment 87 Fabian Vogt 2021-05-14 08:46:01 UTC
(In reply to Martin Loviska from comment #86)
> Unfortunately we can still see failures of caused by incorrect presets in
> sle15sp2.
> 
> https://openqa.suse.de/tests/5998504#step/btrfsmaintenance/20

According to the .packages file, it still has 
systemd-presets-branding-SLE-15.1-20.5.1, while it's only fixed in 20.8.1. That was released 14 days ago though...
Comment 88 Marcus Meissner 2021-05-14 10:03:34 UTC
The QR last snapshot might have been before the release.
Comment 89 Oliver Kurz 2021-05-31 06:18:34 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: jeos-filesystem
https://openqa.suse.de/tests/5924075

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed
Comment 90 Oliver Kurz 2021-06-14 06:18:56 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: jeos-filesystem
https://openqa.suse.de/tests/5924075

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed
Comment 92 openQA Review 2021-07-06 14:22:55 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6382393

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed
Comment 93 openQA Review 2021-07-21 00:45:31 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6493840

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed
Comment 94 openQA Review 2021-08-05 01:27:37 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6637925

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed
Comment 95 openQA Review 2021-08-19 02:29:00 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6637925

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed
Comment 96 openQA Review 2021-09-02 03:51:15 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6637925

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed
Comment 97 openQA Review 2021-09-17 01:21:40 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/6637925

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 98 Martin Loviska 2021-09-23 09:37:02 UTC
We cannot see the failure anymore in QR images nor among updates:

* [sle-15-SP3-JeOS-for-kvm-and-xen-QR-x86_64-Build3.3.1](https://openqa.suse.de/tests/7160384#step/btrfsmaintenance/17)
* [sle-15-SP2-JeOS-for-kvm-and-xen-QR-x86_64-Build15.93](https://openqa.suse.de/tests/7161356#step/btrfsmaintenance/17)
* [sle-15-SP3-JeOS-for-kvm-and-xen-Updates-x86_64-Build20210923](https://openqa.suse.de/tests/7198657#step/btrfsmaintenance/17)
* [sle-15-SP2-JeOS-for-kvm-and-xen-Updates-x86_64-Build20210923](https://openqa.suse.de/tests/7198626#step/btrfsmaintenance/17)
Comment 99 openQA Review 2021-10-08 00:55:16 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7341446

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 100 openQA Review 2021-10-22 01:41:37 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7501986

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 101 openQA Review 2021-11-12 01:08:32 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7639225

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 102 openQA Review 2021-11-26 01:34:37 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7741125

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 103 openQA Review 2021-12-10 02:53:00 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7812956

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 104 openQA Review 2021-12-25 00:37:24 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7899856

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 105 openQA Review 2022-01-08 00:41:42 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/7950268

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 106 openQA Review 2022-01-22 01:02:58 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8000755

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 107 openQA Review 2022-02-05 01:19:35 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8104759

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 108 openQA Review 2022-02-19 01:20:28 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8192329

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 109 openQA Review 2022-03-19 01:29:35 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8341996

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.
Comment 110 Radoslav Tzvetkov 2022-03-29 13:45:38 UTC
David, any update for SLE15 SP4 on this?
Comment 111 openQA Review 2022-04-19 01:11:41 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8560139

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 40 days if nothing changes in this ticket.
Comment 112 openQA Review 2022-05-29 01:13:32 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: mau-filesystem
https://openqa.suse.de/tests/8808749

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`

Expect the next reminder at the earliest in 80 days if nothing changes in this ticket.