Hi guys,
I am about to release 1.45.2 for Fedora rawhide, but I was thinking
about how to package the e2scrub cron job/systemd service.
I really do not like the idea of installing cron job and/or the service as
a part of regular e2fsprogs package. This can potentially really surprise
people in a bad way.
Note that I've already heard some complaints from debian users about the
systemd service being installed on their system after the e2fsprogs
update.
What I am going to do is to split the systemd service into a separate
package and I'd like to come to some agreement about the name of the
package so that we can have the same name across distributions (at least
Fedora/Debian/Suse).
I was thinking about e2scrub-service for systemd service or e2scrub-cron
for the cron job. What do you think ?
Also I decided not to package the cron job for now. But if I decide to
package it in the future I'd like to change the e2scrub cron
configuration so that it can run on the systems with systemd but make
the package conflict with the e2scrub-service so that users are free to
decide how they want to use it.
Thoughts ?
Thanks!
-Lukas
On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> Hi guys,
>
> I am about to release 1.45.2 for Fedora rawhide, but I was thinking
> about how to package the e2scrub cron job/systemd service.
Funny, xfs has the same conundrum. Adding Eric & xfs list to cc...
> I really do not like the idea of installing cron job and/or the service as
> a part of regular e2fsprogs package. This can potentially really surprise
> people in a bad way.
>
> Note that I've already heard some complaints from debian users about the
> systemd service being installed on their system after the e2fsprogs
> update.
Yeah, e2scrub is bitrotting rather faster than I had thought it
would... but it's only available in Debian unstable.
> What I am going to do is to split the systemd service into a separate
> package and I'd like to come to some agreement about the name of the
> package so that we can have the same name across distributions (at least
> Fedora/Debian/Suse).
Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
that name to be very clunky and would have preferred "xfs_scrub".
> I was thinking about e2scrub-service for systemd service or e2scrub-cron
> for the cron job. What do you think ?
In /theory/ the cronjob support in e2scrub (and xfs_scrub) were designed
to step out of the way if systemd is running, so at least in theory (on
Debian anyway) the two can be in the same package with the end result
being that e2scrub runs weekly in the background. I've not tried in
rhel/suse environments, however.
I also don't see the point of supporting cron *while* systemd is active.
That increases the amount of corner-case testing we have to do, for
little gain. It's enough work to maintain the systemd-with-timers and
sysvinit-with-cron scenarios.
If you're worried about the stability of systemd timer code, systemd's
timer support has been stable enough to run e2scrub_all/xfs_scrub_all on
my systems since late 2015, and I have no interest in supporting either
on a pre-2016 distro. Practically speaking, I guess that RHEL8, SLES16,
and Ubuntu 20.04 will be the first LTS distros to support e2scrub at
all.
(As for xfs_scrub, it'll barely achieve alpha status in Linux 5.2...)
> Also I decided not to package the cron job for now. But if I decide to
> package it in the future I'd like to change the e2scrub cron
> configuration so that it can run on the systems with systemd but make
> the package conflict with the e2scrub-service so that users are free to
> decide how they want to use it.
If you do end up creating two packages I'd name the systemd one
e2scrub-systemd over e2scrub-service.
--D
> Thoughts ?
>
> Thanks!
> -Lukas
On 5/29/19 1:21 PM, Darrick J. Wong wrote:
> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
>> Hi guys,
>>
>> I am about to release 1.45.2 for Fedora rawhide, but I was thinking
>> about how to package the e2scrub cron job/systemd service.
>
> Funny, xfs has the same conundrum. Adding Eric & xfs list to cc...
>
>> I really do not like the idea of installing cron job and/or the service as
>> a part of regular e2fsprogs package. This can potentially really surprise
>> people in a bad way.
>>
>> Note that I've already heard some complaints from debian users about the
>> systemd service being installed on their system after the e2fsprogs
>> update.
>
> Yeah, e2scrub is bitrotting rather faster than I had thought it
> would... but it's only available in Debian unstable.
>
>> What I am going to do is to split the systemd service into a separate
>> package and I'd like to come to some agreement about the name of the
>> package so that we can have the same name across distributions (at least
>> Fedora/Debian/Suse).
>
> Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> that name to be very clunky and would have preferred "xfs_scrub".
Yes it is a bit clunky but *shrug*
The main motivator for this was one piece uses python3 and that Made People
Sad who wanted minimal systems with minimal deps but still wanted xfsprogs.
Keeping services separate is a good idea as well, I think.
I don't have a strong opinion on whether /just/ the service should be separate,
or the scrub util + the service should be separate.
I put all the xfs scrubbing bits in one package in rawhide.
-Eric
On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> Hi guys,
>
> I am about to release 1.45.2 for Fedora rawhide, but I was thinking
> about how to package the e2scrub cron job/systemd service.
>
> I really do not like the idea of installing cron job and/or the service as
> a part of regular e2fsprogs package. This can potentially really surprise
> people in a bad way.
>
> Note that I've already heard some complaints from debian users about the
> systemd service being installed on their system after the e2fsprogs
> update.
One of the reasons I deliberately decided to enable it for Debian
Unstable was it was the best way to flush out the bugs. :-)
Yeah, Debian Unstable users are my guinea pigs. :-) Doesn't it work
that way with Fedora and RHEL? :-)
BTW, The complaints were mostly from e2scrub_all not working correctly
if certain packages weren't installed, or if the LVM package was
installed, but there were no LVM volumes present, etc. The other
complaint I got was when there was no free space for the snapshot.
I'm kind of hopeful that I've gotten them all at this point, but we'll
see....
> What I am going to do is to split the systemd service into a separate
> package and I'd like to come to some agreement about the name of the
> package so that we can have the same name across distributions (at least
> Fedora/Debian/Suse).
Hmm.... what keeping the service as part of the e2fsprogs package, but
then not enabling out of the box. That is, require that user run:
systemctl enable e2scrub_all.timer
in order to actually get the feature? (They can also disable it using
"systemctl disable e2scrub_all.timer".)
As far as the cron job is concerned, we could just leave the crontab
entry commented out by default, and require that the user go in and
edit the /etc/cron.d/e2scrub_all file if they want to enable it. Not
packaging it also seems fine; Debian's support for non-systemd
configurations is at best marginal at this point, and while I'm not a
fan of systemd, I'm also a realist...
What do folks think?
- Ted
Rather than naming the packages "e2scrub-*" it makes more sense to me to use "e2fsprogs-scrub" so that it is clear this is a sub-package of e2fsprogs? Or is the thought that the scrub functionality might move out of e2fsprogs and xfsprogs at some point in the future.
Cheers, Andreas
PS: I'd agree with Darrick that "xfsprogs-scrub" is probably a better name.
> On May 29, 2019, at 17:59, Theodore Ts'o <[email protected]> wrote:
>
>> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
>> Hi guys,
>>
>> I am about to release 1.45.2 for Fedora rawhide, but I was thinking
>> about how to package the e2scrub cron job/systemd service.
>>
>> I really do not like the idea of installing cron job and/or the service as
>> a part of regular e2fsprogs package. This can potentially really surprise
>> people in a bad way.
>>
>> Note that I've already heard some complaints from debian users about the
>> systemd service being installed on their system after the e2fsprogs
>> update.
>
> One of the reasons I deliberately decided to enable it for Debian
> Unstable was it was the best way to flush out the bugs. :-)
>
> Yeah, Debian Unstable users are my guinea pigs. :-) Doesn't it work
> that way with Fedora and RHEL? :-)
>
> BTW, The complaints were mostly from e2scrub_all not working correctly
> if certain packages weren't installed, or if the LVM package was
> installed, but there were no LVM volumes present, etc. The other
> complaint I got was when there was no free space for the snapshot.
> I'm kind of hopeful that I've gotten them all at this point, but we'll
> see....
>
>> What I am going to do is to split the systemd service into a separate
>> package and I'd like to come to some agreement about the name of the
>> package so that we can have the same name across distributions (at least
>> Fedora/Debian/Suse).
>
> Hmm.... what keeping the service as part of the e2fsprogs package, but
> then not enabling out of the box. That is, require that user run:
>
> systemctl enable e2scrub_all.timer
>
> in order to actually get the feature? (They can also disable it using
> "systemctl disable e2scrub_all.timer".)
>
> As far as the cron job is concerned, we could just leave the crontab
> entry commented out by default, and require that the user go in and
> edit the /etc/cron.d/e2scrub_all file if they want to enable it. Not
> packaging it also seems fine; Debian's support for non-systemd
> configurations is at best marginal at this point, and while I'm not a
> fan of systemd, I'm also a realist...
>
> What do folks think?
>
> - Ted
On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> that name to be very clunky and would have preferred "xfs_scrub".
Why not just xfs-scrub?
On Wed 29-05-19 19:59:48, Theodore Ts'o wrote:
> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> > What I am going to do is to split the systemd service into a separate
> > package and I'd like to come to some agreement about the name of the
> > package so that we can have the same name across distributions (at least
> > Fedora/Debian/Suse).
>
> Hmm.... what keeping the service as part of the e2fsprogs package, but
> then not enabling out of the box. That is, require that user run:
>
> systemctl enable e2scrub_all.timer
>
> in order to actually get the feature? (They can also disable it using
> "systemctl disable e2scrub_all.timer".)
>
> As far as the cron job is concerned, we could just leave the crontab
> entry commented out by default, and require that the user go in and
> edit the /etc/cron.d/e2scrub_all file if they want to enable it. Not
> packaging it also seems fine; Debian's support for non-systemd
> configurations is at best marginal at this point, and while I'm not a
> fan of systemd, I'm also a realist...
>
> What do folks think?
Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
support only systemd init anyway these days (and in fact our distro people
want to deprecate cron in favor of systemd). I guess I'll split off the
scrub bits into a separate sub-package (likely e2fsprogs will suggest
installation of this sub-package) and the service will be disabled by
default.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> support only systemd init anyway these days (and in fact our distro people
> want to deprecate cron in favor of systemd). I guess I'll split off the
> scrub bits into a separate sub-package (likely e2fsprogs will suggest
> installation of this sub-package) and the service will be disabled by
> default.
I'm not super-fond of extra sub-packages for their own sake, and the
extra e2scrub bits are small enough (about 32k?) that I don't believe
it justifies an extra sub-package; but that's a distribution-level
packaging decision, so it's certainly fine if we're not completely aligned.
My plan is to change the Debian package to turn off the timer unit
file by default, probably with a NEWS.Debian file[1] which tells users
how to enable it if they want at package installation time --- but to
keep the e2scrub bits in the base e2fsprogs package.
[1] https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-news-debian
Out of curiosity, were any of the complaints that you've heard gone
beyond people who ran into the various e2scrub/e2scrub_all bugs? I'm
curious what their concerns were.
- Ted
On Wed, May 29, 2019 at 11:04:26PM -0700, Christoph Hellwig wrote:
> On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> > Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> > that name to be very clunky and would have preferred "xfs_scrub".
>
> Why not just xfs-scrub?
Slight preference for the package sharing a name with its key
ingredient:
# xfs_scrub /home
Bad command or file name
# apt install xfs_scrub
<stuff>
# xfs_scrub /home
WARNING: ALL DATA ON NON-REMOVABLE DISK
DRIVE C: WILL BE LOST!
Proceed with Format (Y/N)?
--D
On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
> On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> > support only systemd init anyway these days (and in fact our distro people
> > want to deprecate cron in favor of systemd). I guess I'll split off the
> > scrub bits into a separate sub-package (likely e2fsprogs will suggest
> > installation of this sub-package) and the service will be disabled by
> > default.
>
> I'm not super-fond of extra sub-packages for their own sake, and the
> extra e2scrub bits are small enough (about 32k?) that I don't believe
> it justifies an extra sub-package; but that's a distribution-level
> packaging decision, so it's certainly fine if we're not completely aligned.
Yes, size is not a big concern but the scrub bits require util-linux, lvm,
and mailer to work correctly and I don't want to add these dependencies to
stock e2fsprogs package because some minimal installations do not want e.g.
lvm at all. Granted these are just scripts so I could get away with not
requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
user to determine that his systemd-service fails due to missing packages.
> Out of curiosity, were any of the complaints that you've heard gone
> beyond people who ran into the various e2scrub/e2scrub_all bugs? I'm
> curious what their concerns were.
I didn't hear any complaints so far. But I have my doubts anyone actually
run that code so far - openSUSE Tumbleweed has limited userbase, we do
installs to btrfs by default, we don't propose LVM by default, and I didn't
enable the service files to run by default.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote:
> On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
> > On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> > > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> > > support only systemd init anyway these days (and in fact our distro people
> > > want to deprecate cron in favor of systemd). I guess I'll split off the
> > > scrub bits into a separate sub-package (likely e2fsprogs will suggest
> > > installation of this sub-package) and the service will be disabled by
> > > default.
> >
> > I'm not super-fond of extra sub-packages for their own sake, and the
> > extra e2scrub bits are small enough (about 32k?) that I don't believe
> > it justifies an extra sub-package; but that's a distribution-level
> > packaging decision, so it's certainly fine if we're not completely aligned.
>
> Yes, size is not a big concern but the scrub bits require util-linux, lvm,
> and mailer to work correctly and I don't want to add these dependencies to
> stock e2fsprogs package because some minimal installations do not want e.g.
> lvm at all. Granted these are just scripts so I could get away with not
> requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
> user to determine that his systemd-service fails due to missing packages.
So you're using an extra package to force the installation of the
necessary prerequisite packages, instead of the current approach where
we don't require them, but we just skip running the scrub if lvm and
util-linux are not present. I think both approaches makes sense.
It's also a good point that we need to handle the case of a missing
sendmail intelligently. It looks like we currently skip sending mail
at all in the cron case, and in the case systemd case, we'll spew a
warning (which won't get mailed since there's no sendmail, but it does
mean some extra lines in the logfile). All of this being said, it's
not _completely_ useless to scrub without an mailer; we still mark the
file system as needing to be checked on the next boot. But it's
another argument that we shouldn't enable the service by default.
For that reason, I'm not sure I'd want to force the installation of a
mailer, since someone might want to run e2scrub by hand, and
e2scrub_all every week w/o isn't a completely insane thing. But we
certainly should handle that case gracefully.
- Ted
On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote:
> On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
> > On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> > > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> > > support only systemd init anyway these days (and in fact our distro people
> > > want to deprecate cron in favor of systemd). I guess I'll split off the
> > > scrub bits into a separate sub-package (likely e2fsprogs will suggest
> > > installation of this sub-package) and the service will be disabled by
> > > default.
> >
> > I'm not super-fond of extra sub-packages for their own sake, and the
> > extra e2scrub bits are small enough (about 32k?) that I don't believe
> > it justifies an extra sub-package; but that's a distribution-level
> > packaging decision, so it's certainly fine if we're not completely aligned.
>
> Yes, size is not a big concern but the scrub bits require util-linux, lvm,
> and mailer to work correctly and I don't want to add these dependencies to
> stock e2fsprogs package because some minimal installations do not want e.g.
> lvm at all. Granted these are just scripts so I could get away with not
> requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
> user to determine that his systemd-service fails due to missing packages.
All good reasons for a separate package, particularly considering that
on the RH side they've split out xfs_scrub because of its python 3
dependencies.
> > Out of curiosity, were any of the complaints that you've heard gone
> > beyond people who ran into the various e2scrub/e2scrub_all bugs? I'm
> > curious what their concerns were.
>
> I didn't hear any complaints so far. But I have my doubts anyone actually
> run that code so far - openSUSE Tumbleweed has limited userbase, we do
> installs to btrfs by default, we don't propose LVM by default, and I didn't
> enable the service files to run by default.
(I suspect it's only Debian Unstable users who are running it right
now...)
--D
>
> Honza
> --
> Jan Kara <[email protected]>
> SUSE Labs, CR
On May 31, 2019, at 8:10 AM, Theodore Ts'o <[email protected]> wrote:
>
> On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote:
>> On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
>>> On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
>>>> Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
>>>> support only systemd init anyway these days (and in fact our distro people
>>>> want to deprecate cron in favor of systemd). I guess I'll split off the
>>>> scrub bits into a separate sub-package (likely e2fsprogs will suggest
>>>> installation of this sub-package) and the service will be disabled by
>>>> default.
>>>
>>> I'm not super-fond of extra sub-packages for their own sake, and the
>>> extra e2scrub bits are small enough (about 32k?) that I don't believe
>>> it justifies an extra sub-package; but that's a distribution-level
>>> packaging decision, so it's certainly fine if we're not completely aligned.
>>
>> Yes, size is not a big concern but the scrub bits require util-linux, lvm,
>> and mailer to work correctly and I don't want to add these dependencies to
>> stock e2fsprogs package because some minimal installations do not want e.g.
>> lvm at all. Granted these are just scripts so I could get away with not
>> requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
>> user to determine that his systemd-service fails due to missing packages.
>
> So you're using an extra package to force the installation of the
> necessary prerequisite packages, instead of the current approach where
> we don't require them, but we just skip running the scrub if lvm and
> util-linux are not present. I think both approaches makes sense.
>
> It's also a good point that we need to handle the case of a missing
> sendmail intelligently. It looks like we currently skip sending mail
> at all in the cron case, and in the case systemd case, we'll spew a
> warning (which won't get mailed since there's no sendmail, but it does
> mean some extra lines in the logfile). All of this being said, it's
> not _completely_ useless to scrub without an mailer; we still mark the
> file system as needing to be checked on the next boot. But it's
> another argument that we shouldn't enable the service by default.
>
> For that reason, I'm not sure I'd want to force the installation of a
> mailer, since someone might want to run e2scrub by hand, and
> e2scrub_all every week w/o isn't a completely insane thing. But we
> certainly should handle that case gracefully.
If sendmail is unavailable (and maybe even if it *is* available), e2scrub
can use logger to write a short message to syslog if there is an error.
Something like:
e2scrub: $device errors detected, needs offline e2fsck to correct
e2scrub: $device logs in /var/log/e2scrub....
in mark_corrupt() or from e2scrub_fail.
Cheers, Andreas
On Fri 31-05-19 10:10:19, Theodore Ts'o wrote:
> On Fri, May 31, 2019 at 12:07:13PM +0200, Jan Kara wrote:
> > On Thu 30-05-19 09:51:55, Theodore Ts'o wrote:
> > > On Thu, May 30, 2019 at 11:59:07AM +0200, Jan Kara wrote:
> > > > Yeah, my plan is to just not package cron bits at all since openSUSE / SLES
> > > > support only systemd init anyway these days (and in fact our distro people
> > > > want to deprecate cron in favor of systemd). I guess I'll split off the
> > > > scrub bits into a separate sub-package (likely e2fsprogs will suggest
> > > > installation of this sub-package) and the service will be disabled by
> > > > default.
> > >
> > > I'm not super-fond of extra sub-packages for their own sake, and the
> > > extra e2scrub bits are small enough (about 32k?) that I don't believe
> > > it justifies an extra sub-package; but that's a distribution-level
> > > packaging decision, so it's certainly fine if we're not completely aligned.
> >
> > Yes, size is not a big concern but the scrub bits require util-linux, lvm,
> > and mailer to work correctly and I don't want to add these dependencies to
> > stock e2fsprogs package because some minimal installations do not want e.g.
> > lvm at all. Granted these are just scripts so I could get away with not
> > requiring e.g. lvm at all but it seems user-unfriendly to leave it up to
> > user to determine that his systemd-service fails due to missing packages.
>
> So you're using an extra package to force the installation of the
> necessary prerequisite packages, instead of the current approach where
> we don't require them, but we just skip running the scrub if lvm and
> util-linux are not present. I think both approaches makes sense.
>
> It's also a good point that we need to handle the case of a missing
> sendmail intelligently. It looks like we currently skip sending mail
> at all in the cron case, and in the case systemd case, we'll spew a
> warning (which won't get mailed since there's no sendmail, but it does
> mean some extra lines in the logfile). All of this being said, it's
> not _completely_ useless to scrub without an mailer; we still mark the
> file system as needing to be checked on the next boot. But it's
> another argument that we shouldn't enable the service by default.
>
> For that reason, I'm not sure I'd want to force the installation of a
> mailer, since someone might want to run e2scrub by hand, and
> e2scrub_all every week w/o isn't a completely insane thing. But we
> certainly should handle that case gracefully.
Yeah, if the scripts can handle missing mailer and do something useful in
that case, I think I will switch the RPM dependency on postfix to just
Recommends and not Requires.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Le Thu, 30 May 2019 08:28:55 -0700
"Darrick J. Wong" <[email protected]> écrivait:
> On Wed, May 29, 2019 at 11:04:26PM -0700, Christoph Hellwig wrote:
> > On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> > > Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I
> > > find that name to be very clunky and would have preferred
> > > "xfs_scrub".
> >
> > Why not just xfs-scrub?
>
> Slight preference for the package sharing a name with its key
> ingredient:
>
> # xfs_scrub /home
> Bad command or file name
> # apt install xfs_scrub
> <stuff>
> # xfs_scrub /home
> WARNING: ALL DATA ON NON-REMOVABLE DISK
> DRIVE C: WILL BE LOST!
> Proceed with Format (Y/N)?
>
> --D
Debian packages always replace _ with - in the package name itself
because the _ is used to separate the package name proper from the
version and architecture : package_version_arch.deb.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <[email protected]>
| +33 1 78 94 84 02
------------------------------------------------------------------------
On Wed, May 29, 2019 at 07:59:48PM -0400, Theodore Ts'o wrote:
> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> > Hi guys,
> >
> > I am about to release 1.45.2 for Fedora rawhide, but I was thinking
> > about how to package the e2scrub cron job/systemd service.
> >
> > I really do not like the idea of installing cron job and/or the service as
> > a part of regular e2fsprogs package. This can potentially really surprise
> > people in a bad way.
> >
> > Note that I've already heard some complaints from debian users about the
> > systemd service being installed on their system after the e2fsprogs
> > update.
>
> One of the reasons I deliberately decided to enable it for Debian
> Unstable was it was the best way to flush out the bugs. :-)
>
> Yeah, Debian Unstable users are my guinea pigs. :-) Doesn't it work
> that way with Fedora and RHEL? :-)
>
> BTW, The complaints were mostly from e2scrub_all not working correctly
> if certain packages weren't installed, or if the LVM package was
> installed, but there were no LVM volumes present, etc. The other
> complaint I got was when there was no free space for the snapshot.
> I'm kind of hopeful that I've gotten them all at this point, but we'll
> see....
Yeah, I've heard from two people and it was all about the service being
enabled by default when installing/updating e2fsprogs which for them was
very much unexpected. They were the types of people what want to have as
much controll as they can so they were annoyed by that and immediatelly
disabled the service :)
>
> > What I am going to do is to split the systemd service into a separate
> > package and I'd like to come to some agreement about the name of the
> > package so that we can have the same name across distributions (at least
> > Fedora/Debian/Suse).
>
> Hmm.... what keeping the service as part of the e2fsprogs package, but
> then not enabling out of the box. That is, require that user run:
>
> systemctl enable e2scrub_all.timer
>
> in order to actually get the feature? (They can also disable it using
> "systemctl disable e2scrub_all.timer".)
That's the suggestion for rpm packages in fedora - not enabling services by
default. I am still not decided about this since installing separate service
package is strong enough of a hint that user probably want to enable it.
>
> As far as the cron job is concerned, we could just leave the crontab
> entry commented out by default, and require that the user go in and
> edit the /etc/cron.d/e2scrub_all file if they want to enable it. Not
> packaging it also seems fine; Debian's support for non-systemd
> configurations is at best marginal at this point, and while I'm not a
> fan of systemd, I'm also a realist...
Yeah, commenting out the crontab entry sounds like a good way to go
about it.
>
> What do folks think?
>
> - Ted
On Wed, May 29, 2019 at 11:21:11AM -0700, Darrick J. Wong wrote:
> On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> > Hi guys,
> >
> > I am about to release 1.45.2 for Fedora rawhide, but I was thinking
> > about how to package the e2scrub cron job/systemd service.
>
> Funny, xfs has the same conundrum. Adding Eric & xfs list to cc...
>
> > I really do not like the idea of installing cron job and/or the service as
> > a part of regular e2fsprogs package. This can potentially really surprise
> > people in a bad way.
> >
> > Note that I've already heard some complaints from debian users about the
> > systemd service being installed on their system after the e2fsprogs
> > update.
>
> Yeah, e2scrub is bitrotting rather faster than I had thought it
> would... but it's only available in Debian unstable.
>
> > What I am going to do is to split the systemd service into a separate
> > package and I'd like to come to some agreement about the name of the
> > package so that we can have the same name across distributions (at least
> > Fedora/Debian/Suse).
>
> Indeed. Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
> that name to be very clunky and would have preferred "xfs_scrub".
>
> > I was thinking about e2scrub-service for systemd service or e2scrub-cron
> > for the cron job. What do you think ?
>
> In /theory/ the cronjob support in e2scrub (and xfs_scrub) were designed
> to step out of the way if systemd is running, so at least in theory (on
> Debian anyway) the two can be in the same package with the end result
> being that e2scrub runs weekly in the background. I've not tried in
> rhel/suse environments, however.
>
> I also don't see the point of supporting cron *while* systemd is active.
> That increases the amount of corner-case testing we have to do, for
> little gain. It's enough work to maintain the systemd-with-timers and
> sysvinit-with-cron scenarios.
Yeah, you're probably right. I just wanted to give people some options
if they do not want (for whatever reason) to use systemd. Container
environment might be a good example of that, but I am not at all sure
how well is lvm2 supported in containers.
>
> If you're worried about the stability of systemd timer code, systemd's
> timer support has been stable enough to run e2scrub_all/xfs_scrub_all on
> my systems since late 2015, and I have no interest in supporting either
> on a pre-2016 distro. Practically speaking, I guess that RHEL8, SLES16,
> and Ubuntu 20.04 will be the first LTS distros to support e2scrub at
> all.
>
> (As for xfs_scrub, it'll barely achieve alpha status in Linux 5.2...)
>
> > Also I decided not to package the cron job for now. But if I decide to
> > package it in the future I'd like to change the e2scrub cron
> > configuration so that it can run on the systems with systemd but make
> > the package conflict with the e2scrub-service so that users are free to
> > decide how they want to use it.
>
> If you do end up creating two packages I'd name the systemd one
> e2scrub-systemd over e2scrub-service.
Ok, thanks for suggestion. Andreas was suggesting naming it as part of
e2fsprogs, that is - e2fsprogs-scrub but then it would be
e2fsprogs-scrub-systemd and that sounds a bit convoluted to me.
Thanks!
-Lukas
>
> --D
>
> > Thoughts ?
> >
> > Thanks!
> > -Lukas