[SOLVED] Anacron symlinked to "true", again.

Tritonio · 2022-06-24 11:53:41

I had encountered this issue in the past and I thought it was because I did something hacky during the upgrade from the previous Devuan version. But now the same thing happened in a fresh and quite standard installation of Devuan.

I am using the graphical installer (refracta?) without EFI and the only non standard settings are that I create a separate boot partition and I encrypt the root filesystem. Everything else I think is defaults or they are language and locale related settings.

After the end of the installation, anacron is symlinked to "true" which causes, for example, the log rolling of syslog etc not to work. There's basically nothing being run by anacron but because anacron technically exists, Cron is not used a fallback either, so many scheduled things just don't run at all. Crontab entries will still run though.

Last time I had this issue I had copy-pasted a bunch of pages from this forum into a pastebin for future reference by me, here: https://pastebin.com/iGZVJShW The solution is near the end and involves removing dpkg diversions and also uninstalling live* packages.

It looks like this is a very old bug in the Refracta installer which is somehow still around? Or am I doing something wrong? If this is such a common bug I think it should be something that must be affecting many, maybe even most Devuan users without them even knowing about it.

alexkemp · 2022-06-24 17:06:44

OMG

I also used the refracta install when I first installed Devuan. There is zero else that I can think of that could have caused this:-

$ la /usr/sbin/anacron
lrwxrwxrwx 1 root root 9 Jul 21  2017 /usr/sbin/anacron -> /bin/true

Would removing anacron actually cause harm?

xinomilo · 2022-06-24 20:44:51

anacron looks good over here.. (never used refracta installer though).

but before messing up with diversions etc, did you try : `apt install --reinstall anacron` ?
and what's the output of `dpkg -S /usr/sbin/anacron` ?

alexkemp · 2022-06-25 01:12:51

$ dpkg -S /usr/sbin/anacron
diversion by live-config from: /usr/sbin/anacron
diversion by live-config to: /usr/sbin/anacron.orig.anacron
anacron: /usr/sbin/anacron

$ sudo apt install --reinstall anacron
[sudo] password for alexk: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/35.0 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 197564 files and directories currently installed.)
Preparing to unpack .../anacron_2.3-30_amd64.deb ...
Unpacking anacron (2.3-30) over (2.3-30) ...
Setting up anacron (2.3-30) ...
Processing triggers for man-db (2.9.4-2) ...

$ la /usr/sbin/anacron
lrwxrwxrwx 1 root root 9 Jul 21  2017 /usr/sbin/anacron -> /bin/true
$ la /usr/sbin/anacron.orig.anacron
-rwxr-xr-x 1 root root 38928 Feb  6  2021 /usr/sbin/anacron.orig.anacron

WTF?

golinux · 2022-06-25 02:08:34

@Tritonio and alexkemp

Answering for fsmithred who is away until next week. He knows about this. It is iitc a regression in the live installer. So just hang tight for a few days . . .

xinomilo · 2022-06-25 09:23:28

(temporary) workaround, remove live-config package if you don't need it, and reinstall anacron afterwards.

Tritonio · 2022-06-25 13:49:31

Is it possible to roll out a fix for all users that are affected by this? Most people won't even know that they have a completely broken anacron setup.

Try:

ls /etc/cron.daily

For a list of things that don't run because of this. NTP and apt related tasks are probably bad not to be running.

rolfie · 2022-06-25 15:42:43

To which package does "la" belong? My bash (Chimaera from net-install) tells me command not found.

chris2be8 · 2022-06-25 15:53:24

On my system la is an alias:

$ alias
alias l='ls -alF'
alias la='ls -A'
alias ll='ls -l'
alias ls='ls --color=auto'

Which is set in .bashrc (I don't know why it doesn't work for you though).

rolfie · 2022-06-25 15:57:52

On my Chimaera no alias is set.

Anyhow:

# ls -A /usr/sbin/anacron
/usr/sbin/anacron

Last edited by rolfie (2022-06-25 15:58:43)

alexkemp · 2022-06-25 21:56:41

I've set it up myself, as it is the listing I use most:

$ alias
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias la='ls -Al'
alias ls='ls --color=auto'

fsmithred · 2022-06-28 18:21:08

I thought I fixed this in an earlier version, but I did it wrong. To fix your installed system:

rm /usr/sbin/anacron
mv /usr/sbin/anacron.orig.anacron /usr/sbin/anacron

Getting this out to everyone might be tricky. That would include anyone who installed Refracta, Devuan Live, or any other system that has anacron installed an used refractainstaller. I could put the fix in a postinstall script in the next version, but I think the user should be warned and asked to OK it. I don't know how to program debconf and I don't really have time to figure it out right now. If anyone knows how to get a debconf dialog to run from a postinst script, please help. I can tell you what the script needs to do.

pcalvert · 2022-06-28 23:04:58

fsmithred wrote:

I could put the fix in a postinstall script in the next version, but I think the user should be warned and asked to OK it.

I don't think that's really necessary. On a live system it doesn't make sense to have anacron running. However, once the system has been installed, having anacron running is the normal and expected behavior. IMO, asking the user to OK the fix is asking for trouble since some users will likely be confused by this.

fsmithred · 2022-06-29 00:42:41

IMO, asking the user to OK the fix is asking for trouble since some users will likely be confused by this.

I agree, but I worry about messing up some edge case that I didn't think of. I will get a new version out soon.

For the record, the correct fix is

rm /usr/sbin/anacron
dpkg-divert --rename --remove /usr/sbin/anacron

alexkemp · 2022-06-29 03:04:24

Oops. Already performed your earlier fix. Hope that the earlier one actually works. Or do I need to revert that change & use dpkg-divert instead?

Does the system need restarting? What initiates /etc/cron* at startup anyway? (I've always wondered).

fsmithred · 2022-06-29 09:31:31

The second pair of commands I posted are what the installer should do. They could also be run in a live session immediately before installing the system.

Currently, the installer removes the diversion but does not rename the diverted file. To fix an installed system, you remove the symlink and rename the file. I think restarting anacron is sufficient, but a reboot would certainly work.

rm /usr/sbin/anacron
mv /usr/sbin/anacron.orig.anacron /usr/sbin/anacron
/etc/init.d/anacron restart

anacron and cron are started from init scripts. anacron checks /etc/anacrontab for what jobs it should do. (It runs the cron scripts.)

Edit: Here's the bug report https://bugs.devuan.org/cgi/bugreport.cgi?bug=682

alexkemp · 2022-06-29 14:46:57

fsmithred wrote:

I think restarting anacron is sufficient, but a reboot would certainly work.

Many thanks for such quick responses & help.

I've had to go down some very deep rabbit holes to try to answer what needs doing. God knows, SysVinit doesn't exactly make the startup sequence simple.

Personal notes:-
• I met programming in 1973 (basic on punched-cards entered into a mainframe (?) via work-authorised evening classes).
• I met computers in 1986 (Amstrad laptop running MSDOS).
• I met Linux (and the Internet) in 1998 (whilst supporting Freeserve users on FS's premium call-line).
• I used Linux on a dedicated server in 1999 for 15 years until retirement (starting with Redhat 6, I think, & then the first CentOS)
• I fell down dead (heart fibrillation) whilst at Freeserve. Consequently I often need to fully research stuff to remember it all over again, which is (at least partly) what has happened here.

tl;dr:
Read "Summing Up" at the very end of this post.
See /usr/share/doc/anacron/README.Debian
See Introduction to SysVinit runlevels & scripts
See cron.{daily,weekly,monthly} (actually run by anacron which is called by cron)
Anacron leaves messages in /var/log/syslog
Anacron is NOT a daemon & thus is never seen by the system

So, hang tightly on to your chairs as we follow Alice down the Rabbit Hole (why not listen to the YT Official Music Video as we do this, but better is the 1969 Live Version at Woodstock (Grace Slick at her best as the sun rises and JA blow every other band from the previous 8 hours into dust) (12m views on 2022-06-29)):

The sequence goes like this:-
Ⅰ Computer loads a Bootloader (grub)
Ⅱ Bootloader loads the Kernel
Ⅲ Kernel loads System V init

There is a README in /etc/init.d (hooray!) which is written by Debian & talks mostly in terms of SystemD (boo!), although sysvinit is also mentioned (hooray!):

/etc/init.d/README wrote:

Configuration of System V init under Debian GNU/Linux
Most Unix versions have a file here that describes how the scripts
in this directory work, and how the links in the /etc/rc?.d/ directories
influence system startup/shutdown.
For Debian, this information is contained in the policy manual, chapter
"System run levels and init.d scripts". The Debian Policy Manual is
available at:
http://www.debian.org/doc/debian-policy/#contents

You may perhaps not be surprised to find that the chapter mentioned above for init.d scripts does not exist. Look instead for #starting-system-services instead:
- Chapter 9. The Operating System
- Chapter 9.3. Starting system services

See the README.runlevels file shipped with sysv-rc for implementation details

(on my system exists at /usr/share/doc/sysv-rc/README.runlevels.gz):-

README.runlevels wrote:

0. Overview.
All scripts executed by the init system are located in /etc/init.d.
The directories /etc/rc?.d (? = S, 0 .. 6) contain relative links to
those scripts. These links are named S<2-digit-number><original-name>
or K<2-digit-number><original-name>.
The following runlevels are defined:
N System bootup (NONE).
S Single user mode (not to be switched to directly)
0 halt
1 single user mode
2 .. 5 multi user mode
6 reboot

Ⅳ init examines /etc/inittab to locate & run runlevel S scripts

README.runlevels wrote:

1. Boot.
rcS executes all the S* scripts in /etc/rcS.d in alphabetical
(and thus numerical) order. The first argument passed to the
executed scripts is "start". The runlevel at this point is "N" (none).

$ cat /etc/inittab
# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

$ man init
NAME
       init, telinit - process control initialization

DESCRIPTION
   Init
       Init is the parent of all processes.  Its primary role is to
       create processes from a script stored in the file
       /etc/inittab (see inittab(5)).  This file usually has entries
       which cause init to spawn gettys on each line that users
       can log in.  It also controls autonomous processes
       required by any particular system.

RUNLEVELS
       A  runlevel  is  a software configuration of the system
       which allows only a selected group of processes to exist.
       The processes spawned by init for each of these runlevels
       are defined in the /etc/inittab file.  Init can be in one of
       eight  runlevels:  0–6  and  S  (a.k.a. s).  The runlevel
       is changed by having a privileged user run telinit, which
       sends appropriate signals to init, telling it which runlevel
       to change to.

       Runlevels S, 0, 1, and 6 are reserved.  Runlevel S is used
       to initialize the system on boot.  When starting runlevel S
       (on boot) or runlevel 1 (switching from a multi-user
       runlevel) the system is entering ``single-user mode'',
       after which the current runlevel is S.  Runlevel 0 is used
       to halt the system; runlevel 6 is used to reboot the system.

       After booting through S the system automatically enters
       one of the multi-user runlevels 2 through 5, unless there
       was some problem that needs to be fixed by the
       administrator in single-user mode.  Normally after entering
       single-user mode the administrator performs maintenance
       and then reboots the system.

BOOTING
       After init is invoked as the last step of the kernel boot
       sequence, it looks for the file /etc/inittab to see if there
       is an entry of the type initdefault (see inittab(5)). The
       initdefault entry determines the initial runlevel of the
       system.  If there is no such entry (or no /etc/inittab at
       all), a runlevel must be entered at the system console.

       Runlevel S or s initialize the system and do not require
       an /etc/inittab file.

       In single user mode, /sbin/sulogin is invoked on
       /dev/console.

       When entering single user mode, init initializes the
       consoles stty settings to sane values. Clocal mode is set.
       Hardware speed and handshaking are not changed.

       When entering a multi-user mode for the first time, init
       performs the boot and bootwait entries to allow file
       systems to be mounted before users can log in.  Then all
       entries matching the runlevel are processed.

       When starting a new process, init first checks whether the
       file /etc/initscript exists. If it does, it uses this script  to
       start the process.

       Each time a child terminates, init records the fact and the
       reason it died in /var/run/utmp and /var/log/wtmp, provided
       that these files exist.

BOOTFLAGS
       It  is  possible  to  pass  a  number of flags to init from the
       boot monitor (GRUB). Init accepts the following flags:

       -s, S, single
            Single user mode boot. In this mode /etc/inittab is
            examined and the bootup rc scripts are usually run before
            the single user mode shell is started.

       1-5  Runlevel to boot into.

Ⅴ init switches to the default runlevel, running anacron & then cron + other scripts, including slim

README.runlevels wrote:

2. Going multiuser.
After the rcS.d scripts have been executed, init switches to the
default runlevel as specified in /etc/inittab, usually "2".
Init then executes the /etc/init.d/rc script which takes care of
starting the services in /etc/rc2.d.

We are finally getting close to understanding how anacron works. Here is the listing of init scripts run from rc2.d, in the order that they are run. Note that anacron is loaded early before cron:

$ la /etc/rc2.d
total 0
lrwxrwxrwx 1 root root 27 Jul 29  2020 K01speech-dispatcher -> ../init.d/speech-dispatcher
lrwxrwxrwx 1 root root 37 Nov 26  2021 README -> /usr/share/doc/sysv-rc/rc2-5.d-README
lrwxrwxrwx 1 root root 26 May 12  2018 S01console-setup.sh -> ../init.d/console-setup.sh
lrwxrwxrwx 1 root root 37 Sep 27  2021 S02pulseaudio-enable-autospawn -> ../init.d/pulseaudio-enable-autospawn
lrwxrwxrwx 1 root root 17 May 12  2018 S02rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 14 Jul 29  2020 S02sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root 15 May 12  2018 S02uuidd -> ../init.d/uuidd
lrwxrwxrwx 1 root root 15 Dec 18  2018 S03acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 17 Dec 18  2018 S03anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root 26 Jun  7  2019 S03clamav-freshclam -> ../init.d/clamav-freshclam
lrwxrwxrwx 1 root root 14 Dec 18  2018 S03cron -> ../init.d/cron
lrwxrwxrwx 1 root root 14 Dec 18  2018 S03dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 15 Dec 18  2018 S03exim4 -> ../init.d/exim4
lrwxrwxrwx 1 root root 17 Dec 18  2018 S03hddtemp -> ../init.d/hddtemp
lrwxrwxrwx 1 root root 20 Dec 18  2018 S03irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root 13 Dec 18  2018 S03ntp -> ../init.d/ntp
lrwxrwxrwx 1 root root 19 Jul 29  2020 S03rmnologin -> ../init.d/rmnologin
lrwxrwxrwx 1 root root 15 Dec 18  2018 S03rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root 23 Feb  9  2021 S03smartmontools -> ../init.d/smartmontools
lrwxrwxrwx 1 root root 22 Dec 18  2018 S04avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 19 Aug 23  2021 S04bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 Feb 26  2021 S04elogind -> ../init.d/elogind
lrwxrwxrwx 1 root root 25 Sep 27  2021 S04network-manager -> ../init.d/network-manager
lrwxrwxrwx 1 root root 14 Dec 18  2018 S04slim -> ../init.d/slim
lrwxrwxrwx 1 root root 14 Dec 18  2018 S04wicd -> ../init.d/wicd
lrwxrwxrwx 1 root root 18 Dec 18  2018 S05bootlogs -> ../init.d/bootlogs
lrwxrwxrwx 1 root root 14 Dec 18  2018 S05cups -> ../init.d/cups
lrwxrwxrwx 1 root root 22 Dec 18  2018 S05cups-browsed -> ../init.d/cups-browsed
lrwxrwxrwx 1 root root 15 Dec 18  2018 S05saned -> ../init.d/saned
lrwxrwxrwx 1 root root 18 Dec 18  2018 S06rc.local -> ../init.d/rc.local

/etc/init.d/anacron wrote:

#! /bin/sh
### BEGIN INIT INFO
# Provides: anacron
# Required-Start: $remote_fs $syslog $time
# Required-Stop: $remote_fs $syslog $time
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Run anacron jobs
# Description: The first purpose of this script is to run anacron at
# boot so that it can catch up with missed jobs. Note
# that anacron is not a daemon. It is run here just once
# and is later started by the real cron. The second
# purpose of this script is that said cron job invokes
# this script to start anacron at those subsequent times,
# to keep the logic in one place.

Ⅵ Anacron examines /etc/anacrontab to locate & run the /etc/cron.{daily,weekly,monthly} scripts

cron expects the machine that hosts it to be running 24 «» 7 «» 365
anacron is happy for it's host to take non-scheduled breaks

Thus, cron is well-fitted for use upon a non-SystemD network server, whilst anacron is better fitted for a Desktop machine.

man anacron wrote:

ANACRON(8)
NAME
anacron - runs commands periodically
DESCRIPTION
Anacron can be used to execute commands periodically, with
a frequency specified in days. Unlike cron(8), it does not
assume that the machine is running continuously. Hence, it
can be used on machines that aren't running 24 hours a day, to
control daily, weekly, and monthly jobs that are usually controlled
by cron.
When executed, Anacron reads a list of jobs from a configuration
file, normally /etc/anacrontab (see anacrontab(5)). This file
contains the list of jobs that Anacron controls. Each job entry
specifies a period in days, a delay in minutes, a unique job
identifier, and a shell command.
For each job, Anacron checks whether this job has been
executed in the last n days, where n is the period specified for
that job. If not, Anacron runs the job's shell command, after
waiting for the number of minutes specified as the delay
parameter.
After the command exits, Anacron records the date in a special
timestamp file for that job, so it can know when to execute it
again. Only the date is used for the time calculations. The
hour is not used.
When there are no more jobs to be run, Anacron exits.
If a job generates any output on its standard output or standard
error, the output is mailed to the user running Anacron (usually
root), or to the address contained by the MAILTO environment
variable in the crontab, if such exists.
Informative messages about what Anacron is doing are sent to
syslogd(8) under facility cron, priority notice. Error messages
are sent at priority error.
"Active" jobs (i.e. jobs that Anacron already decided to run and
now wait for their delay to pass, and jobs that are currently
being executed by Anacron), are "locked", so that other copies
of Anacron won't run them at the same time.
DEBIAN-SPECIFIC CONFIGURATION
On Debian-based systems, anacron will be activated hourly
every day from 07:30 local time to 23:30 local time through cron
job (on non-systemd systems where cron is installed and enabled)
or systemd timer (on systemd-based systems). On activation,
anacron will check if it missed some jobs. If yes, it will start those
jobs after a short period of time.

$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root

# These replace cron's entries
1	5	cron.daily	run-parts --report /etc/cron.daily
7	10	cron.weekly	run-parts --report /etc/cron.weekly
@monthly	15	cron.monthly	run-parts --report /etc/cron.monthly

Ⅶ Cron examines /etc/crontab to locate & run the cron scripts

Cron is used now only on non-SystemD desktops. When used together with Anacron it is changed by Debian to only run hourly, initiating anacron via /etc/cron.d/anacron (which script is what actually inspects & runs the cron.{daily,weekly,monthly} scripts).

man cron wrote:

CRON(8)
NAME
cron - daemon to execute scheduled commands (Vixie Cron)
NOTES
cron searches its spool area (/var/spool/cron/crontabs) for crontab
files (which are named after accounts in /etc/passwd); crontabs
found are loaded into memory. Note that crontabs in this directory
should not be accessed directly - the crontab command should be
used to access and update them.
cron also reads /etc/crontab, which is in a slightly different format
(see crontab(5)). In Debian, the content of /etc/crontab is
predefined to run programs under /etc/cron.hourly, /etc/cron.daily,
/etc/cron.weekly and /etc/cron.monthly.
This configuration is specific to Debian, see the note under
DEBIAN SPECIFIC below.
Additionally, in Debian, cron reads the files in the /etc/cron.d
directory. cron treats the files in /etc/cron.d as in the same way as
the /etc/crontab file (they follow the special format of that file,
i.e. they include the user field). However, they are independent
of /etc/crontab: they do not, for example, inherit environment
variable settings from it. This change is specific to Debian see the
note under DEBIAN SPECIFIC below.
Like /etc/crontab, the files in the /etc/cron.d directory are monitored
for changes. In general, the system administrator should not use
/etc/cron.d/, but use the standard system crontab /etc/crontab.
DEBIAN SPECIFIC
Debian introduces some changes to cron that were not originally
available upstream. The most significant changes introduced are:
— Support for /etc/cron.{hourly,daily,weekly,monthly} via /etc/crontab,
Support for /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and
/etc/cron.monthly is provided in Debian through the default setting of the
/etc/crontab file (see the system-wide example in crontab(5)). The
default system-wide crontab contains four tasks: run every hour, every
day, every week and every month. Each of these tasks will execute
run-parts providing each one of the directories as an argument. These
tasks are disabled if anacron is installed (except for the hourly task) to
prevent conflicts between both daemons.

$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
$ la /etc/cron.d
total 20
-rw-r--r-- 1 root root 285 May 19  2019 anacron
-rw-r--r-- 1 root root 201 Jun  7  2021 e2scrub_all
-rw-r--r-- 1 root root 712 Dec 17  2018 php
-rw-r--r-- 1 root root 102 Jun 11  2015 .placeholder
-rw-r--r-- 1 root root 190 May 12  2018 popularity-contest
$ cat /etc/cron.d/anacron
# /etc/cron.d/anacron: crontab entries for the anacron package

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 7-23 * * *   root	[ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi

Summing Up

Once Anacron is correctly installed there should be zero need to restart neither Anacron nor the System, as long as Cron is correctly installed & is running. The sequence of affairs is slightly tortuous, but goes something like this:-

Cron is initiated once per hour
Cron examines /etc/cron.d & runs the /etc/cron.d/anacron script…
…which itself runs the /etc/init.d/anacron script…
…which loads the anacron binary…
…which examines & runs all cron.{daily,weekly,monthly} scripts that need to be run

Immediately after those final scripts have been run the anacron binary unloads itself (it is not a daemon).

Perhaps the best method to test for the Cron daemon being active is the following (note that in the listing below Anacron appears as "not present", which is the result that got me started on this 3-day research & write-up in the first place!) (cron shows as "+" which means yes, it is active):-

$ service --status-all
 [ + ]  acpid
 [ ? ]  alsa-utils
 [ - ]  anacron
 [ - ]  apparmor
 [ + ]  avahi-daemon
 [ + ]  bluetooth
 [ - ]  bootlogs
 [ - ]  bootmisc.sh
 [ - ]  brightness
 [ - ]  checkfs.sh
 [ - ]  checkroot-bootclean.sh
 [ - ]  checkroot.sh
 [ - ]  clamav-freshclam
 [ - ]  console-setup.sh
 [ + ]  cron
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ + ]  cups
 [ + ]  cups-browsed
 [ + ]  dbus
 [ + ]  elogind
 [ + ]  eudev
 [ - ]  exim4
 [ - ]  hddtemp
 [ - ]  hostname.sh
 [ ? ]  hwclock.sh
 [ - ]  irqbalance
 [ - ]  keyboard-setup.sh
 [ - ]  killprocs
 [ ? ]  kmod
 [ - ]  live-config
 [ - ]  live-tools
 [ - ]  lm-sensors
 [ ? ]  mount-configfs
 [ - ]  mountall-bootclean.sh
 [ - ]  mountall.sh
 [ - ]  mountdevsubfs.sh
 [ - ]  mountkernfs.sh
 [ - ]  mountnfs-bootclean.sh
 [ - ]  mountnfs.sh
 [ + ]  network-manager
 [ ? ]  networking
 [ + ]  nfs-common
 [ - ]  nftables
 [ + ]  ntp
 [ - ]  procps
 [ - ]  pulseaudio-enable-autospawn
 [ - ]  rc.local
 [ - ]  rmnologin
 [ - ]  rpcbind
 [ - ]  rsync
 [ + ]  rsyslog

Last edited by alexkemp (2022-06-30 22:12:26)

ralph.ronnquist · 2022-06-29 23:17:52

quick note: I think your IV and V are in wrong order: init executes /etc/init.d/rcS because that's what /etc/inittab says. That file is the configuration for init.

Please continue

EDIT: Actually, you skipped over the pre-pivot stage, which is the initial bootup (adding .1 to your III) using the initrd filesystem.

The kernel begins by running its /init which is a shell script, and that script will eventually pivot the root to the "real" filesystem and exec /sbin/init. The initrd scripting is held in /usr/share/initramfs-tools which is a configuration place for building an initrd, since the actual, running initrd is the cpio package loaded from /boot into RAM by the kernel (using the initrd= parameter).

afaik most linux systems have that 2-stage boot, to allow the bootup to be programmed generically even though every actual bootup is a specific host. It's quite possible to set up the bootup for the specific host without using an initrd stage but then typically it needs a specific kernel with the right modules compiled in.

alexkemp · 2022-06-30 01:29:06

ralph.ronnquist wrote:

your IV and V are in wrong order

Many thanks - fixed.

Actually, you skipped over the pre-pivot stage

Good lord, I've skipped over so much detail that this is merely a large pamphlet rather than a multi-volume book. Which has only taken me several hours to research & write. But I take your point.

fsmithred · 2022-07-06 14:34:40

Fixed version of refractainstaller is now in ceres and will migrate down to daedalus. I'll have to pull some strings to get it into chimaera-proposed-updates. If you're in a hurry to get it, you can download it from the repo.

refractainstaller-base
https://pkgmaster.devuan.org/devuan/poo … .2_all.deb

refractainstaller-gui
https://pkgmaster.devuan.org/devuan/poo … .2_all.deb

This one will correctly remove the diversion of anacron and rename it so it runs. It also contains a postinst script, so that when you upgrade the installer to this version, it will check your system for the leftover cruft from the diversion and correct it. It does not restart anacron, so logs won't rotate until after a reboot or a manual restart of anacron.

Tritonio · 2022-07-08 16:11:09

Good news. Will there be an new Live ISO that fixes the installer?

Tritonio · 2022-09-04 22:22:53

Now that the repo key needs fixing in the ISOs, maybe it's worth including a fix for this in the new Live ISOs. :-)

Last edited by Tritonio (2022-09-04 22:23:10)

Head_on_a_Stick · 2022-09-05 06:05:55

Not sure if this is still relevant but:

fsmithred wrote:

I don't know how to program debconf and I don't really have time to figure it out right now. If anyone knows how to get a debconf dialog to run from a postinst script, please help.

You can feed debconf-set-selections with a here string (or here document if you're not using bash) containing the relevant information.

This example is for GRUB:

debconf-set-selections <<<"grub-efi-amd64 grub2/force_efi_extra_removable boolean true"

Use debconf-get-selections to find the correct syntax for each entry and use dpkg-reconfigure to bring up the interactive configuration dialogue for each package that shows all the options.

And off-topic but:

ralph.ronnquist wrote:

you skipped over the pre-pivot stage, which is the initial bootup (adding .1 to your III) using the initrd filesystem.

Devuan uses an initramfs rather than an initrd and so uses chroot instead of pivot_root.

Last edited by Head_on_a_Stick (2022-09-05 06:08:01)

fsmithred · 2022-09-05 12:38:27

Yes, new live isos are coming soon. The fixed version of the installer is currently in chimaera-proposed-updates.

To use the current isos, wget the new keyring in the live session, and install it with dpkg or gdebi before running the installer.

fsmithred · 2022-09-08 00:48:58

New live isos with new repo key and new refractainstaller with anacron fix are uploaded.

The officially official Devuan Forum!

#1 2022-06-24 11:53:41

[SOLVED] Anacron symlinked to "true", again.

#2 2022-06-24 17:06:44

Re: [SOLVED] Anacron symlinked to "true", again.

#3 2022-06-24 20:44:51

Re: [SOLVED] Anacron symlinked to "true", again.

#4 2022-06-25 01:12:51

Re: [SOLVED] Anacron symlinked to "true", again.

#5 2022-06-25 02:08:34

Re: [SOLVED] Anacron symlinked to "true", again.

#6 2022-06-25 09:23:28

Re: [SOLVED] Anacron symlinked to "true", again.

#7 2022-06-25 13:49:31

Re: [SOLVED] Anacron symlinked to "true", again.

#8 2022-06-25 15:42:43

Re: [SOLVED] Anacron symlinked to "true", again.

#9 2022-06-25 15:53:24

Re: [SOLVED] Anacron symlinked to "true", again.

#10 2022-06-25 15:57:52

Re: [SOLVED] Anacron symlinked to "true", again.

#11 2022-06-25 21:56:41

Re: [SOLVED] Anacron symlinked to "true", again.

#12 2022-06-28 18:21:08

Re: [SOLVED] Anacron symlinked to "true", again.

#13 2022-06-28 23:04:58

Re: [SOLVED] Anacron symlinked to "true", again.

#14 2022-06-29 00:42:41

Re: [SOLVED] Anacron symlinked to "true", again.

#15 2022-06-29 03:04:24

Re: [SOLVED] Anacron symlinked to "true", again.

#16 2022-06-29 09:31:31

Re: [SOLVED] Anacron symlinked to "true", again.

#17 2022-06-29 14:46:57

Re: [SOLVED] Anacron symlinked to "true", again.

Summing Up

#18 2022-06-29 23:17:52

Re: [SOLVED] Anacron symlinked to "true", again.

#19 2022-06-30 01:29:06

Re: [SOLVED] Anacron symlinked to "true", again.

#20 2022-07-06 14:34:40

Re: [SOLVED] Anacron symlinked to "true", again.

#21 2022-07-08 16:11:09

Re: [SOLVED] Anacron symlinked to "true", again.

#22 2022-09-04 22:22:53

Re: [SOLVED] Anacron symlinked to "true", again.

#23 2022-09-05 06:05:55

Re: [SOLVED] Anacron symlinked to "true", again.

#24 2022-09-05 12:38:27

Re: [SOLVED] Anacron symlinked to "true", again.

#25 2022-09-08 00:48:58

Re: [SOLVED] Anacron symlinked to "true", again.

Board footer