You are not logged in.
Did you copy-paste those errors? There is a syntax error in the 2nd (s/b '<control>O', or perhaps 'Ctrl-O', not '<constrol>O').
By the sound of it you want backports. Here my setup but remember, YMMV:
$ cat /etc/apt/sources.list | head -8
deb http://deb.devuan.org/merged chimaera main non-free contrib
deb http://deb.devuan.org/merged chimaera-security main non-free contrib
deb http://deb.devuan.org/merged chimaera-updates main non-free contrib
# changed next line following https://dev1galaxy.org/viewtopic.php?pid=38033#p38033
# deb http://deb.devuan.org/devuan chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-backports main non-free contrib
$ uname -a
Linux ng3 6.0.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1~bpo11+1 (2022-10-29) x86_64 GNU/Linux
Hi Geoff 42
It must be some other feature of your system that is preventing install of that version. I have the precise same sources.list as you, yet and have the 2.31-13+deb11u4 version for libc6 (note that my system is AMD, not intel):
$ sudo apt-cache policy
(snip)
500 http://deb.devuan.org/devuan chimaera-proposed-updates/main amd64 Packages
release v=4.0.0,o=Devuan,a=chimaera-proposed-updates,n=chimaera-proposed-updates,l=Devuan,c=main,b=amd64
origin deb.devuan.org
(snip)
$ apt search libc6 | head -n 3
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Sorting...
Full Text Search...
libc6/stable,now 2.31-13+deb11u4 amd64 [installed]
PS
I also wondered why that single line was different to all others in the wiki!
(update)
Realising that I made an error (the update you are talking of is 2.31-13+deb11u5, not u4) I changed the proposed-updates line to match all others, then re-ran the apt update that had already been ran 5 minutes before. The results were startling:
$ ~/.update
Hit:1 http://deb.devuan.org/merged chimaera InRelease
Hit:2 http://deb.devuan.org/merged chimaera-security InRelease
Hit:3 http://deb.devuan.org/merged chimaera-updates InRelease
Hit:4 https://josm.openstreetmap.de/apt alldist InRelease
Get:5 http://deb.devuan.org/merged chimaera-proposed-updates InRelease [26.6 kB]
Hit:6 http://deb.devuan.org/merged chimaera-backports InRelease
Get:7 http://deb.devuan.org/merged chimaera-proposed-updates/main amd64 Packages [70.3 kB]
Get:8 http://deb.devuan.org/merged chimaera-proposed-updates/main Translation-en [38.4 kB]
Get:9 http://deb.devuan.org/merged chimaera-proposed-updates/non-free Translation-en [10.9 kB]
Get:10 http://deb.devuan.org/merged chimaera-proposed-updates/contrib Translation-en [499 B]
Fetched 147 kB in 2s (94.0 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
10 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
libbluray2 libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 locales shim-helpers-amd64-signed shim-unsigned
10 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
(snip)
$ apt search libc6 | head -n 3
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Sorting...
Full Text Search...
libc6/stable-proposed-updates,now 2.31-13+deb11u5 amd64 [installed]
Wow! I've been missing out on a lot of updates. Thanks.
Current chimaera-BP kernel is 5.18.0.0
Ogis1975's is a reasonable question to ask.
If you get offended by the question then
That is the response of a child, not of a grown adult
No-one can ever then expect that you will take this matter seriously & responsibly
The future then will be filled with an infinite repetition of these (and other) issues, with zero fix in sight
Now yes, of course, you also get idiotic responses from entitled fools that have zero respect for the continual efforts of unpaid volunteers on their behalf. Those people do not deserve any respect, but that does not mean that Ogis1975's question is not a reasonable one to ask.
Many thanks to Ralph for his continual efforts on Devuan's behalf. It is a new venture & I fully expect bumps along the road. As long as things continually improve I have few complaints & immense gratitude for the simple fact that it is available to the world & to me.
Did you get your version from elsewhere?
No. The standard youtube-dl is also installed in the standard location. However, I first got it in the days of Debian & updates were few & far in between (today updates are never). So, I installed a second copy in /usr/local/bin and, if you look at the code in my post, that is where the update command is made. I still have youtube-dl installed, but it never updates now:
$ /usr/bin/youtube-dl --version
2021.06.06
$ /usr/local/bin/youtube-dl --version
2021.12.17
$ /usr/bin/yt-dlp --version
2022.08.19
If you only ever want to download old YT videos then you do not need yt-dlp. However, if a recent video then you do, since G changes the algorithm every month or two. Hence the need to make use of backports.
I advise you most strongly not to bother.
This is the result of a youtube-dl (local) upgrade attempt just now:
sudo /usr/local/bin/youtube-dl -U
youtube-dl is up-to-date (2021.12.17)
It has been abandoned & no longer will download most YT videos. Use yt-dlp instead (available via backports):
man yt-dlp
NAME
yt-dlp - A youtube-dl fork with additional features and patches
# …
$ yt-dlp --version
2022.08.19
Hi HoaS.
^ That output is normal for any graphical terminal emulator regardless of the init system.
This OSTechNix page reports the following for an Ubuntu 18.04 LTS server:(in text: (user command) tty => /dev/tty1)
When I read that, I saw the words “Ubuntu 18.04 LTS” & overlooked the word server.
Sure ’nuff; in xfce4-terminal:
alexk@ng3:~$ tty
/dev/pts/0
In vt01:
alexk@ng3:~$ tty
/dev/tty1
Thanks for the correction.
Added later:
I now realise that other commands within the OSTechNix page also rely on being within a VT session. As one example, the page reports that:
By default, there are 7 ttys in Linux. … The 1 to 6 ttys are command line only. The 7th tty is GUI (your X desktop session).
…
To view the total number of active virtual consoles, run: fgconsole
You can see the next unallocated virtual terminal using command: fgconsole --next-available
In xfce4-terminal:
$ fgconsole
Couldn't get a file descriptor referring to the console.
In vt01:
$ fgconsole
1
$ fgconsole --next-available
8
That confirms the simple statements within the OSTechNix page quoted at the top of this section. However, also necessary to realise that those simple statements are there to help give simple inroads to begin understanding some of the basics of this topic, whilst the topic itself is way more complex than that (as is indicated by the 64+ VTs created at init startup).
Further, lets offer a silent prayer of thanks up for the fact that Devuan has a simple sanity at it's heart, and that we are not forced to use an OS that has an eternal struggle for domination at it's heart. I spent 12 hours yesterday researching to try to discover which binaries handle the C‑A‑Fn + A‑Fn key combos. I'm a professional researcher with multiple decades experience, but could not find a definitive answer (it should not be a difficult question). What I *did* find was the way that multiple distros are beginning to make simple certainties no longer certain. An example:– The simple route back to a GUI from a VT is Alt‑F7, and that has been true within a default setup for decades. During my research I found many distros that have recently changed the default VT setup, with radical differences in the methods of return. And I'm sorry; I went through scores of websites and, because I was not looking for that precise issue, I did not record which they were.
Like a Bulldog (and also a rat), once I get my teeth into something I cannot stop biting until my teeth meet (ratchet mechanism on their jaws).
(upfront: nothing directly to do with Devuan)
Surprisingly, this topic has *everything* to do with SystemD (if only in reverse), since the virus has taken over from the kernel the process of producing Virtual Terminals (VTs), just like so much else.
In Devuan, the kernel produces a whole bunch of VTs on startup. The precise number will be a kernel setup item. For myself it seems to be 64 (see Ralph's answer), although there are also a few extra:
$ ls /dev/tty[0-9]* | wc -l
64
$ la /dev/tty*
crw-rw-rw- 1 root tty 5, 0 Aug 25 08:40 /dev/tty
crw--w---- 1 root tty 4, 0 Aug 25 08:40 /dev/tty0
crw------- 1 alexk tty 4, 1 Aug 26 18:23 /dev/tty1
crw--w---- 1 root tty 4, 10 Aug 25 08:40 /dev/tty10
…
crw--w---- 1 root tty 4, 9 Aug 25 08:40 /dev/tty9
crw-rw---- 1 root dialout 4, 64 Aug 25 08:40 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Aug 25 08:40 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Aug 25 08:40 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Aug 25 08:40 /dev/ttyS3
We now need to consider delgado's answer, and it has taken me quite some time to get the point.
When the computer is first started, the screen that appears is a VT initiated (as best as I can tell) by agetty via init:
DESCRIPTION
agetty opens a tty port, prompts for a login name and invokes the /bin/login command. It is normally invoked by init(8).
My system uses XFCE as a Desktop Manager and SLiM as a Login Manager. Therefore it is startxfce4 for me rather than startx, but the point is that an X-Session is launched which provides the GUI components in both cases, and that is comprehensively different to agetty, which is text-only.
With hindsight it is blooming obvious, but the VT produced by agetty has absolutely nothing to do with the terminal produced by xterm (or in my case, xfce-terminal) which is a GUI emulation of a text-terminal. For those that are interested in historical research, this is what it took to drive a text-terminal (aka typewriter) in the 1960s:
The main difference is that a VT does NOT have a mouse, nor history support. It is possible, though damn difficult, to install them. It is, however, important to know which of the two (VT or GUI-Terminal) you are in, because the commands to switch between VT & GUI are different depending on whether you are based within a GUI or VT screen:
VT → VT : Ctrl + Alt + F7 or, Alt + F7 (switch to VT07, etc) (Ctrl key is optional)
VT → GUI : Ctrl + Alt + F7 or, Alt + F7 (switch to VT07, etc) (Ctrl key is optional)
GUI → VT : Ctrl + Alt + F7 (switch to VT07, etc) (all 3 keys required)
By default, most systems keep 6 text VTs available (at 1-6) and one GUI at '7', so the return in a default system is Ctrl-F7. However, this can be changed (just open another X-Session) and, worse, some distributions change the setup. Yikes! This page has good info on the command to change VTs, etc. (CHVT), and make a note that the TTY command gives a different result in Devuan to SystemD distros:
$ tty
/dev/pts/0
so make a note of the pgrep -a Xorg command that ralph gave.
It seems clear, then, that it is Xorg that handles 3-finger salutes to change from the GUI to a VT, but (perhaps) agetty that handles 2-finger salutes to switch out of the VT to another VT/GUI.
Thank you delgado. That was the kind of info that I was searching for.
Whether Alt-F7 would have got me back *after* login I do not yet know.
I do now, and the answer is "yes".
These are the steps I just took:
Close down all programs.
Open JOSM
Issue (wrong for JOSM) kbd command Ctrl-Alt-F1
(screen switches to text-screen vt01, with a login prompt on screen)
Login with my user/password
Issue w & pgrep commands (see below)
Issue Alt-F7 command
(screen instantly switches back to JOSM screen)
For reference, here are the results of w & pgrep from inside TTY1:
$ w
18:23:03 up 1 day, 9:43, 2 users, load average: 0.22, 0.70, 0.87
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
alexk tty1 - 18:19 5.00s 0.15s 0.01s w
alexk :0.0 :0.0 Thu08 ?xdm? 9:43m 1.10s xfce4-session
$ pgrep -a Xorg
1899 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/slim.auth vt07
Unless someone knows what supplies Alt-F7 I guess that we are done with this question now. Thank you to everyone that responded - most helpful.
Many thanks, Ralph.
Ctl-Alt-F1 got me to a text-screen under vt07; all that was on the screen was a prompt to login. All it (appeared to) accept as input was a username, then password, although on later testing Alt-F7 did actually return me to the xfce4-session under vt07.
Trying w + pgrep just now from an ordinary terminal:
$ w
10:14:06 up 1 day, 1:34, 1 user, load average: 0.63, 0.64, 0.81
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
alexk :0.0 :0.0 Thu08 ?xdm? 7:53m 1.02s xfce4-session
$ pgrep -a Xorg
1899 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/slim.auth vt07
That result for w is exactly what I got during my dilemma after the text login for the abandoned session. It neatly explains why I could not understand which TTY the XFCE Session was running under.
Whether Alt-F7 would have got me back *after* login I do not yet know. I also do not understand why exit following login did not shut down vt01 & drop me back into the still-running vt07 session. I see from man Xorg that Xorg supplies the Ctl-Alt-Fn commands, but I also still do not know which program is supplying the Alt-Fn command. So many questions.
Edit: fixed key combos
Try Alt-F7
Reproduced the problem, and Alt-F7 worked to get me back to the logged-in GUI session at the identical place. Thank you Gregors.
The following page documents XFCE4 sessions (the use of alt-f7 is there) (and also, why it may not work):
Try Alt-F7
Why? What does it do? Where is the link to the documentation that it sits within?
Thanks for trying, Gregors, but an unreferenced reply is worthless.
These are two sites I referenced from FF:
(upfront: nothing directly to do with Devuan; everything to do with me being a prat)
Whilst working with JOSM under XFCE to make some small updates to the OSM map I hit a wrong combination of keys & found myself at a fresh text-session. I then could neither shut down that new session nor navigate back to the original xfce-session. My actual actions probably made it impossible to be able to revert to the GUI, but I wanted to know how to do that under Devuan with a XFCE session.
The key-combo needed: Shift-Alt-F1
(switch off auto-download prior to examining a large boundary-area)
The key-combo actually used: Ctl-Alt-F1
(start up & switch to TTY1)
(use of w indicated that the new session was under TTY1 & the former xfce-session was on 0:0 (whatever that is))
I cannot now remember the precise order of steps that I took, but I did try exit and startx, plus a text-login, and eventually got to a new XFCE session & used FF to research (it all seemed to be Ubuntu fixes), but nothing worked & I eventually had to shutdown & crash/burn the original GUI. Chromium managed to recover all the tabs in the former session, so that was OK.
If I ever do something as dumb as this again, how do I recover back to the original session?
Edit: fixed key combos
Please see if devuan-baseconf is installed. Let me know if it is.
$ locate avoid-systemd
/etc/apt/preferences.d/avoid-systemd
#
$ apt-cache search devuan-baseconf
devuan-baseconf - Devuan base config files
$ apt-cache showpkg devuan-baseconf
Package: devuan-baseconf
Versions:
0.6.4+devuan3.1 (/var/lib/apt/lists/deb.devuan.org_merged_dists_chimaera_main_binary-amd64_Packages) (/var/lib/dpkg/status)
Already installed. I do full-system updates daily.
In the Git README.md the curl line is secure (https) whereas in your apt command it is not (http); is that the reason for the error?
# curl -s 'https://download.opensuse.org/repositories/home:/ungoogled_chromium/Debian_Bullseye/Release.key' …
Oh. I was wondering where all your nonsense was coming from. Then I listened to the latest Rachel Maddow Highlights (Jul 25, 2022) where she was introducing Gerald LK Smith & his Christian Nationalism from the 1950s, and the way that the far right in America are newly re-introducing it, together with it's rampant racism & antisemitism, and I understood. Same old, same old again, and again.
No thanks.
The combo I found that has worked is to introduce Backports. Guaranteed not to destroy your setup. Here is my example for Chimaera (last line):
$ cat /etc/apt/sources.list
deb http://deb.devuan.org/merged chimaera main non-free contrib
deb http://deb.devuan.org/merged chimaera-security main non-free contrib
deb http://deb.devuan.org/merged chimaera-updates main non-free contrib
deb http://deb.devuan.org/devuan chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-backports main non-free contrib
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.
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!):
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:
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):-
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
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
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
#! /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.
ANACRON(8)
NAME
anacron - runs commands periodicallyDESCRIPTION
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).
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
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
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).
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'
$ 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?
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?
I found some notes that I made at the time that I thought worth adding, but could not edit the OP, so will put them here.
In terms of package repositories:–
‘main’ + ‘security’ are recommended by default for the stable release
‘updates’ are “safe to upgrade right away” for the stable release
‘proposed-updates’ are “usually safe to use” for the stable release
‘backports’ are “linked to stable dependencies” for the stable release
And to complete this little update, here is the current listing used successfully since upgrade:–
$ cat /etc/apt/sources.list
deb http://deb.devuan.org/merged chimaera main non-free contrib
deb http://deb.devuan.org/merged chimaera-security main non-free contrib
deb http://deb.devuan.org/merged chimaera-updates main non-free contrib
deb http://deb.devuan.org/devuan chimaera-proposed-updates main non-free contrib
deb http://deb.devuan.org/merged chimaera-backports main non-free contrib