[Bug 1165780] New: Reduce the number of PID1 reloading triggered by btrfsmaintenance units
http://bugzilla.suse.com/show_bug.cgi?id=1165780 Bug ID: 1165780 Summary: Reduce the number of PID1 reloading triggered by btrfsmaintenance units Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: fbui@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c1 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |dsterba@suse.com --- Comment #1 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Reduce the number of PID1 |Reduce the number of PID1 |reloading triggered by |reloading triggered by |btrfsmaintenance units |btrfsmaintenance -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c2 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com --- Comment #2 from Fabian Vogt <fvogt@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c5 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dsterba@suse.com |kernel-maintainers@forge.pr | |ovo.novell.com --- Comment #5 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c6 --- Comment #6 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- See also: https://en.opensuse.org/SDB:Fix_btrfsmaintenance-refresh -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c7 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com --- Comment #7 from Michal Suchanek <msuchanek@suse.com> --- If you have a fix submit it to the package. Also a summary of the issue would be helpful. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c8 --- Comment #8 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://github.com/kdave/bt | |rfsmaintenance/pull/79 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c9 --- Comment #9 from Franck Bui <fbui@suse.com> --- (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 ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c10 --- Comment #10 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c11 --- Comment #11 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- 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:~ # -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c12 --- Comment #12 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c13 --- Comment #13 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c14 --- Comment #14 from Fabian Vogt <fvogt@suse.com> --- (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/df43313e20745f14de7dcc9b1f5df... 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c15 --- Comment #15 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c16 --- Comment #16 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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=2932... https://forums.opensuse.org/showthread.php/539806-files-disappear-reappear-i... https://forums.opensuse.org/showthread.php/539503-boot-efi-is-not-mounted?p=...
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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c17 --- Comment #17 from Franck Bui <fbui@suse.com> --- (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" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c18 --- Comment #18 from Franck Bui <fbui@suse.com> --- Also what's the point of enabling the service unit if the path unit is suposed to automatically trigger it ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c19 --- Comment #19 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- Created attachment 836007 --> http://bugzilla.suse.com/attachment.cgi?id=836007&action=edit before -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c20 --- Comment #20 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- Created attachment 836008 --> http://bugzilla.suse.com/attachment.cgi?id=836008&action=edit after -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c21 --- Comment #21 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c22 --- Comment #22 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 M Fredericks <emfee@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emfee@gmx.net -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c23 --- Comment #23 from Franck Bui <fbui@suse.com> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c24 Karl Mistelberger <karl.mistelberger@nefkom.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #836007|0 |1 is obsolete| | --- Comment #24 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- Created attachment 836104 --> http://bugzilla.suse.com/attachment.cgi?id=836104&action=edit erroneous activation of btrfsmaintenance-refresh The attachment shows journal of rescue system (without debug enabled) with erroneous activation of btrfsmaintenance-refresh.service -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c25 --- Comment #25 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c26 --- Comment #26 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- 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... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c27 --- Comment #27 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c28 --- Comment #28 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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-btrfsmaintenanc...
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:~ # -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c29 --- Comment #29 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c30 --- Comment #30 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c31 --- Comment #31 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c32 --- Comment #32 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c33 --- Comment #33 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c34 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com Flags| |needinfo?(meissner@suse.com | |) --- Comment #34 from Franck Bui <fbui@suse.com> --- (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 ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c35 --- Comment #35 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c36 --- Comment #36 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c37 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(msuchanek@suse.co | |m) --- Comment #37 from Franck Bui <fbui@suse.com> --- @Michal Suchanek, can you please deal with the PR ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 http://bugzilla.suse.com/show_bug.cgi?id=1165780#c38 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://github.com/kdave/bt |https://github.com/kdave/bt |rfsmaintenance/pull/79 |rfsmaintenance/pull/81 CC| |dsterba@suse.com Assignee|kernel-maintainers@forge.pr |dsterba@suse.com |ovo.novell.com | Flags|needinfo?(meissner@suse.com |needinfo?(dsterba@suse.com) |), | |needinfo?(msuchanek@suse.co | |m) | --- Comment #38 from Michal Suchanek <msuchanek@suse.com> --- David, please merge the PR and submit to OBS. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c39 David Sterba <dsterba@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dsterba@suse.com) | --- Comment #39 from David Sterba <dsterba@suse.com> --- I've released 0.5 upstream, updated the devel project and submitted that to Factory. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c41 --- Comment #41 from Franck Bui <fbui@suse.com> --- The change doesn't seem to be available in TW, anything wrong happened ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c42 --- Comment #42 from Fabian Vogt <fvogt@suse.com> --- (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/. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c43 --- Comment #43 from Franck Bui <fbui@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c44 --- Comment #44 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c45 --- Comment #45 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c46 --- Comment #46 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c47 --- Comment #47 from Karl Mistelberger <karl.mistelberger@nefkom.net> ---
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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c48 --- Comment #48 from Fabian Vogt <fvogt@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c49 --- Comment #49 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c50 --- Comment #50 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c51 --- Comment #51 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c52 владимир путин <1000Hz.radiowave@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |1000Hz.radiowave@gmail.com --- Comment #52 from владимир путин <1000Hz.radiowave@gmail.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c53 --- Comment #53 from владимир путин <1000Hz.radiowave@gmail.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Frederic Crozat <fcrozat@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat@suse.com, | |rgoldwyn@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c55 --- Comment #55 from Goldwyn Rodrigues <rgoldwyn@suse.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c56 --- Comment #56 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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" :~ # -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c57 --- Comment #57 from asf <1000Hz.radiowave@gmail.com> --- 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! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c58 --- Comment #58 from asf <1000Hz.radiowave@gmail.com> --- and yeah, i forgot the instabilities in snapper work, as a bonus you may get to the btrfsmaintenance package. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c59 --- Comment #59 from Franck Bui <fbui@suse.com> --- (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*. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c60 --- Comment #60 from Franck Bui <fbui@suse.com> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c61 --- Comment #61 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c62 --- Comment #62 from Karl Mistelberger <karl.mistelberger@nefkom.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c65 --- Comment #65 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c66 --- Comment #66 from Franck Bui <fbui@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c68 --- Comment #68 from asf <1000Hz.radiowave@gmail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c69 --- Comment #69 from Franck Bui <fbui@suse.com> --- (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 ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rgoldwyn@suse.com | |) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c71 --- Comment #71 from asf <1000Hz.radiowave@gmail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1178874 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Bj�rn Voigt <bjoernv@arcor.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjoernv@arcor.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c75 --- Comment #75 from Swamp Workflow Management <swamp@suse.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c76 --- Comment #76 from Swamp Workflow Management <swamp@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c77 --- Comment #77 from Oliver Kurz <okurz@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c78 Martin Loviska <mloviska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mloviska@suse.com --- Comment #78 from Martin Loviska <mloviska@suse.com> --- 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-prese... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c80 --- Comment #80 from Michal Suchanek <msuchanek@suse.com> --- Is this needed in Leap/Factory as well? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c81 --- Comment #81 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c82 Santiago Zarate <santiago.zarate@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |santiago.zarate@suse.com, | |sweiberg@suse.com Flags| |needinfo?(sweiberg@suse.com | |) --- Comment #82 from Santiago Zarate <santiago.zarate@suse.com> --- I wonder if the same fix is needed for SP3: https://openqa.suse.de/tests/5847309#step/btrfsmaintenance/20 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c83 --- Comment #83 from Fabian Vogt <fvogt@suse.com> --- (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.
-- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c84 --- Comment #84 from Swamp Workflow Management <swamp@suse.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c85 --- Comment #85 from Martin Loviska <mloviska@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c86 --- Comment #86 from Martin Loviska <mloviska@suse.com> --- Unfortunately we can still see failures of caused by incorrect presets in sle15sp2. https://openqa.suse.de/tests/5998504#step/btrfsmaintenance/20 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c87 --- Comment #87 from Fabian Vogt <fvogt@suse.com> --- (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... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c88 --- Comment #88 from Marcus Meissner <meissner@suse.com> --- The QR last snapshot might have been before the release. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c89 --- Comment #89 from Oliver Kurz <okurz@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Jose Lausuch <jalausuch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jalausuch@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 Stefan Weiberg <sweiberg@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sweiberg@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c90 --- Comment #90 from Oliver Kurz <okurz@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c92 --- Comment #92 from openQA Review <openqa-review@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c93 --- Comment #93 from openQA Review <openqa-review@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c94 --- Comment #94 from openQA Review <openqa-review@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c95 --- Comment #95 from openQA Review <openqa-review@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c96 --- Comment #96 from openQA Review <openqa-review@suse.de> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c97 --- Comment #97 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 M Fredericks <emfee@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|emfee@gmx.net | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c98 --- Comment #98 from Martin Loviska <mloviska@suse.com> --- 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) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c99 --- Comment #99 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c100 --- Comment #100 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 ���������������� ���������� <1000Hz.radiowave@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|1000Hz.radiowave@gmail.com | -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c101 --- Comment #101 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c102 --- Comment #102 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c103 --- Comment #103 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c104 --- Comment #104 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c105 --- Comment #105 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c106 --- Comment #106 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c107 --- Comment #107 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c108 --- Comment #108 from openQA Review <openqa-review@suse.de> --- 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` -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c109 --- Comment #109 from openQA Review <openqa-review@suse.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c110 Radoslav Tzvetkov <rtsvetkov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rtsvetkov@suse.com Flags| |needinfo?(dsterba@suse.com) --- Comment #110 from Radoslav Tzvetkov <rtsvetkov@suse.com> --- David, any update for SLE15 SP4 on this? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c111 --- Comment #111 from openQA Review <openqa-review@suse.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1165780 https://bugzilla.suse.com/show_bug.cgi?id=1165780#c112 --- Comment #112 from openQA Review <openqa-review@suse.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com