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 1 of 2  [1] 2  Next page →

#247095 — updatedb.mlocate

So around midnight I am seeing a burst of activity,  which sometimes interferes with whatever else I happen to be doing at the time.  Looking at the process list,  I see the above-referenced come and go.  I didn't want this,  and it's not apparent to me how to deal with it.

How do I find out where this is invoked,  so I can get rid of it?


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [next] | [standalone]

#247096

On Sat, Apr 09, 2022 at 11:04:18AM -0500, Roy J. Tellason, Sr. wrote:
> So around midnight I am seeing a burst of activity,  which sometimes interferes with whatever else I happen to be doing at the time.  Looking at the process list,  I see the above-referenced come and go.  I didn't want this,  and it's not apparent to me how to deal with it.
> 
> How do I find out where this is invoked,  so I can get rid of it?
> 
You can uninstall the mlocate package.  Or, you can edit
/etc/cron.daily/mlocate and comment out the cron entry.  That would
leave the package installed, but you would need to keep the database
updated manually.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#247097

On Sat 09 Apr 2022 at 12:39:45 -0400, Roberto C. Sánchez wrote:

> On Sat, Apr 09, 2022 at 11:04:18AM -0500, Roy J. Tellason, Sr. wrote:
> > So around midnight I am seeing a burst of activity,  which sometimes interferes with whatever else I happen to be doing at the time.  Looking at the process list,  I see the above-referenced come and go.  I didn't want this,  and it's not apparent to me how to deal with it.
> > 
> > How do I find out where this is invoked,  so I can get rid of it?
> > 
> You can uninstall the mlocate package.  Or, you can edit
> /etc/cron.daily/mlocate and comment out the cron entry.  That would
> leave the package installed, but you would need to keep the database
> updated manually.

Or replace mlocate with plocate, which is reckoned to be better than
mlocate.

-- 
Brian.

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

#247098

On Sat, 9 Apr 2022 17:50:03 +0100
Brian <ad44@cityscape.co.uk> wrote:

<
plocate is a locate(1) based on posting lists, giving much faster searches
on a much smaller index. It is a drop-in replacement for mlocate in nearly
all aspects, and is fast on SSDs and non-SSDs alike.
>

Besides this it also handles sshfs mounts proper

my 2 EURO cents


> On Sat 09 Apr 2022 at 12:39:45 -0400, Roberto C. Sánchez wrote:
> 
> > On Sat, Apr 09, 2022 at 11:04:18AM -0500, Roy J. Tellason, Sr. wrote:
> > > So around midnight I am seeing a burst of activity,  which sometimes interferes with whatever else I happen to be doing at the time.  Looking at the process list,  I see the above-referenced come and go.  I didn't want this,  and it's not apparent to me how to deal with it.
> > > 
> > > How do I find out where this is invoked,  so I can get rid of it?
> > > 
> > You can uninstall the mlocate package.  Or, you can edit
> > /etc/cron.daily/mlocate and comment out the cron entry.  That would
> > leave the package installed, but you would need to keep the database
> > updated manually.
> 
> Or replace mlocate with plocate, which is reckoned to be better than
> mlocate.
> 

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

#247100

On Sat 09 Apr 2022 at 18:18:31 +0100, Brad Rogers wrote:

> On Sat, 9 Apr 2022 17:50:03 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> Hello Brian,
> 
> >Or replace mlocate with plocate, which is reckoned to be better than
> 
> mlocate is a transitional package in Debian.  It installs plocate.  Which
> means Roy is likely running plocate anyway.  Therefore mlocate can be
> removed.
> 
> From info on the Debian package tracker, plocate has been used in place
> of mlocate since at least October 2020.  There's no data going back
> further.

Thank you, Brad, for clarifying.

I remember the discussions on -devel regarding plocate. It is on my
Debain 11 system, but I could not remember how it got there and did
not investigate.

-- 
Brian.

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

#247101

On Sat, Apr 09, 2022 at 06:18:31PM +0100, Brad Rogers wrote:
> mlocate is a transitional package in Debian.  It installs plocate.  Which
> means Roy is likely running plocate anyway.  Therefore mlocate can be
> removed.

This is not the case in Debian 11 (stable).  It appears to be true in
testing and unstable, though.

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

#247154

On Saturday 09 April 2022 12:39:45 pm Roberto C. Sánchez wrote:
> On Sat, Apr 09, 2022 at 11:04:18AM -0500, Roy J. Tellason, Sr. wrote:
> > So around midnight I am seeing a burst of activity,  which sometimes interferes with whatever else I happen to be doing at the time.  Looking at the process list,  I see the above-referenced come and go.  I didn't want this,  and it's not apparent to me how to deal with it.
> > 
> > How do I find out where this is invoked,  so I can get rid of it?
> > 
> You can uninstall the mlocate package.  Or, you can edit
> /etc/cron.daily/mlocate and comment out the cron entry.  That would
> leave the package installed, but you would need to keep the database
> updated manually.

Okay,  I found the script by that name and made it not executable.  We'll see if that works.

What I'd really like to know is,  why is this happening now when it wasn't happening before?  It probably changed after my last round of updating things...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#247099

On Sat, 9 Apr 2022 11:04:18 -0500
"Roy J. Tellason, Sr." <roy@rtellason.com> wrote:

> How do I find out where this is invoked,  so I can get rid of it?

You may not want to get rid of it. That's the process that updates the
database for the locate utility, which is very useful.

I was about to add, think instead about adding a nice value to its cron
entry. However it look like mlocate is now handled by systemd, and I
don't know enough to advise you on how to do that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#247155

On Saturday 09 April 2022 01:22:08 pm Charles Curley wrote:
> On Sat, 9 Apr 2022 11:04:18 -0500
> "Roy J. Tellason, Sr." <roy@rtellason.com> wrote:
> 
> > How do I find out where this is invoked,  so I can get rid of it?
> 
> You may not want to get rid of it. That's the process that updates the
> database for the locate utility, which is very useful.

Yeah,  it's useful if you change things on the system.  I don't do that all that often,  though.
 
> I was about to add, think instead about adding a nice value to its cron
> entry. 

There is some stuff about that in the script in question,  but rather than working my way through all that I just made that script not executable.

> However it look like mlocate is now handled by systemd, and I 
> don't know enough to advise you on how to do that.
 
I don't understand the reason for so many things getting pushed in that direction.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#247172

On Sun 10 Apr 2022 at 09:52:15 (-0500), Roy J. Tellason, Sr. wrote:
> On Saturday 09 April 2022 01:22:08 pm Charles Curley wrote:
> > On Sat, 9 Apr 2022 11:04:18 -0500
> > "Roy J. Tellason, Sr." <roy@rtellason.com> wrote:
> > 
> > > How do I find out where this is invoked,  so I can get rid of it?
> > 
> > You may not want to get rid of it. That's the process that updates the
> > database for the locate utility, which is very useful.
> 
> Yeah,  it's useful if you change things on the system.  I don't do that all that often,  though.

Bear in mind it indexes /home, so you can use it for your own files.
Obviously, it's a lot faster than find.

> > I was about to add, think instead about adding a nice value to its cron
> > entry. 
> 
> There is some stuff about that in the script in question,  but rather than working my way through all that I just made that script not executable.
> 
> > However it look like mlocate is now handled by systemd, and I 
> > don't know enough to advise you on how to do that.
>  
> I don't understand the reason for so many things getting pushed in that direction.

It's far more flexible than cron and anacron. But cron is still there,
so you could move it back. But I think Greg's contributions to this
thread have enough information to make it straightforward for you to
change the time to suit.

Cheers,
David.

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

#247104

On Saturday, 9 April 2022 12:04:18 EDT Roy J. Tellason, Sr. wrote:
> So around midnight I am seeing a burst of activity,  which sometimes
> interferes with whatever else I happen to be doing at the time. 
> Looking at the process list,  I see the above-referenced come and go. 
> I didn't want this,  and it's not apparent to me how to deal with it.
> 
> How do I find out where this is invoked,  so I can get rid of it?

It used to be in a root crontab, where you could delay it to say 3 am.
But I've no clue where its at in the later versions since systemd took 
over.  Run synaptic, search for locate, and see if properties>installed 
files will tell you where the time entry is now. Its a pretty handy 
utility so I wouldn't remove it, its keeping its database up to date so 
you can do a "locate filename", and find out where in terabytes of data, 
that filename might be found.  
> --
> Member of the toughest, meanest, deadliest, most unrelenting -- and
> ablest -- form of life in this section of space,  a critter that can
> be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet
> Masters" -
> Information is more dangerous than cannon to a society ruled by lies.
> --James M Dakin
> 
> .


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]

#247106

On Sat, Apr 09, 2022 at 03:40:41PM -0400, gene heskett wrote:
> On Saturday, 9 April 2022 12:04:18 EDT Roy J. Tellason, Sr. wrote:
> > So around midnight I am seeing a burst of activity,  which sometimes
> > interferes with whatever else I happen to be doing at the time. 
> > Looking at the process list,  I see the above-referenced come and go. 
> > I didn't want this,  and it's not apparent to me how to deal with it.
> > 
> > How do I find out where this is invoked,  so I can get rid of it?
> 
> It used to be in a root crontab, where you could delay it to say 3 am.
> But I've no clue where its at in the later versions since systemd took 
> over.

It's in cron.daily.

unicorn:~$ ls /etc/cron.daily/
apt-compat*  dpkg*           man-db*   popularity-contest*
aptitude*    google-chrome@  mlocate*  spamassassin*
calendar*    logrotate*      ntp*      sysstat*

So, you could change when the cron.daily job runs, but you can't easily
postpone just one part of cron.daily.

unicorn:~$ grep daily /etc/crontab
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

I don't remember whether I moved that to 06:25 myself, or what.  But
anyway, that's where you would change it.

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

#247107

On Saturday, 9 April 2022 16:35:26 EDT Greg Wooledge wrote:
> grep daily /etc/crontab

Matches mine too Greg, so I expect thats default, but why is Roy's going 
off at about midnight?

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]

#247109

On Sat, Apr 09, 2022 at 04:59:04PM -0400, gene heskett wrote:
> On Saturday, 9 April 2022 16:35:26 EDT Greg Wooledge wrote:
> > grep daily /etc/crontab
> 
> Matches mine too Greg, so I expect thats default, but why is Roy's going 
> off at about midnight?

We'd have to see what his /etc/crontab contains, and what his system
clock is set to.

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

#247158

On Saturday 09 April 2022 05:11:39 pm Greg Wooledge wrote:
> On Sat, Apr 09, 2022 at 04:59:04PM -0400, gene heskett wrote:
> > On Saturday, 9 April 2022 16:35:26 EDT Greg Wooledge wrote:
> > > grep daily /etc/crontab
> > 
> > Matches mine too Greg, so I expect thats default, but why is Roy's going 
> > off at about midnight?
> 
> We'd have to see what his /etc/crontab contains, 

Trying to paste it in here,  but after opening it,  copying it,  paste seems to have no effect?

> and what his system clock is set to.

UTC.



-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#247121

On Sat, 09 Apr 2022 16:59:04 -0400
gene heskett <gheskett@shentel.net> wrote:

> Matches mine too Greg, so I expect thats default, but why is Roy's
> going off at about midnight?

Two of my machines have their database files dated at midnight or one
minute after.

Possibly because updatedb is run by a systemd timer, not cron.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#247122

On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote:
> Two of my machines have their database files dated at midnight or one
> minute after.
> 
> Possibly because updatedb is run by a systemd timer, not cron.

??

unicorn:~$ ls -l /var/lib/mlocate/mlocate.db
-rw-r----- 1 root mlocate 28983797 Apr  9 00:00 /var/lib/mlocate/mlocate.db

?!

unicorn:~$ less /etc/cron.daily/mlocate 
#! /bin/bash

set -e

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi
[...]

Wow.  That's incredibly annoying!

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?

Oh well.  It clearly isn't bothering me (I'm usually in bed before
midnight, though not always), so I never had to look into it.  I'm sure
someone felt it was a "good idea" to move things from perfectly normal
and well-understood crontab files into this new systemd timer crap that
nobody understands, and that I should respect their wisdom, but I don't
see the advantages at this time.

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

#247125

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

On Sat, Apr 09, 2022 at 11:59:07PM -0400, Greg Wooledge wrote:

[...]

> Oh well.  It clearly isn't bothering me (I'm usually in bed before
> midnight, though not always), so I never had to look into it.  I'm sure
> someone felt it was a "good idea" to move things from perfectly normal
> and well-understood crontab files into this new systemd timer crap that
> nobody understands, and that I should respect their wisdom, but I don't
> see the advantages at this time.

FWIW, Debian is (still) perfectly viable with SysV, something I thank
daily Debian developers for.

Cheers
-- 
t

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

#247127

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

Greg Wooledge writes:

> On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote:
> > Two of my machines have their database files dated at midnight or one
> > minute after.
> >
> > Possibly because updatedb is run by a systemd timer, not cron.

[...]

> # skip in favour of systemd timer
> if [ -d /run/systemd/system ]; then
>     exit 0
> fi
> [...]
>
> Wow.  That's incredibly annoying!

It provides a mechanism that adjusts to the init system at runtime. Maybe  
there are better ways to do it, but it seems to work OK?

> 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?

Try

# 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.

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.

> Oh well.  It clearly isn't bothering me (I'm usually in bed before
> midnight, though not always), so I never had to look into it.  I'm sure
> someone felt it was a "good idea" to move things from perfectly normal
> and well-understood crontab files into this new systemd timer crap that
> nobody understands, and that I should respect their wisdom, but I don't
> see the advantages at this time.

I think systemd tries to provide an alternative for all the `...tab` files  
that used to be the standard (/etc/inittab, /etc/crontab, /etc/fstab come to  
mind). IMHO the notable advantage over the traditional method is that on  
systemd-systems one can query all the status information with a single  
command: `systemctl status <name-of-unit>`. Similarly, the lifecycle of  
start/stop/enable/disable can all be handled by the single command  
`systemctl start/stop/enable/disable <name-of-unit>`. All stdout/stderr  
outputs available via `journalctl -u <name-of-unit>`. In theory this could  
eliminate the need to know about or remember the individual services' log  
file names.

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).

IMHO systemd's interface is not the best design-wise and in terms of its  
strange defaults, formats and names (paged output by default is one of the  
things I disable all the time, INI-derivatives are really not my favorite  
configuration syntax, binary logfiles, semantics of disable/mask can be  
confusing...). IMHO it does provide a lot of useful features that were  
missing previously, though.

YMMV
Linux-Fan

öö

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

#247129

On Sunday, 10 April 2022 05:33:53 EDT Linux-Fan wrote:
> Greg Wooledge writes:
> > On Sat, Apr 09, 2022 at 09:26:58PM -0600, Charles Curley wrote:
> > > Two of my machines have their database files dated at midnight or
> > > one
> > > minute after.
> > > 
> > > Possibly because updatedb is run by a systemd timer, not cron.
> 
> [...]
> 
> > # skip in favour of systemd timer
> > if [ -d /run/systemd/system ]; then
> > 
> >     exit 0
> > 
> > fi
> > [...]
> > 
> > Wow.  That's incredibly annoying!
> 
> It provides a mechanism that adjusts to the init system at runtime.
> Maybe there are better ways to do it, but it seems to work OK?
> 
> > 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?
> 
> Try
> 
> # 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.
> 
> 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.
> 
> > Oh well.  It clearly isn't bothering me (I'm usually in bed before
> > midnight, though not always), so I never had to look into it.  I'm
> > sure someone felt it was a "good idea" to move things from perfectly
> > normal and well-understood crontab files into this new systemd timer
> > crap that nobody understands, and that I should respect their
> > wisdom, but I don't see the advantages at this time.
> 
> I think systemd tries to provide an alternative for all the `...tab`
> files that used to be the standard (/etc/inittab, /etc/crontab,
> /etc/fstab come to mind). IMHO the notable advantage over the
> traditional method is that on systemd-systems one can query all the
> status information with a single command: `systemctl status
> <name-of-unit>`. Similarly, the lifecycle of start/stop/enable/disable
> can all be handled by the single command `systemctl
> start/stop/enable/disable <name-of-unit>`. All stdout/stderr outputs
> available via `journalctl -u <name-of-unit>`. In theory this could
> eliminate the need to know about or remember the individual services'
> log file names.
> 
> 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).
 
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...

> IMHO systemd's interface is not the best design-wise and in terms of
> its strange defaults, formats and names (paged output by default is
> one of the things I disable all the time, INI-derivatives are really
> not my favorite configuration syntax, binary logfiles, semantics of
> disable/mask can be confusing...). IMHO it does provide a lot of
> useful features that were missing previously, though.
> 
> YMMV
> Linux-Fan
> 
> öö


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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web