The officially official Devuan Forum!

You are not logged in.

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

Tritonio
Member
Registered: 2022-01-09
Posts: 7  

Anacron symlinked to "true", again.

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.

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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?

Offline

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

xinomilo
Member
Registered: 2017-07-02
Posts: 259  

Re: Anacron symlinked to "true", again.

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

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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

Offline

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

golinux
Administrator
Registered: 2016-11-25
Posts: 2,574  

Re: Anacron symlinked to "true", again.

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

Offline

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

xinomilo
Member
Registered: 2017-07-02
Posts: 259  

Re: Anacron symlinked to "true", again.

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

Offline

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

Tritonio
Member
Registered: 2022-01-09
Posts: 7  

Re: Anacron symlinked to "true", again.

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.

Offline

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

rolfie
Member
Registered: 2017-11-25
Posts: 661  

Re: Anacron symlinked to "true", again.

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

Offline

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

chris2be8
Member
Registered: 2018-08-11
Posts: 146  

Re: Anacron symlinked to "true", again.

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

Offline

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

rolfie
Member
Registered: 2017-11-25
Posts: 661  

Re: Anacron symlinked to "true", again.

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)

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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'

Offline

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

fsmithred
Administrator
Registered: 2016-11-25
Posts: 2,096  

Re: Anacron symlinked to "true", again.

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.

Offline

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

pcalvert
Member
Registered: 2017-05-15
Posts: 113  

Re: Anacron symlinked to "true", again.

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.


“The goal of socialism is communism.”
— Vladimir Lenin

Offline

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

fsmithred
Administrator
Registered: 2016-11-25
Posts: 2,096  

Re: Anacron symlinked to "true", again.

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

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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

Offline

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

fsmithred
Administrator
Registered: 2016-11-25
Posts: 2,096  

Re: Anacron symlinked to "true", again.

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

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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:

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

  1. Cron is initiated once per hour

  2. Cron examines /etc/cron.d & runs the /etc/cron.d/anacron script…

  3. …which itself runs the /etc/init.d/anacron script…

  4. …which loads the anacron binary…

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

Offline

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

ralph.ronnquist
Administrator
From: Clifton Hill, Victoria, AUS
Registered: 2016-11-30
Posts: 710  

Re: Anacron symlinked to "true", again.

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 smile

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.

Online

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

alexkemp
Member
Registered: 2018-05-14
Posts: 60  

Re: Anacron symlinked to "true", again.

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.

Offline

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

fsmithred
Administrator
Registered: 2016-11-25
Posts: 2,096  

Re: Anacron symlinked to "true", again.

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.

Offline

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

Tritonio
Member
Registered: 2022-01-09
Posts: 7  

Re: Anacron symlinked to "true", again.

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

Offline

Board footer