I upgraded five machines to 15.1 nd rather late I discovered thart the contents of /etc/crom* have been deleted. What has replaced it?
I first noticed because locate was “findng” non existent files.
What have I missed
I upgraded five machines to 15.1 nd rather late I discovered thart the contents of /etc/crom* have been deleted. What has replaced it?
I first noticed because locate was “findng” non existent files.
What have I missed
Hi
These tasks have been replaced by systemd timers/services.
Can you point me at a document saying howto control this? At present it is not working as indicated by the mlocate database not eing up to date.
…not a fan of systemd which seems unnatura to me.
Malcom may not have been totally clear that “systemd-timers” is a systemd application, and like all systemd applications can be configured to load on boot thereby becoming a service.
For any systemd application,
It is generally critical to read or invoke the Unit file which is a kind of configuration file, complete not only with settings which can be modified but also states its location and included documentation. You can read any systemd Unit file by querying its status as follows for systemd-timers…
systemctl status systemd-timers
Read up on basic commands related to systemctl, journalctl and important but not used as often systemd, they’re not hard to pick up and are powerful ways for you to manage your system components.
TSU
To update your locate database, just open an elevated console and run
updatedb
Since systemd-timers is part of a default installation, even an outdated database should fine its Unit file.
If you just now installed the mlocate package, then run the above command immediately and as needed, the database should update on its own every 24 hrs.
TSU
This is not he sane as the previous system. My laptop is not on for 24hrs but anacron dealt with that. I ran updatedb by hand but this rather negates ts utility!
mlocate package is installed but the update did not happen.
Still struggling to find the control files for these things, or any comprensible documentation… I was happy with shell scripts in /etc/init.d or crontab.*
I also wonder what other crn scripts are not being run.
In Leap 15.1 there is an mlocate timer:
rpm -ql mlocate
/etc/apparmor.d
/etc/apparmor.d/usr.bin.locate
/etc/apparmor.d/usr.bin.updatedb
/etc/updatedb.conf
/usr/bin/locate
/usr/bin/updatedb
/usr/lib/systemd/system/mlocate.service
/usr/lib/systemd/system/mlocate.timer
/usr/sbin/rcmlocate
/usr/share/doc/packages/mlocate
/usr/share/doc/packages/mlocate/AUTHORS
/usr/share/doc/packages/mlocate/ChangeLog
/usr/share/doc/packages/mlocate/NEWS
/usr/share/doc/packages/mlocate/README
/usr/share/fillup-templates/sysconfig.locate
/usr/share/licenses/mlocate
/usr/share/licenses/mlocate/COPYING
/usr/share/man/man1/locate.1.gz
/usr/share/man/man5/mlocate.db.5.gz
/usr/share/man/man5/updatedb.conf.5.gz
/usr/share/man/man8/updatedb.8.gz
/var/lib/mlocate
/var/lib/mlocate/mlocate.db
Enable and start it as root:
systemctl enable mlocate.timer
systemctl start mlocate.timer
You can see, when it will be executed and if it was executed by:
systemctl list-timers --all
systemctl list-timers --all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2019-07-14 23:00:00 CEST 37min left Sun 2019-07-14 22:00:28 CEST 21min ago snapper-timeline.timer snapper-timeline.service
Mon 2019-07-15 00:00:00 CEST 1h 37min left Mon 2019-07-08 00:00:09 CEST 6 days ago btrfs-balance.timer btrfs-balance.service
Mon 2019-07-15 00:00:00 CEST 1h 37min left Mon 2019-07-08 00:00:09 CEST 6 days ago fstrim.timer fstrim.service
Mon 2019-07-15 00:00:00 CEST 1h 37min left Sun 2019-07-14 00:00:28 CEST 22h ago logrotate.timer logrotate.service
Mon 2019-07-15 00:00:00 CEST 1h 37min left Sun 2019-07-14 00:00:28 CEST 22h ago mandb.timer mandb.service
Mon 2019-07-15 00:00:00 CEST 1h 37min left Sun 2019-07-14 00:00:28 CEST 22h ago mlocate.timer mlocate.service
Mon 2019-07-15 00:38:47 CEST 2h 16min left Sun 2019-07-14 00:20:50 CEST 22h ago backup-rpmdb.timer backup-rpmdb.service
Mon 2019-07-15 01:21:26 CEST 2h 59min left Sun 2019-07-14 01:55:28 CEST 20h ago check-battery.timer check-battery.service
Mon 2019-07-15 01:35:23 CEST 3h 13min left Sun 2019-07-14 01:53:28 CEST 20h ago backup-sysconfig.timer backup-sysconfig.service
Mon 2019-07-15 13:46:28 CEST 15h left Sun 2019-07-14 13:46:28 CEST 8h ago snapper-cleanup.timer snapper-cleanup.service
Mon 2019-07-15 13:51:28 CEST 15h left Sun 2019-07-14 13:51:28 CEST 8h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2019-08-01 00:00:00 CEST 2 weeks 3 days left Mon 2019-07-01 00:00:11 CEST 1 weeks 6 days ago btrfs-scrub.timer btrfs-scrub.service
For those reading here who may also be using GNOME.
Being NON-Technical, long term GNOME user was puzzled when chron failing to update time, took a while till re-read Manual book.opensuse.reference_color_en.pdf how GNOME now uses chronyd for time.
paulparker@linux-die5:~> **sudo systemctl status chronyd**
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2019-07-12 06:52:11 AEST; 3 days ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Main PID: 1112 (chronyd)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/chronyd.service
└─1112 /usr/sbin/chronyd
Jul 12 06:52:10 linux-die5 systemd[1]: Starting NTP client/server...
Jul 12 06:52:11 linux-die5 chronyd[1112]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SECHASH -SIGND +ASYNCDNS +IPV6 -DEBU>
Jul 12 06:52:11 linux-die5 chronyd[1112]: Frequency -12.992 +/- 0.238 ppm read from /var/lib/chrony/drift
Jul 12 06:52:11 linux-die5 systemd[1]: Started NTP client/server.
Jul 12 06:52:25 linux-die5 chronyd[1112]: Selected source 144.48.166.166
Jul 12 06:53:32 linux-die5 chronyd[1112]: Selected source 27.124.125.250
Jul 12 06:55:41 linux-die5 chronyd[1112]: Selected source 203.14.0.250
paulparker@linux-die5:~>
paulparker@linux-die5:~> **systemctl list-timers --all**NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2019-07-15 08:00:00 AEST 2min 30s left Mon 2019-07-15 07:00:00 AEST 57min ago snapper-timeline.timer snapper-timeline.service
Tue 2019-07-16 00:00:00 AEST 16h left Mon 2019-07-15 00:00:00 AEST 7h ago logrotate.timer logrotate.service
Tue 2019-07-16 00:00:00 AEST 16h left Mon 2019-07-15 00:00:00 AEST 7h ago mandb.timer mandb.service
Tue 2019-07-16 00:00:51 AEST 16h left Mon 2019-07-15 01:26:51 AEST 6h ago backup-sysconfig.timer backup-sysconfig.service
Tue 2019-07-16 01:24:35 AEST 17h left Mon 2019-07-15 00:41:51 AEST 7h ago backup-rpmdb.timer backup-rpmdb.service
Tue 2019-07-16 01:34:38 AEST 17h left Mon 2019-07-15 01:43:41 AEST 6h ago check-battery.timer check-battery.service
Tue 2019-07-16 07:04:41 AEST 23h left Mon 2019-07-15 07:04:41 AEST 52min ago snapper-cleanup.timer snapper-cleanup.service
Tue 2019-07-16 07:07:51 AEST 23h left Mon 2019-07-15 07:07:51 AEST 49min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2019-07-22 00:00:00 AEST 6 days left Mon 2019-07-15 00:00:00 AEST 7h ago btrfs-balance.timer btrfs-balance.service
Mon 2019-07-22 00:00:00 AEST 6 days left Mon 2019-07-15 00:00:00 AEST 7h ago fstrim.timer fstrim.service
Thu 2019-08-01 00:00:00 AEST 2 weeks 2 days left Mon 2019-07-01 05:51:08 AEST 2 weeks 0 days ago btrfs-scrub.timer btrfs-scrub.service
11 timers listed.
paulparker@linux-die5:~>
paulparker@linux-die5:~> **sudo zypper info chrony**Loading repository data...
Reading installed packages...
Information for package chrony:
-------------------------------
Repository : Main Repository
Name : chrony
Version : 3.2-lp151.8.6
Arch : x86_64
Vendor : openSUSE
Installed Size : 442.4 KiB
Installed : Yes
Status : up-to-date
Source package : chrony-3.2-lp151.8.6.src
Summary : System Clock Synchronization Client and Server
Description :
Chrony is an implementation of the Network Time Protocol (NTP). It can
synchronize the system clock with NTP servers, reference clocks (e.g. a
GPS receiver), and manual input using wristwatch and keyboard. It can
also operate as an NTPv4 (RFC 5905) server and peer to provide a time
service to other computers in the network.
Chrony consists of two programs: chronyd and chronyc.
Chronyd is a daemon which runs in the background on the system. It
obtains measurements of the system clock’s offset relative to time
servers on other systems via the network and adjusts the system time
accordingly. For isolated systems, the user can periodically enter the
correct time by hand (using chronyc). In either case, chronyd
determines the rate at which the computer gains or loses time, and
compensates for this. Chronyd can act as either a client or a server.
Chronyc provides a user interface to chronyd for monitoring its
performance and configuring various settings. It can do so while
running on the same computer as the chronyd instance it is controlling
or a different computer.
paulparker@linux-die5:~>
Comprehensible documentation: man systemd.unit ; man systemd.timer
erlangen:~ # systemctl list-unit-files mlocate*
UNIT FILE STATE
mlocate.service static
mlocate.timer enabled
2 unit files listed.
erlangen:~ #
The timer runs the service:
erlangen:~ # systemctl status mlocate.timer
● mlocate.timer - Daily locate database update
Loaded: loaded (/usr/lib/systemd/system/mlocate.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Fri 2019-07-12 22:02:35 CEST; 2 days ago
Trigger: Tue 2019-07-16 00:00:00 CEST; 15h left
Docs: man:updatedb
Jul 12 22:02:35 erlangen systemd[1]: Started Daily locate database update.
erlangen:~ # systemctl status mlocate.service
● mlocate.service - Update locate database
Loaded: loaded (/usr/lib/systemd/system/mlocate.service; static; vendor preset: disabled)
Active: inactive (dead) since Mon 2019-07-15 05:13:56 CEST; 3h 3min ago
Docs: man:updatedb
Process: 32713 ExecStart=/bin/sh -c chown -R ${RUN_UPDATEDB_AS}:root /var/lib/mlocate && su ${RUN_UPDATEDB_AS} -c /usr/bin/updatedb (code=exited, status=0/SUCCESS)
Main PID: 32713 (code=exited, status=0/SUCCESS)
Jul 15 05:13:54 erlangen systemd[1]: Starting Update locate database...
Jul 15 05:13:54 erlangen su[32713]: (to nobody) root on none
Jul 15 05:13:54 erlangen su[32713]: pam_unix(su:session): session opened for user nobody by (uid=0)
Jul 15 05:13:56 erlangen systemd[1]: mlocate.service: Succeeded.
Jul 15 05:13:56 erlangen systemd[1]: Started Update locate database.
erlangen:~ #
An alternative to the “systemd” man pages is: <https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.systemd.html>.
BTW: The /etc/cron.daily|hourly|weekly|monthly directories still exist and, they’re still functional and, they’re installed by the “filesystem” package – both Leap 15.0 and Leap 15.1 use the same version of this package …
Yes!
And I wouldn’t expect that they would disappear any time in the forseeable future, even modern components are often written as cronjobs… IIRC examples are snapper, clearing the various “tmp” files.
But the initial issue is that in an upgrade cronjobs weren’t migrated…
Which is a risk if not a likelihood if you modify the default files that might list cronjobs but should not be an issue if the cronjobs were described in a separate custom file.… So if the cronjobs are set up again, that’s a hint how to make your work persist through upgrades.
TSU