Indeed ...

The poster was right.
I didn't now about refractainstaller being used by Miyo.

Now it's fixed.

Thanks for your input.

Best,

A.

The post at Dev1 that I linked to, which had the same /usr/sbin/anacron --> /bin/true and deviations apparently was not/had not been using Refractainstaller.

So something other used live-config and generated the same problem.
https://dev1galaxy.org/viewtopic.php?id=1901

That was a miyolinux system, which uses refractainstaller.

The way it's designed, the live-config change should not need to be undone as it only exists in the running live system. If you mount the filesystem inside the live-iso to look at it when it's not running, you would find that the diverted file does not exist. It gets created by live-config when the system boots.

Tsk, tsk ...  8^D!!!

Can't do everyhting.

So it seems.

Yes.

The post at Dev1 that I linked to, which had the same /usr/sbin/anacron --> /bin/true and deviations apparently was not/had not been using Refractainstaller.

So something other used live-config and generated the same problem.
https://dev1galaxy.org/viewtopic.php?id=1901

ie: this would not be specific to the refractainstaller but to how live-config is used by any application. (?) 

No.

It was ralph.ronnquist who saw it and pointed it out to me while helping me sort out the problem I was having with anacron.
https://dev1galaxy.org/viewtopic.php?pid=28663#p28663
I just observed and tried to pay attention.

A question just occurred to me: in 10 years, no one else using refractainstaller had a problem/issue with anacron?
Maybe there's something that's not working right.

ie:
I realised what was going on when I saw that my fstrim script was not logging.
If not for that, I would have never known about what was going on with anacron.
And I don't recall any system notifications warning me of anacron failures.

Not good, no?

Sure.

But it is live-config that is making a signifficant change.
No clean-up after use?
A notification of some sort?

eg:

Yes, it's working.

Thanks a lot for your input.

Best,

A.

I haven't been paying close attention to this thread.

live-config messes with anacron via the live-config script, /lib/live/config/1110-anacron which uses dpkg-divert to disable anacron. This is useful in a live-CD where everything is read-only.
This only activates when you boot into a live system, not an installed system.

Refractainstaller copies the RUNNING live system to hard drive.

You just uncovered a 10-year-old bug that I didn't know about. The installer needs to undo this during the installation.

I suspect that the right way to undo it is to use dpkg-divert.

# ls -l /usr/sbin/anacron*
lrwxrwxrwx 1 root root     9 Apr  2  2018 /usr/sbin/anacron -> /bin/true
-rwxr-xr-x 1 root root 38928 Feb  6 14:18 /usr/sbin/anacron.orig.anacron

# dpkg-divert --remove /usr/sbin/anacron
dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x
Removing 'diversion of /usr/sbin/anacron to /usr/sbin/anacron.orig.anacron by live-config'

And then to verify that it really did what it was supposed to do (but did not):

# ls -l /usr/sbin/anacron*
lrwxrwxrwx 1 root root     9 Apr  2  2018 /usr/sbin/anacron -> /bin/true
-rwxr-xr-x 1 root root 38928 Feb  6 14:18 /usr/sbin/anacron.orig.anacron

Yet dpkg-divert thinks it did the right thing:

# dpkg-divert --remove /usr/sbin/anacron
dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x
No diversion 'any diversion of /usr/sbin/anacron', none removed.

Computer, do as I say!

# mv /usr/sbin/anacron.orig.anacron /usr/sbin/anacron
# ls -l /usr/sbin/anacron*
-rwxr-xr-x 1 root root 38928 Feb  6 14:18 /usr/sbin/anacron
root@nomad:/home/phred# 

I'll reboot and see what happens.

Update: I see this in syslog for the first time after reboot. I think it's working now.

Apr  1 15:44:42 localhost anacron[1828]: Will run job `cron.daily' in 5 min.
Apr  1 15:44:42 localhost anacron[1828]: Will run job `cron.weekly' in 10 min.
Apr  1 15:44:42 localhost anacron[1828]: Will run job `cron.monthly' in 15 min.

Right.

I'll do all that and report back, hopefully marking this long thread as [Solved].

----
Edit:
Done.
No more /usr/sbin/anacron --> /bin/true

groucho@devuan:~$ ls -l /usr/sbin/anacron.orig.anacron
-rwxr-xr-x 1 root root 34832 May 19  2019 /usr/sbin/anacron.orig.anacron
groucho@devuan:~$

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

groucho@devuan:~$ ls -l /usr/sbin/anacron
lrwxrwxrwx 1 root root 20 Apr  1 11:06 /usr/sbin/anacron -> anacron.orig.anacron
groucho@devuan:~$ 

groucho@devuan:~$ 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
groucho@devuan:~$ 

I have purged it but I see that the diversion by live-config is still there.
How to go back to the 'original' pre-live-config configuration?

It seems to be working.  8^D!

groucho@devuan:~$ 
groucho@devuan:~$ sudo /usr/sbin/anacron -s -d -n -f
[sudo] password for groucho: 
Anacron 2.3 started on 2021-04-01
Job `cron.daily' locked by another anacron - skipping
Job `cron.weekly' locked by another anacron - skipping
Job `cron.monthly' locked by another anacron - skipping
Normal exit (0 jobs run)
groucho@devuan:~$ 
groucho@devuan:~$ 

----

Once done, who/where would I have to report this problem to?

Does not seem to originate inrefractainstaller-base, more like in the required live-config.
Or is it related to the bug report I linked to?

Don't think is would be a good thing just to leave it be. (?)

Thank you very much for the time and effort you put into solving this problem for me.
Really appreciate it.

Best,

A.

Once done, how should I test that everything is working properly?

One confirmation would be that your fstrim logging shows up.

A manual forced test would be like before, i.e. if live-config is uninstalled, then

sudo /usr/sbin/anacron -s -d -n -f

should be telling about running the cron.{daily,weekly,monthly} jobs.

So ...
That's where things get screwed up?

I see.

I could eventually pin it ...

Hmm ...
I think I can uninstall refracta-base as I have only ever used it from my ascii/Beowulf VM.   
That would take care of live-config and the redirection for good.

Unless live-config comes back with something else.

I think I'll do that and then use the first option you have advised.

Think that would do well as a long term solution?
Once done, how should I test that everything is working properly?

Thanks in advance,

A.

Possibly @fsmithred (who's doing refracta-base) knows something about that redirect but in any case it's wrong for your purpose.

The fix has two options:

The first option would be to change the link by:

sudo ln -sTf anacron.orig.anacron /usr/sbin/anacron

That will undo the redirect, but this then runs the risk of being undone, and the redirect comming back, if the live-config package is updated.

The second option would be to change /etc/init.d/anacron to use /usr/sbin/anacron.orig.anacron as binary; i.e., change start-stop-daemon --start command line to be

start-stop-daemon --start --exec /usr/sbin/anacron.orig.anacron -- $ANACRON_ARGS

The second option is probably a more sticky fix than changing the link, although it probably breaks if the live-config package is uninstalled.

EDIT: btw you might want to "verify" that anacron.orig.anacron is indeed the program by checking

$ md5sum /usr/sbin/anacron.orig.anacron
a16e182008f9105825af2580ab9e5ced  /usr/sbin/anacron.orig.anacron

Poking around the system I found this file: /usr/sbin/anacron.orig.anacron.
Original anacron?

Is there any other?  8^D

For /usr/sbin/anacron.orig.anacron

groucho@devuan:~$ ls -l /usr/sbin/anacron.orig.anacron
-rwxr-xr-x 1 root root 34832 May 19  2019 /usr/sbin/anacron.orig.anacron
groucho@devuan:~$ 

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

For /usr/sbin/anacron

groucho@devuan:~$ ls -l /usr/sbin/anacron
lrwxrwxrwx 1 root root 9 Dec  8  2017 /usr/sbin/anacron -> /bin/true
groucho@devuan:~$ 

groucho@devuan:~$ 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
groucho@devuan:~$ 

Then I came across this post:
https://dev1galaxy.org/viewtopic.php?id=1901

In that case (non-working anacron in ascii), the diversions by live-config from: /usr/sbin/anacron and to: /usr/sbin/anacron.orig.anacron were also present.
And /usr/bin/anacron was also a link to /bin/true.

I have live-config because of refractasnapshot-base so that is needed.

groucho@devuan:~$ aptitude why live-config
i   refractasnapshot-base Depends live-config (>= 2.0.15)
groucho@devuan:~$ 

From what I understand, it seems that either the /usr/bin/anacron link to /bin/true or the diversions could be related to a non-working anacron.

I also found this from 2013: https://bugs.launchpad.net/ubuntu/+sour … ug/1254614
Confirmed/unassigned.

What do you think?

Thanks in advance,

A.

I see.

So like you said, it is not starting.

groucho@devuan:~$ file /usr/sbin/anacron
/usr/sbin/anacron: symbolic link to /bin/true
groucho@devuan:~$ 

groucho@devuan:~$ file $(readlink -f /lib64/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-2.28.so: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f25dfd7b95be4ba386fd71080accae8c0732b711, stripped
groucho@devuan:~$ 

This is all rather puzzling.
All this time I searchig, I have seen quite a few cron/crotab issues posted.
But this one takes the prize.

How is it that things could get this way?

BTW: yesterday there was a huge file update which included the kernel. Apparently no issues.

Thanks so much for your help.

Best,

A.

Good thing.

groucho@devuan:~$ sudo /usr/sbin/anacron -s -d -n -f
[sudo] password for groucho: 
groucho@devuan:~$ 

Reports nothing, so it would seem to be anacron.

It's very short:

groucho@devuan:~$ cat /tmp/strace.log
     32311:	
     32311:	WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1.
     32311:	
     32311:	file=libc.so.6 [0];  needed by /usr/sbin/anacron [0]
     32311:	find library=libc.so.6 [0]; searching
     32311:	 search cache=/etc/ld.so.cache
     32311:	  trying file=/lib/x86_64-linux-gnu/libc.so.6
     32311:	
     32311:	file=libc.so.6 [0];  generating link map
     32311:	  dynamic: 0x00007feb40805b80  base: 0x00007feb4064b000   size: 0x00000000001c0800
     32311:	    entry: 0x00007feb4066f1b0  phdr: 0x00007feb4064b040  phnum:                 12
     32311:	
     32311:	
     32311:	calling init: /lib/x86_64-linux-gnu/libc.so.6
     32311:	
     32311:	
     32311:	initialize program: /usr/sbin/anacron
     32311:	
     32311:	
     32311:	transferring control: /usr/sbin/anacron
     32311:	
     32311:	
     32311:	calling fini: /usr/sbin/anacron [0]
     32311:	
groucho@devuan:~$ 

Looks for just one library and cache tells it where to find it.
ie: /lib/x86_64-linux-gnu/libc.so.6

groucho@devuan:~$ locate libc.so.6
/lib/i386-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6
groucho@devuan:~$ 

Must be the warning?

Thanks.

Best,

A.

sudo /usr/sbin/anacron -s -d -n -f

report nothing.

Then try the following:

sudo env LD_DEBUG=libs,files /usr/sbin/anacron -s -d -n -f >& /tmp/strace.log

... and paste somewhere

That should be a debug listing of the loading of dynamic libraries including how they are looked up in the file system.

I'll take your word for that.
I can't make heads or tails of it.

With 8Gb at hand, I never see the swap file get used.

Here it is:

groucho@devuan:~$ ls -l /lib*/ld-linux-*
lrwxrwxrwx 1 root root 32 May  1  2019 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so
groucho@devuan:~$ 

Thanks.

Best,

A.

However the "brk(NULL)" which should follow "munmap()" doesn't show up and instead the "exit_group()" showing premature exiting, and that suggests borked linking rather than out of memory; i.e., a technological mismatch with the dynamic libraries rather then a functional error.

Which libc6 do you have?

ls -l /lib*/ld-linux-*