Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247095 > unrolled thread

updatedb.mlocate

Back to article view | Back to linux.debian.user

Contents

  updatedb.mlocate "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-04-09 18:40 +0200
    Re: updatedb.mlocate Roberto C. Sánchez <roberto@debian.org> - 2022-04-09 18:50 +0200
      Re: updatedb.mlocate Brian <ad44@cityscape.co.uk> - 2022-04-09 19:00 +0200
        Re: updatedb.mlocate "sp007@caiway.net" <sp007@caiway.net> - 2022-04-09 19:30 +0200
        Re: updatedb.mlocate Brian <ad44@cityscape.co.uk> - 2022-04-09 19:40 +0200
        Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-09 20:10 +0200
      Re: updatedb.mlocate "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-04-10 16:40 +0200
    Re: updatedb.mlocate Charles Curley <charlescurley@charlescurley.com> - 2022-04-09 19:30 +0200
      Re: updatedb.mlocate "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-04-10 16:50 +0200
        Re: updatedb.mlocate David Wright <deblis@lionunicorn.co.uk> - 2022-04-11 01:30 +0200
    Re: updatedb.mlocate gene heskett <gheskett@shentel.net> - 2022-04-09 21:50 +0200
      Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-09 22:40 +0200
        Re: updatedb.mlocate gene heskett <gheskett@shentel.net> - 2022-04-09 23:00 +0200
          Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-09 23:20 +0200
            Re: updatedb.mlocate "Roy J. Tellason, Sr." <roy@rtellason.com> - 2022-04-10 17:00 +0200
          Re: updatedb.mlocate Charles Curley <charlescurley@charlescurley.com> - 2022-04-10 05:30 +0200
            Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-10 06:00 +0200
              Re: updatedb.mlocate <tomas@tuxteam.de> - 2022-04-10 08:10 +0200
              Re: updatedb.mlocate Linux-Fan <Ma_Sys.ma@web.de> - 2022-04-10 11:40 +0200
                Re: updatedb.mlocate gene heskett <gheskett@shentel.net> - 2022-04-10 12:10 +0200
                  Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-10 16:40 +0200
                    Re: updatedb.mlocate Darac Marjal <mailinglist@darac.org.uk> - 2022-04-10 16:50 +0200
                      Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-10 18:10 +0200
                        Re: updatedb.mlocate David Wright <deblis@lionunicorn.co.uk> - 2022-04-10 20:50 +0200
                Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-10 16:10 +0200
                  Re: updatedb.mlocate gene heskett <gheskett@shentel.net> - 2022-04-10 22:40 +0200
                  Re: updatedb.mlocate David Wright <deblis@lionunicorn.co.uk> - 2022-04-11 01:30 +0200
                    Re: updatedb.mlocate David <bouncingcats@gmail.com> - 2022-04-11 01:40 +0200
                      Re: updatedb.mlocate Greg Wooledge <greg@wooledge.org> - 2022-04-11 02:00 +0200
                        Re: updatedb.mlocate David <bouncingcats@gmail.com> - 2022-04-11 02:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#247152

On Sun, Apr 10, 2022 at 06:03:13AM -0400, gene heskett wrote:
> Thats fine, as long as the systemd stuff is disabled by finding an entry 
> in the presently logged in users ~/.config, but I do not consider that as 
> a user item. thats (updatedb) sysadmin stuff, and much of this hoohah 
> could be prevented by setting the trigger time at install time with a 
> random time between 1 and 4 AM when most users are inactive anyway. How 
> many lines of bash code would it take to do that, 3? 4? IDK but it could 
> be done...

The mlocate package includes a /lib/systemd/system/mlocate.timer file.
It's static content.  If the package maintainer wanted to randomize the
contents, they would need to write code in the mlocate.postinst script
to change the static file -- which is a really BAD idea.  A slightly
better idea: don't include the static file at all, but include code in
the mlocate.postinst which generates a randomized mlocate.timer file.

The mlocate.postinst script is not a bash script.  It's an sh script.
So, the "obvious" way to do it in bash (a here document with $((RANDOM%...))
expressions in it) won't work.  They would need to call out to some
external process (perhaps awk) to generate some random numbers, store
those in variables, and then use the variables in the here document.

They would also need to arrange for the randomized mlocate.timer file
to be cleaned up when the package is removed, so that's even more code
to write.

Kind of a pain in the ass.

Even if randomizing the times is more trouble than it's worth, I wonder
how much support might exist for simply specifying a different static time
for each package that currently runs at midnight.  E.g. have mlocate
run at 00:05, have man-db run at 00:10, have logrotate run at 00:15,
and so on.  I don't know how many different timers all run at midnight --
just the ones that *I* happen to have.  There are probably lots more.

[toc] | [prev] | [next] | [standalone]

#247156

[Multipart message — attachments visible in raw view] — view raw

On 10/04/2022 15:29, Greg Wooledge wrote:
> On Sun, Apr 10, 2022 at 06:03:13AM -0400, gene heskett wrote:
>> Thats fine, as long as the systemd stuff is disabled by finding an entry
>> in the presently logged in users ~/.config, but I do not consider that as
>> a user item. thats (updatedb) sysadmin stuff, and much of this hoohah
>> could be prevented by setting the trigger time at install time with a
>> random time between 1 and 4 AM when most users are inactive anyway. How
>> many lines of bash code would it take to do that, 3? 4? IDK but it could
>> be done...
> The mlocate package includes a /lib/systemd/system/mlocate.timer file.
> It's static content.  If the package maintainer wanted to randomize the
> contents, they would need to write code in the mlocate.postinst script
> to change the static file -- which is a really BAD idea.  A slightly
> better idea: don't include the static file at all, but include code in
> the mlocate.postinst which generates a randomized mlocate.timer file.
>
> The mlocate.postinst script is not a bash script.  It's an sh script.
> So, the "obvious" way to do it in bash (a here document with $((RANDOM%...))
> expressions in it) won't work.  They would need to call out to some
> external process (perhaps awk) to generate some random numbers, store
> those in variables, and then use the variables in the here document.
>
> They would also need to arrange for the randomized mlocate.timer file
> to be cleaned up when the package is removed, so that's even more code
> to write.
>
> Kind of a pain in the ass.
>
> Even if randomizing the times is more trouble than it's worth, I wonder
> how much support might exist for simply specifying a different static time
> for each package that currently runs at midnight.  E.g. have mlocate
> run at 00:05, have man-db run at 00:10, have logrotate run at 00:15,
> and so on.  I don't know how many different timers all run at midnight --
> just the ones that *I* happen to have.  There are probably lots more.

Systemd already supports this.

* AccuracySec=   Specify the accuracy the timer shall elapse with. [...] 
Within this time window, the expiry time shall be placed at a 
host-specific, randomized, but stable position.

* RandomizedDelaySec =    Delay the timer by a randomly selected, evenly 
distributed amount of time between 0 and the specified time value.


So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply 
"once per day, but at a random time during the day".

>

[toc] | [prev] | [next] | [standalone]

#247160

On Sun, Apr 10, 2022 at 03:49:02PM +0100, Darac Marjal wrote:
> Systemd already supports this.
> 
> * AccuracySec=   Specify the accuracy the timer shall elapse with. [...]
> Within this time window, the expiry time shall be placed at a host-specific,
> randomized, but stable position.
> 
> * RandomizedDelaySec =    Delay the timer by a randomly selected, evenly
> distributed amount of time between 0 and the specified time value.
> 
> 
> So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply
> "once per day, but at a random time during the day".

If that's the case, it's not working correctly on my system.  mlocate
has OnCalendar=daily and AccuracySec=24h, but before I changed it, it
was scheduled to run *exactly* at midnight.

/lib/systemd/system/man-db.timer has OnCalendar=daily and AccuracySec=12h
and it's scheduled to run *exactly* at midnight.

/lib/systemd/system/logrotate.timer has OnCalendar=daily and AccuracySec=1h
and it's scheduled to run *exactly* at midnight.

unicorn:~$ systemctl list-timers | grep 00:00
Mon 2022-04-11 00:00:00 EDT 13h left    Sun 2022-04-10 00:00:00 EDT 10h ago      logrotate.timer              logrotate.service
Mon 2022-04-11 00:00:00 EDT 13h left    Sun 2022-04-10 00:00:00 EDT 10h ago      man-db.timer                 man-db.service

Further evidence in the form of timestamps on files in /var/log:

-rw-r-----   1 root    adm             1559363 Apr  9 23:59 auth.log.1
-rw-r-----   1 root    adm              568405 Apr  9 23:59 mail.log.1
-rw-r-----   1 root    adm              568405 Apr  9 23:59 mail.info.1
-rw-r-----   1 root    adm                   0 Apr 10 00:00 mail.warn
-rw-r-----   1 root    adm                   0 Apr 10 00:00 debug
-rw-r-----   1 root    adm              740788 Apr 10 00:00 syslog.1
-rw-r-----   1 root    adm               46660 Apr 10 00:00 daemon.log.1

Previously I had noted that the mlocate db timestamp was at midnight
as well.

[toc] | [prev] | [next] | [standalone]

#247164

On Sun 10 Apr 2022 at 12:04:05 (-0400), Greg Wooledge wrote:
> On Sun, Apr 10, 2022 at 03:49:02PM +0100, Darac Marjal wrote:
> > Systemd already supports this.
> > 
> > * AccuracySec=   Specify the accuracy the timer shall elapse with. [...]
> > Within this time window, the expiry time shall be placed at a host-specific,
> > randomized, but stable position.
> > 
> > * RandomizedDelaySec =    Delay the timer by a randomly selected, evenly
> > distributed amount of time between 0 and the specified time value.
> > 
> > 
> > So, "OnCalendar=daily" together with "AccuracySec=24h" *seems* to imply
> > "once per day, but at a random time during the day".
> 
> If that's the case, it's not working correctly on my system.  mlocate
> has OnCalendar=daily and AccuracySec=24h, but before I changed it, it
> was scheduled to run *exactly* at midnight.
> 
> /lib/systemd/system/man-db.timer has OnCalendar=daily and AccuracySec=12h
> and it's scheduled to run *exactly* at midnight.
> 
> /lib/systemd/system/logrotate.timer has OnCalendar=daily and AccuracySec=1h
> and it's scheduled to run *exactly* at midnight.

I think that's because there are two more options whose default values
are zero and false, so they're not specified in our .timer files.

AIUI, setting RandomizedDelaySec=24hr would get you the effect it
seems you expected above, but I seriously think you wouldn't want.

AccuracySec appears to allow several expiring timers to be grouped
into one instant if that instant is within the range allowed, hence
minimising wakeups; RandomizedDelaySec does the opposite, spreading
them out, hence minimising spikes in system load.

If you set RandomizedDelaySec=24hr, then mlocate/whatever would run
at random times of day each day. Setting FixedRandomDelay=true would
make mlocate/whatever run at the same time each day, and that time
would be whatever happened to be chosen on the first day.
(I think buster/241 lacks the fixed one.)

I'm quite happy for mlocate to run (almost) first thing in the morning
when I turn on the computer (assuming I didn't run it beyond midnight
last night).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#247151

On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote:
> Greg Wooledge writes:
> > unicorn:~$ less /lib/systemd/system/mlocate.timer
> > [Unit]
> > Description=Updates mlocate database every day
> > 
> > [Timer]
> > OnCalendar=daily
> > AccuracySec=24h
> > Persistent=true
> > 
> > [Install]
> > WantedBy=timers.target
> > 
> > ... it doesn't even say when it runs?  What silliness is this?

I was mistaken: it *does* say when it runs, but only if you've read at
least two different man pages.

systemd.timer(5) says that OnCalendar= specifies a "calendar event
expression", and refers to systemd.time(7) to explain what that means.

systemd.time(7) says that a "calendar event" defines one or more points
in time, and then gives some examples.  By reading these examples,
one may infer that this thing specifies when the timer will trigger.

It also explains that the keyword "daily" doesn't just mean "once a day".
It actually says:

                  daily → *-*-* 00:00:00

In other words, "daily" explicitly means "once a day at local midnight",
assuming you can infer that "*-*-*" means "once a day".

So, apparently it's the Debian developers who decided to make a bunch of
jobs all run at the same time (local midnight), either by making a bad
choice, or by being lazy.

> # systemctl list-timers
> NEXT                         LEFT          LAST                         PASSED    UNIT                         ACTIVATES
> Mon 2022-04-11 00:00:00 CEST 12h left      Sun 2022-04-10 00:00:01 CEST 11h ago   mlocate.timer                mlocate.service
> 
> It shows that at least on my system, it is going to run on 00:00 local time.

Yeah, but... it doesn't say *why* or how to change it.  See above.

> I can imagine that the idea behind not specifying the actual time in the
> individual unit allows you to configure the actual time of invocation
> somehwere else. This way if you have a lot of machines all online you can
> avoid having bursts of activity in the entire network/datacenter just as the
> clock turns to 00:00.

Indeed, the Debian developers have passed that burden on to the local
system administrator.  Worse, they didn't give any guidance or even a
cargo-cultable example for how to override it.  Users are expected to
figure it out themselves.

> Specifically in the case of `cron`, I think it is an improvement that user-
> specific timers are now kept in the user's home directory
> (~/.config/systemd/user directory) rather than a system directory
> (/var/spool/cron/crontabs).

I am extremely skeptical of how useful it is to specify a systemd timer
at the --user level.  They'll only run when the systemd --user service
manager is running, which is only when the user is logged in.

What kind of jobs would you schedule in a timer, that you would want
to run *only* when you are logged in?  I can't really think of any.
Most scheduled jobs would be things I would want to trigger regardless
of whether I'm logged in (cleaning up logs and temp files, retrieving
email from a remote mail server).  I guess *some* things could be
deferred until login, like randomizing an email .signature file, but
those would be the exceptions.

Now, let's see if I can figure out how to override the time at which
mlocate runs its update.  I'll apply some previous systemd knowledge
that I happen to possess already, which is that in order to override
the getty@.service configuration, one must create a directory named
/etc/systemd/system/getty@.service.d and put *.conf files in it.

So, extrapolating from that, let's try creating...

unicorn:~$ sudo mkdir -p /etc/systemd/system/mlocate.timer.d
[sudo] password for greg: 
unicorn:~$ sudo vi /etc/systemd/system/mlocate.timer.d/time.conf
unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf
[Timer]
OnCalendar=
OnCalendar=04:20

I created a three-line override file which clears out the previous
OnCalendar= event(s), and then sets up a new event that runs the thing
at 04:20 each day, instead of midnight each day.

unicorn:~$ sudo systemctl daemon-reload
unicorn:~$ systemctl list-timers | grep mlocate
Mon 2022-04-11 04:20:00 EDT 18h left    Sun 2022-04-10 09:58:20 EDT 16s ago      mlocate.timer                mlocate.service

Slight oops -- after I updated the daemon, the new time for the timer
had already expired, so it ran immediately.  That's definitely not how
cron works (changing the time on a cron job doesn't cause an immediate
job execution).  I wonder how one would go about changing the time on
a systemd timer *without* triggering an immediate execution in the middle
of the work day.

[toc] | [prev] | [next] | [standalone]

#247169

On Sunday, 10 April 2022 10:04:53 EDT Greg Wooledge wrote:
> On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote:
> > Greg Wooledge writes:
> > > unicorn:~$ less /lib/systemd/system/mlocate.timer
> > > [Unit]
> > > Description=Updates mlocate database every day
> > > 
> > > [Timer]
> > > OnCalendar=daily
> > > AccuracySec=24h
> > > Persistent=true
> > > 
> > > [Install]
> > > WantedBy=timers.target
> > > 
> > > ... it doesn't even say when it runs?  What silliness is this?
> 
> I was mistaken: it *does* say when it runs, but only if you've read at
> least two different man pages.
> 
> systemd.timer(5) says that OnCalendar= specifies a "calendar event
> expression", and refers to systemd.time(7) to explain what that means.
> 
> systemd.time(7) says that a "calendar event" defines one or more points
> in time, and then gives some examples.  By reading these examples, one
> may infer that this thing specifies when the timer will trigger.
> 
> It also explains that the keyword "daily" doesn't just mean "once a
> day". It actually says:
> 
>                   daily → *-*-* 00:00:00
> 
> In other words, "daily" explicitly means "once a day at local
> midnight", assuming you can infer that "*-*-*" means "once a day".
> 
> So, apparently it's the Debian developers who decided to make a bunch
> of jobs all run at the same time (local midnight), either by making a
> bad choice, or by being lazy.
> 
> > # systemctl list-timers
> > NEXT                         LEFT          LAST                      
> >   PASSED    UNIT                         ACTIVATES Mon 2022-04-11
> > 00:00:00 CEST 12h left      Sun 2022-04-10 00:00:01 CEST 11h ago  
> > mlocate.timer                mlocate.service
> > 
> > It shows that at least on my system, it is going to run on 00:00
> > local time.
> Yeah, but... it doesn't say *why* or how to change it.  See above.
> 
> > I can imagine that the idea behind not specifying the actual time in
> > the individual unit allows you to configure the actual time of
> > invocation somehwere else. This way if you have a lot of machines
> > all online you can avoid having bursts of activity in the entire
> > network/datacenter just as the clock turns to 00:00.
> 
> Indeed, the Debian developers have passed that burden on to the local
> system administrator.  Worse, they didn't give any guidance or even a
> cargo-cultable example for how to override it.  Users are expected to
> figure it out themselves.
> 
> > Specifically in the case of `cron`, I think it is an improvement that
> > user- specific timers are now kept in the user's home directory
> > (~/.config/systemd/user directory) rather than a system directory
> > (/var/spool/cron/crontabs).
> 
> I am extremely skeptical of how useful it is to specify a systemd timer
> at the --user level.  They'll only run when the systemd --user service
> manager is running, which is only when the user is logged in.
> 
> What kind of jobs would you schedule in a timer, that you would want
> to run *only* when you are logged in?  I can't really think of any.
> Most scheduled jobs would be things I would want to trigger regardless
> of whether I'm logged in (cleaning up logs and temp files, retrieving
> email from a remote mail server).  I guess *some* things could be
> deferred until login, like randomizing an email .signature file, but
> those would be the exceptions.
> 
> Now, let's see if I can figure out how to override the time at which
> mlocate runs its update.  I'll apply some previous systemd knowledge
> that I happen to possess already, which is that in order to override
> the getty@.service configuration, one must create a directory named
> /etc/systemd/system/getty@.service.d and put *.conf files in it.
> 
> So, extrapolating from that, let's try creating...
> 
> unicorn:~$ sudo mkdir -p /etc/systemd/system/mlocate.timer.d
> [sudo] password for greg:
> unicorn:~$ sudo vi /etc/systemd/system/mlocate.timer.d/time.conf
> unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf
> [Timer]
> OnCalendar=
> OnCalendar=04:20
> 
> I created a three-line override file which clears out the previous
> OnCalendar= event(s), and then sets up a new event that runs the thing
> at 04:20 each day, instead of midnight each day.
> 
> unicorn:~$ sudo systemctl daemon-reload
> unicorn:~$ systemctl list-timers | grep mlocate
> Mon 2022-04-11 04:20:00 EDT 18h left    Sun 2022-04-10 09:58:20 EDT 16s
> ago      mlocate.timer                mlocate.service
> 
> Slight oops -- after I updated the daemon, the new time for the timer
> had already expired, so it ran immediately.  That's definitely not how
> cron works (changing the time on a cron job doesn't cause an immediate
> job execution).  I wonder how one would go about changing the time on
> a systemd timer *without* triggering an immediate execution in the
> middle of the work day.
> 
> .
anacron?

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#247173

On Sun 10 Apr 2022 at 10:04:53 (-0400), Greg Wooledge wrote:
> On Sun, Apr 10, 2022 at 11:33:53AM +0200, Linux-Fan wrote:
> > Greg Wooledge writes:
> > > unicorn:~$ less /lib/systemd/system/mlocate.timer
> > > [Unit]
> > > Description=Updates mlocate database every day
> > > 
> > > [Timer]
> > > OnCalendar=daily
> > > AccuracySec=24h
> > > Persistent=true
> > > 
> > > [Install]
> > > WantedBy=timers.target
> > > 
> > > ... it doesn't even say when it runs?  What silliness is this?
> 
> I was mistaken: it *does* say when it runs, but only if you've read at
> least two different man pages.
> 
> systemd.timer(5) says that OnCalendar= specifies a "calendar event
> expression", and refers to systemd.time(7) to explain what that means.
> 
> systemd.time(7) says that a "calendar event" defines one or more points
> in time, and then gives some examples.  By reading these examples,
> one may infer that this thing specifies when the timer will trigger.
> 
> It also explains that the keyword "daily" doesn't just mean "once a day".
> It actually says:
> 
>                   daily → *-*-* 00:00:00
> 
> In other words, "daily" explicitly means "once a day at local midnight",
> assuming you can infer that "*-*-*" means "once a day".

To be fair, man systemd.time is extremely comprehensive, with abundant
examples (* is expressly defined). So I'm not surprised that it's
hived off into a separate man page to avoid repeating it elsewhere.

> > Specifically in the case of `cron`, I think it is an improvement that user-
> > specific timers are now kept in the user's home directory
> > (~/.config/systemd/user directory) rather than a system directory
> > (/var/spool/cron/crontabs).
> 
> I am extremely skeptical of how useful it is to specify a systemd timer
> at the --user level.  They'll only run when the systemd --user service
> manager is running, which is only when the user is logged in.
> 
> What kind of jobs would you schedule in a timer, that you would want
> to run *only* when you are logged in?  I can't really think of any.
> Most scheduled jobs would be things I would want to trigger regardless
> of whether I'm logged in (cleaning up logs and temp files, retrieving
> email from a remote mail server).  I guess *some* things could be
> deferred until login, like randomizing an email .signature file, but
> those would be the exceptions.

I don't think it's in the nature of systemd to be proscriptive. One of
its advantages is its extreme, almost overwhelming, flexibility.

> unicorn:~$ cat /etc/systemd/system/mlocate.timer.d/time.conf
> [Timer]
> OnCalendar=
> OnCalendar=04:20
> 
> I created a three-line override file which clears out the previous
> OnCalendar= event(s), and then sets up a new event that runs the thing
> at 04:20 each day, instead of midnight each day.
> 
> unicorn:~$ sudo systemctl daemon-reload
> unicorn:~$ systemctl list-timers | grep mlocate
> Mon 2022-04-11 04:20:00 EDT 18h left    Sun 2022-04-10 09:58:20 EDT 16s ago      mlocate.timer                mlocate.service
> 
> Slight oops -- after I updated the daemon, the new time for the timer
> had already expired, so it ran immediately.  That's definitely not how
> cron works (changing the time on a cron job doesn't cause an immediate
> job execution).  I wonder how one would go about changing the time on
> a systemd timer *without* triggering an immediate execution in the middle
> of the work day.

I'm guessing two possibilities might be worth trying:

systemctl disable mlocate.service   before you fiddle with its
configuration, then enable it afterwards.

touch /var/lib/systemd/timers/stamp-mlocate.timer   with a time
in the future, so that systemd thinks it has already been run.

I don't think they're mutually exclusive.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#247174

On Mon, 11 Apr 2022 at 09:24, David Wright <deblis@lionunicorn.co.uk> wrote:

> systemctl disable mlocate.service   before you fiddle with its
> configuration, then enable it afterwards.

Hi, I think you need "stop" and "start" there, not "disable" and
and "enable".

Or maybe "systemctl daemon-reload" although I'm not sure
about that because I don't know much about systemd.

But a quick test here shows that a "disable" command on a
running service does not stop it.

It's my understanding that "enable" and "disable" only control
whether the service is started at boot time.

Someone who knows better is welcome to confirm or
correct if I am mistaken, thanks.

[toc] | [prev] | [next] | [standalone]

#247175

On Mon, Apr 11, 2022 at 09:34:42AM +1000, David wrote:
> On Mon, 11 Apr 2022 at 09:24, David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> > systemctl disable mlocate.service   before you fiddle with its
> > configuration, then enable it afterwards.
> 
> Hi, I think you need "stop" and "start" there, not "disable" and
> and "enable".
> 
> Or maybe "systemctl daemon-reload" although I'm not sure
> about that because I don't know much about systemd.
> 
> But a quick test here shows that a "disable" command on a
> running service does not stop it.

It's not a running service.  It's a service that's started by a timer.
The other David's proposal was to disable it, in the hope that this
would prevent the timer from being able to start it.

However, I don't think that would work.  I think you'd need to mask it.

That said, I have not tested either of those things.

[toc] | [prev] | [next] | [standalone]

#247176

On Mon, 11 Apr 2022 at 09:50, Greg Wooledge <greg@wooledge.org> wrote:
> On Mon, Apr 11, 2022 at 09:34:42AM +1000, David wrote:
> > On Mon, 11 Apr 2022 at 09:24, David Wright <deblis@lionunicorn.co.uk> wrote:
> >
> > > systemctl disable mlocate.service   before you fiddle with its
> > > configuration, then enable it afterwards.
> >
> > Hi, I think you need "stop" and "start" there, not "disable" and
> > and "enable".
> >
> > Or maybe "systemctl daemon-reload" although I'm not sure
> > about that because I don't know much about systemd.
> >
> > But a quick test here shows that a "disable" command on a
> > running service does not stop it.
>
> It's not a running service.  It's a service that's started by a timer.
> The other David's proposal was to disable it, in the hope that this
> would prevent the timer from being able to start it.

Ah, you're right, I wasn't paying sufficient attention and missed
that, sorry for adding noise to the thread.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web