Posts by Altoid

Altoid · Off-topic

Hello:

I know that it's 01/04 today (at least here) but ...

Tim Anderson @TheRegister wrote:

Version 248 of systemd, a widely used system and service manager for Linux, adds a feature called system extension images, designed to allow system files to be added, or appear to be added, even on read-only file systems.

https://www.theregister.com/2021/04/01/systemd_248/

For fuck's sake, does the shit never stop flowing?

Best,

A.

Altoid · Installation

Hello:

Altoid wrote:

All this time I searching ...
How is it that things could get this way?

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.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

The warning can be ignored.

I see.

ralph.ronnquist wrote:

... expected to see the output "Anacron 2.3 started on 2021-04-01" after the "transferring control" ...

So like you said, it is not starting.

ralph.ronnquist wrote:

... which architecture do you have?

groucho@devuan:~$ uname -a
Linux devuan 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
groucho@devuan:~$

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.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

Right; that's the right one...

Good thing.

ralph.ronnquist wrote:

... verify that the problem is with anacron, by seeing ...
sudo /usr/sbin/anacron -s -d -n -f[
... report nothing.

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.

ralph.ronnquist wrote:

... try the following:
sudo env LD_DEBUG=libs,files /usr/sbin/anacron -s -d -n -f >& /tmp/strace.log
... and paste somewhere

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

ralph.ronnquist wrote:

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

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.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... your /usr/sbin/anacron dies before it starts ...

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

ralph.ronnquist wrote:

... at the point where it should allocate memory.

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

ralph.ronnquist wrote:

... premature exiting, and that suggests borked linking rather than out of memory; i.e., a technological mismatch with the dynamic libraries ...

ralph.ronnquist wrote:

Which libc6 do you have?
ls -l /lib*/ld-linux-*

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.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

| | |-grep,13714 --color=always -A 3 anacron
that was the grepping itself ...

ralph.ronnquist wrote:

Try again with

sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

Hmm ...
I think you are on to something here:

groucho@devuan:~$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
[sudo] password for groucho: 
Starting /usr/sbin/anacron...
groucho@devuan:~$

ralph.ronnquist wrote:

... and verify that that only gives that same one line of output...

It doesn't.

ralph.ronnquist wrote:

Check then at end of /var/log/syslog to see if there's an explanation.

Let's see:

groucho@devuan:~$ tail -7 /var/log/syslog
Mar 31 20:35:01 devuan CRON[15101]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 31 20:45:01 devuan CRON[16636]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 31 20:55:01 devuan CRON[18468]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 31 21:00:01 devuan CRON[19233]: (root) CMD (timeshift --check --scripted)
Mar 31 21:00:01 devuan crontab[19266]: (root) LIST (root)
Mar 31 21:00:01 devuan crontab[19267]: (root) LIST (root)
Mar 31 21:05:01 devuan CRON[20031]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
groucho@devuan:~$

ralph.ronnquist wrote:

Following that we'll need to go deep diving ...

Right.

groucho@devuan:~$ sudo strace -f start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f >& /tmp/strace.log 
groucho@devuan:~$

Done.

ralph.ronnquist wrote:

... will be long as it includes all the system calls by the execution, so the best is if you can paste it ...

Done: -> https://pastebin.com/5Mry6Pm7

ralph.ronnquist wrote:

... there's something just a little bit off on your system and this will give as a haystack to look in.

It was ascii and I think I upgraded when Beowulf a day or two after 3.1.0 was announced.

Let me know if you need more data/tests.

Thanks in advance.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

My test showed nothing ...

Thanks for the effort.

ralph.ronnquist wrote:

... realized that your forced running only resulted in a "Starting..." message, and not like the expected

$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f [sudo]
password for ralph:
Starting /usr/sbin/anacron...
Anacron 2.3 started on 2021-04-01
Will run job `cron.daily'
Will run job `cron.weekly'
Will run job `cron.monthly'
Jobs will be executed sequentially
Job `cron.daily' started
Job `cron.daily' terminated
Job `cron.weekly' started
Job `cron.weekly' terminated
Job `cron.monthly' started
Job `cron.monthly' terminated
Normal exit (3 jobs run)

ralph.ronnquist wrote:

Which package version do you have?
apt-cache policy anacron |& grep Installed

groucho@devuan:~$ apt-cache policy anacron |& grep Installed
  Installed: 2.3-28
groucho@devuan:~$

ralph.ronnquist wrote:

Is there an anacron running?
pstree -ap | grep -A 3 anacron

Yes.

groucho@devuan:~$ pstree -ap | grep -A 3 anacron
  |   |   |-grep,13714 --color=always -A 3 anacron
  |   |   `-pstree,13713 -ap
  |   |-{xfce4-terminal},13572
  |   `-{xfce4-terminal},13573
groucho@devuan:~$

Thanks,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... re logrotate.conf since 18 and 25 are duplicates you might want to compare with the lines before those.

Let's see:

groucho@devuan:~$ cat /etc/logrotate.conf
1 # see "man logrotate" for details
2 # rotate log files weekly
3 weekly
4 
5 # keep 4 weeks worth of backlogs
6 rotate 4
7 
8 # create new (empty) log files after rotating old ones
9 create
10 
11 # uncomment this if you want your log files compressed
12 compress
13
14 # packages drop log rotation information into this directory
15 include /etc/logrotate.d
16
17 # no packages own wtmp, or btmp -- we'll rotate them here
18 /var/log/wtmp {          
19     missingok
20     monthly
21     create 0664 root utmp     <--- | x |
22     rotate 1
23  }
24
25 /var/log/btmp {          
26     missingok
27     monthly
28     create 0660 root utmp     <--- | x |
29    rotate 1
30 }
31 
32 # system-specific logs may be configured here
groucho@devuan:~$

Line 21 -> create 0664 root utmp
Line 28 -> create 0660 root utmp

These two lines are identical save for the permissions the files are assigned when created.
Can't create two files with the same name, no?

man utmp indicates that these are use and login records.
From what I understand, wtmp has information about who is using the systen and wtmp records all login and logouts.

groucho@devuan:~$ less /var/log/wtmp
"/var/log/wtmp" may be a binary file.  See it anyway? 
groucho@devuan:~$

groucho@devuan:~$ less /var/log/btmp
/var/log/btmp: Permission denied
groucho@devuan:~$

groucho@devuan:~$ sudo less /var/log/btmp
[sudo] password for groucho: 
"/var/log/btmp" may be a binary file.  See it anyway? 
groucho@devuan:~$

Thanks for your input.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

You seem to mix up non-root and root user ...

Not surprised.
Sorry.

ralph.ronnquist wrote:

... the user's cron jobs ar run as that user ...

I see ...

ralph.ronnquist wrote:

... only root's cron jobs are run as root.

ralph.ronnquist wrote:

The anacron problem is not that problem, since it gets run by root.

Right.

Any tests I could run to help?

Thank you for your input.

Best,

A.

Altoid · Installation

Hello:

Altoid wrote:

But the problem is that /etc/cron.whatever is not running the scripts as expected.

Maybe not?
Maybe it is just not getting logged?

To try to understand a bit more, I tried this:

Instead of a script to run and log fstrim I tried to run and log something much simpler and (in principle) fool proof.

This is the script:

groucho@devuan:/etc/cron.daily$ cat testing
#!/bin/sh
# test to write to /var/log
# called from crontab 
#
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/testing.log
echo "On $(date -R):" >> $LOG
/bin/uname -a >> "$LOG" 2>&1
groucho@devuan:/etc/cron.daily$

[root@devuan ~]# /etc/cron.daily/testing
[root@devuan ~]#

Runs as root and logs as expected.

groucho@devuan:/var/log$ cat /var/log/testing.log
On Wed, 31 Mar 2021 18:25:00 -0300:
Linux devuan 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
groucho@devuan:/var/log$

The I opened crontab and added an entry to run that same script once a minute:

groucho@devuan:/var/log$ crontab -l
--- snip ---
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# ---
# test
# ---

*  *  *  *  *  /etc/cron.daily/testing

# ---
--- snip ---

This probably gets executed but it does not get logged:

From groucho@devuan Wed Mar 31 18:32:01 2021
Envelope-to: groucho@devuan
Delivery-date: Wed, 31 Mar 2021 18:32:01 -0300
From: root@devuan (Cron Daemon)
To: groucho@devuan
Subject: Cron <groucho@devuan> /etc/cron.daily/testing
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/home/groucho>
X-Cron-Env: <LOGNAME=groucho>
Date: Wed, 31 Mar 2021 18:32:01 -0300

/etc/cron.daily/testing: 7: /etc/cron.daily/testing: cannot create /var/log/testing.log: Permission denied
/etc/cron.daily/testing: 8: /etc/cron.daily/testing: cannot create /var/log/testing.log: Permission denied

I think there is a reason that prevents writing to /var/log.
Don't have a clue as to what it can be.

/var/log/testing.log is under root ownership, just like /var/log/trim.log

groucho@devuan:/var/log$ ls -l /var/log | grep testing
-rw-r--r-- 1 root        root       120 Mar 31 18:25 testing.log
groucho@devuan:/var/log$ 
groucho@devuan:/var/log$ ls -l /var/log | grep trim.log
-rw-r--r-- 1 root        root         0 Mar 31 16:56 trim.log
groucho@devuan:/var/log$

Any idea?

Thanks in advance,

A.

Altoid · Installation

Hello:

Head_on_a_Stick wrote:

... run-parts using root rather than your normal user.

Will do.

Head_on_a_Stick wrote:

Root should have the /sbin directories in PATH, unlike your normal user.

Yes.

Here it is:

[root@devuan ~]# run-parts --verbose /etc/cron.daily
run-parts: executing /etc/cron.daily/0anacron
run-parts: executing /etc/cron.daily/apt-compat
run-parts: executing /etc/cron.daily/apt-show-versions
run-parts: executing /etc/cron.daily/aptitude
run-parts: executing /etc/cron.daily/bsdmainutils
run-parts: executing /etc/cron.daily/chkrootkit
run-parts: executing /etc/cron.daily/cracklib-runtime
run-parts: executing /etc/cron.daily/dev-fstrim
run-parts: executing /etc/cron.daily/dpkg
run-parts: executing /etc/cron.daily/exim4-base
run-parts: executing /etc/cron.daily/logrotate

error: /etc/logrotate.conf:18 duplicate log entry for /var/log/wtmp
error: /etc/logrotate.conf:25 duplicate log entry for /var/log/btmp
run-parts: /etc/cron.daily/logrotate exited with return code 1

run-parts: executing /etc/cron.daily/man-db
run-parts: executing /etc/cron.daily/mlocate
run-parts: executing /etc/cron.daily/passwd
run-parts: executing /etc/cron.daily/rkhunter
run-parts: executing /etc/cron.daily/sysstat
[root@devuan ~]#

Only errors were with logrotate.

groucho@devuan:~$ cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here
groucho@devuan:~$

logrotate.conf - lines 17 to 30:

17 # no packages own wtmp, or btmp -- we'll rotate them here
18 /var/log/wtmp {             <--- | x |
19     missingok
20     monthly
21     create 0664 root utmp
22     rotate 1
23 }
24
25 /var/log/btmp {             <--- | x |
26     missingok
27     monthly
28     create 0660 root utmp
29     rotate 1
30 }

No idea what the error is.

But the problem is that /etc/cron.whatever is not running the scripts as expected.
https://dev1galaxy.org/viewtopic.php?pid=28617#p28617
and
https://dev1galaxy.org/viewtopic.php?pid=28624#p28624

Thanks so much for your input.

Best,

A.

Altoid · Installation

Hello:

This morning I woke up too early.
Decided to have another look.

One thing that gnaws at me is that the problem seems (?) to be circumscribed to the scripts run in /etc/cron.whatever.
So I started by looking at those.

/etc/cron.hourly has nothing to run.
/etc/cron.daily has these 16 scripts:

groucho@devuan:~$ ls -1 /etc/cron.daily
0anacron
apt-compat
apt-show-versions
aptitude
bsdmainutils
chkrootkit
cracklib-runtime
dev-fstrim
dpkg
exim4-base
logrotate
man-db
mlocate
passwd
rkhunter
sysstat
groucho@devuan:~$

I ran run-parts --verbose /etc/cron.daily and looked at what was going on:

1. 0anacron

groucho@devuan:~$ /etc/cron.daily/0anacron
/etc/cron.daily/0anacron: 12: /etc/cron.daily/0anacron: anacron: not found
groucho@devuan:~$

2. apt-compat

run-parts: executing /etc/cron.daily/apt-compat
/usr/lib/apt/apt.systemd.daily: 320: /usr/lib/apt/apt.systemd.daily: cannot create /var/lib/apt//daily_lock: Permission denied
run-parts: /etc/cron.daily/apt-compat exited with return code 2

3. apt-show-versions

acetoneiso:amd64/beowulf 2.4-3 uptodate
--- snip ---
zstd:i386 not installed

4. /etc/cron.daily/aptitude

cp: cannot create regular file 'aptitude.pkgstates': Permission denied
touch: cannot touch 'aptitude.pkgstates': Permission denied
savelog: could not touch aptitude.pkgstates
run-parts: /etc/cron.daily/aptitude exited with return code 4

5. bsdmainutils

bsdmainutils

6. chkrootkit

chkrootkit

7. cracklib-runtime

cracklib-runtime

8. dev-fstrim

/etc/cron.daily/dev-fstrim: 7: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.daily/dev-fstrim: 8: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.daily/dev-fstrim exited with return code 2

9. dpkg

cp: cannot create regular file 'dpkg.arch': Permission denied
touch: cannot touch 'dpkg.arch': Permission denied
savelog: could not touch dpkg.arch
cp: cannot create regular file 'dpkg.status': Permission denied
touch: cannot touch 'dpkg.status': Permission denied
savelog: could not touch dpkg.status
cp: cannot create regular file 'dpkg.diversions': Permission denied
touch: cannot touch 'dpkg.diversions': Permission denied
savelog: could not touch dpkg.diversions
cp: cannot create regular file 'dpkg.statoverride': Permission denied
touch: cannot touch 'dpkg.statoverride': Permission denied
savelog: could not touch dpkg.statoverride
touch: cannot touch 'alternatives.tar': Permission denied
savelog: could not touch alternatives.tar
run-parts: /etc/cron.daily/dpkg exited with return code 4

10. exim4-base

/etc/cron.daily/exim4-base: 27: /etc/cron.daily/exim4-base: exim4: not found
/etc/cron.daily/exim4-base: 90: cd: can't cd to /db
run-parts: /etc/cron.daily/exim4-base exited with return code 1

11. logrotate

error: /etc/logrotate.conf:18 duplicate log entry for /var/log/wtmp
error: /etc/logrotate.conf:25 duplicate log entry for /var/log/btmp
error: error creating output file /var/lib/logrotate/status.tmp: Permission denied
run-parts: /etc/cron.daily/logrotate exited with return code 1

12. man-db

/etc/cron.daily/man-db: 27: /etc/cron.daily/man-db: start-stop-daemon: not found
run-parts: /etc/cron.daily/man-db exited with return code 127

13. mlocate

flock: cannot open lock file /run/mlocate.daily.lock: Permission denied
run-parts: /etc/cron.daily/mlocate exited with return code 66

14. passwd

cp: cannot create regular file 'passwd.bak': Permission denied
cp: cannot create regular file 'group.bak': Permission denied
cp: cannot open '/etc/shadow' for reading: Permission denied
cp: cannot open '/etc/gshadow' for reading: Permission denied
run-parts: /etc/cron.daily/passwd exited with return code 1

15. rkhunter

rkhunter

16. sysstat

sysstat

Starting with the first script: 0anacron

groucho@devuan:~$ cat /etc/cron.weekly/0anacron
#!/bin/sh
#
# anacron's cron script
#
# This script updates anacron time stamps. It is called through run-parts
# either by anacron itself or by cron.
#
# The script is called "0anacron" to assure that it will be executed
# _before_ all other scripts.

test -x /usr/sbin/anacron || exit 0
anacron -u cron.weekly
groucho@devuan:~$

cron.weekly runs it, no doubt.

Step by step:

groucho@devuan:~$ test -x /usr/sbin/anacron || exit 0
groucho@devuan:~$

groucho@devuan:~$ anacron -u cron.weekly
bash: anacron: command not found
groucho@devuan:~$

But ...

groucho@devuan:~$ /usr/sbin/anacron -u cron.weekly
groucho@devuan:~$

I think the problem may (?) be related to PATH.
I'll experiment a bit and get back.

Edit:

I edited /etc/cron.daily/0anacron thus: anacron -u cron.daily --> /usr/sbin/anacron -u cron.daily

Now, running run-parts --verbose /etc/cron.daily does not give me an error for the 0anacron script:

groucho@devuan:~$ run-parts --verbose /etc/cron.daily
run-parts: executing /etc/cron.daily/0anacron
run-parts: executing /etc/cron.daily/apt-compat
/usr/lib/apt/apt.systemd.daily: 320: /usr/lib/apt/apt.systemd.daily: cannot create /var/lib/apt//daily_lock: Permission denied
run-parts: /etc/cron.daily/apt-compat exited with return cod 2
--- snip ---
groucho@devuan:~$

Suggestions?

Thanks in advance,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

I keep my apparmor purged.

I have disabled it at boot with apparmor=0:

groucho@devuan:~$ sudo dmesg | grep  AppArmor
[    0.327253] AppArmor: AppArmor disabled by boot time parameter
groucho@devuan:~$

I got rid of everything and had a particularly hard time with a hidden file in the apparmor cache directory.
rmdir would not remove the directory because it was not empty.
Even running rmdir with --ignore-fail-on-non-empty would not do.
It did not complain but surprisingly enough, did not remove the directory.

I never imagined a cache directory with a hidden file called .features. 8^/

Uninstalling apparmor did not get rid of /etc/apparmor.d/* which I had to do by hand.
Must be profiles added by other applications.

There's also apparmor files in other locations:

groucho@devuan:~$ locate apparmor
/lib/x86_64-linux-gnu/libapparmor.so.1
/lib/x86_64-linux-gnu/libapparmor.so.1.6.0
/usr/share/doc/libapparmor1
/usr/share/doc/libapparmor1/changelog.Debian.gz
/usr/share/doc/libapparmor1/copyright
/usr/share/lintian/overrides/libapparmor1
/usr/src/linux-headers-4.19.0-14-amd64/include/config/default/security/apparmor.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/bootparam
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/hash
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/hash.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/bootparam/value.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/hash/default.h
/var/lib/dpkg/info/libapparmor1:amd64.list
/var/lib/dpkg/info/libapparmor1:amd64.md5sums
/var/lib/dpkg/info/libapparmor1:amd64.shlibs
/var/lib/dpkg/info/libapparmor1:amd64.symbols
/var/lib/dpkg/info/libapparmor1:amd64.triggers
groucho@devuan:~$

I assume that the one in /usr/src/linux-headers-4.19.0-14-amd64 should stay.
And the rest?

ralph.ronnquist wrote:

I would purge selinux too had it been possible; it stays disabled.

How to check it is effectively disabled?

ralph.ronnquist wrote:

... might want to try changing /etc/default/anacron to say
ANACRON_RUN_ON_BATTERY_POWER=yes
just for the possibility that anacron misreads something.

Right.

ralph.ronnquist wrote:

Then, you might try, as root, a manual run to see if it says something
# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d
and then even a forced run ignoring date stamping
# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

Will do and report back.

Edit 1:
Done.
This is the result.

groucho@devuan:~$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d
[sudo] password for groucho: 
Starting /usr/sbin/anacron...
groucho@devuan:~$

groucho@devuan:~$ 
groucho@devuan:~$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
Starting /usr/sbin/anacron...
groucho@devuan:~$

ralph.ronnquist wrote:

... running out of ideas ...

Imagine me.

ralph.ronnquist wrote:

I've set up an anacron test myself now and we'll see ....

Edit 2:

I've just noticed something in the forced cron.weekly run:

groucho@devuan:~$ pgrep -a run-parts
groucho@devuan:~$ run-parts --verbose /etc/cron.weekly
run-parts: executing /etc/cron.weekly/0anacron
/etc/cron.weekly/0anacron: 12: /etc/cron.weekly/0anacron: anacron: not found
run-parts: /etc/cron.weekly/0anacron exited with return code 127

run-parts: executing /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.weekly/dev-fstrim exited with return code 2

run-parts: executing /etc/cron.weekly/man-db
/etc/cron.weekly/man-db: 28: /etc/cron.weekly/man-db: start-stop-daemon: not found
run-parts: /etc/cron.weekly/man-db exited with return code 127

run-parts: executing /etc/cron.weekly/rkhunter    <----    
groucho@devuan:~$

ie: no not found, Permission denied or return code nnn for run-parts: executing /etc/cron.weekly/rkhunter.

I'm also not finding an entry in /var/log/auth.log for the denied instance.

Thank you so much for taking the time to debug this.
Much appreciated.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... looks like the "normal" installed files.

Good thing then.

ralph.ronnquist wrote:

... use apparmor ...

Not really ...

It came along with my update from ascii to Beowulf and I have been meaning to see if it is useful in any way.
I've read a couple of posts here at Dev1 noting that it is not worth having.

In ascii, dmesg infromed that it was disabled.
There must have been a reason for that.

ralph.ronnquist wrote:

... or selinux?

No.
But there are three libraries installed.
Two of them 'automatic'.

groucho@devuan:~$ apt list | grep -i selinux | grep -i installed

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libselinux1-dev/stable,now 2.8-1+b1 amd64 [installed,automatic]
libselinux1/stable,now 2.8-1+b1 amd64 [installed]
libselinux1/stable,now 2.8-1+b1 i386 [installed,automatic]
groucho@devuan:~$

As to why the libselinux libraries are there, I have to dig some with aptitude why and see.
If they are not necessary, I'd rather remove them.

eg: like the absurd 512x512 / 256x256 icons I got rid of.
Just whose bright idea was that?
I should have made a note of how much they weighed.

ralph.ronnquist wrote:

Either one can do ugly things.

Well, it 's decided then.
I will now remove/purge apparmor.
Hopefully without ill effects.

Please let me know which tests I should run to see if there's any change afetr apparmor is gone.

I have noticed that all the scripts which run from crontab apparently do so without issues.

groucho@devuan:~$ crontab -l

# For details see man 4 crontabs
#
# 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
#
#
# --------------------------------------------------------------------------------------------
# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 10Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/every-12-hours
#
# File size examples:
#
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb  ->  15000
# 10Mb  ->  10000
#
# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * *  [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
# ---
#
# 2. For /var/log/boot (bootlogd)
# ---
0 */23 * * *  [ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot
# ---

# 3. For /var/log/cron.log 
# ---
0 */23 * * *  [ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log
# ---
# --------------------------------------------------------------------------------------------

# Back In Time system entry, DO NOT EDIT -> will be edited by the gui:
0 */15 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
#
groucho@devuan:~$

/.xsession-errors > /home/$(whoami)/.xsession-errors)
groucho@devuan:/var/log$ tail -300 cron.log | grep .xsession-errors
Mar 28 23:00:01 devuan CRON[16542]: (groucho) CMD ([ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors)

groucho@devuan:/var/log$ tail -300 cron.log | grep /var/log/boot
Mar 28 23:00:01 devuan CRON[16541]: (groucho) CMD ([ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot)
groucho@devuan:/var/log$

groucho@devuan:/var/log$ tail -300 cron.log | grep /var/log/cron.log
Mar 28 23:00:01 devuan CRON[16543]: (groucho) CMD ([ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log)
groucho@devuan:/var/log$

groucho@devuan:/var/log$ tail -1000 cron.log | grep backintime
Mar 25 15:00:01 devuan CRON[27902]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Mar 27 00:00:01 devuan CRON[15156]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Mar 28 00:00:01 devuan CRON[21698]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
groucho@devuan:/var/log$

Could it be that it is just a cron.whatever problem?

Thanks in advance,

A.

Altoid · Installation

Hello:

Spaceman Spiff wrote:

Is this correct?
How to install NVIDIA driver ...

I had quite a few issues with the nVidia installation in Beowulf, but then I was installing the legacy340xx version which may or may not had been the cause of my problems.

In any case, have a read here, don't skip anything:

https://dev1galaxy.org/viewtopic.php?id=3820

Dev1 member HevyDevy figured out what was going on and how to do it properly.
By following his instructions I was able to successfully install the 340xx in Beowulf.

Apparently his last post/access was 2020-09-20, if you run into trouble with this maybe he'll chip in.
But the instructions he posted were rock solid.

Cheers,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

Peculiar.

Any idea as to what could have caused this situation?

As far as 'permissions' go, I did have a kept back files issue that ended up in upgrading from consolkit to elogind.
See http://dev1galaxy.org/viewtopic.php?id=4130

ralph.ronnquist wrote:

... your test shows that the dev-fstrim does get invoked, which is enough of detail.

Good.

Here's this morning's first entry in /tmp/WTF:

groucho@devuan:~$ cat /tmp/WTF
Tue, 30 Mar 2021 07:15:55 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z ]
+ FANCYTTY=1
+ true
+ echo -n [....] 
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 2
+ GREEN=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ [ 0 -eq 0 ]
+ /bin/echo -ne [ ok 
+ /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
Tue, 30 Mar 2021 07:30:01 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ RED=
+ YELLOW=
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
groucho@devuan:~$

ralph.ronnquist wrote:

... /var/log/WTF for persistent logging.

Right.

ralph.ronnquist wrote:

How do your /etc/anacrontab and /etc/default/anacron look?

Here they are:

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

groucho@devuan:~$ cat /etc/default/anacron
# Environment File for anacron

# ANACRON_RUN_ON_BATTERY_POWER
#
# NOTE:
#       For ANACRON_RUN_ON_BATTERY_POWER, settings here only works
#       when you are not using systemd.
#       Please read /usr/share/doc/anacron/README.Debian
#       to see how to adjust program behaviour on AC power.
#
# If set to "yes", start anacron even when on battery power.  By
# default, the /etc/init.d/anacron script tries to avoid running
# anacron unless on AC power, so as to avoid running down the battery.
# (Things like the locate updatedb cause a lot of I/O.)

ANACRON_RUN_ON_BATTERY_POWER=no

# ANACRON_ARGS
#
# Arguments/options to pass to anacron.
# By default, "-s" is used to ensure serialised job arrangements.
# If you want tasks to execute in parallel when the jobs are due to
# start, do not pass "-s" here.

ANACRON_ARGS=-s
groucho@devuan:~$

Thanks in advance.

Best,

A.

Altoid · Installation

Hello:

Altoid wrote:

I'll do that and post back.

Here's /tmp/WTF before shutting down for the day:

groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
Mon, 29 Mar 2021 17:30:01 -0300
Mon, 29 Mar 2021 18:30:01 -0300
Mon, 29 Mar 2021 19:30:01 -0300
Mon, 29 Mar 2021 20:30:01 -0300
Mon, 29 Mar 2021 21:30:01 -0300
Mon, 29 Mar 2021 22:30:01 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s    <--- | x |         
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ RED=
+ YELLOW=
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
groucho@devuan:~$

Well, + start-stop-daemon --start --exec /usr/sbin/anacron -- -s is there.

Is something running?

groucho@devuan:~$ pgrep -a run-parts
groucho@devuan:~$

No.
Forcing weekly scripts:

groucho@devuan:~$ run-parts --verbose /etc/cron.weekly
run-parts: executing /etc/cron.weekly/0anacron
/etc/cron.weekly/0anacron: 12: /etc/cron.weekly/0anacron: anacron: not found
run-parts: /etc/cron.weekly/0anacron exited with return code 127
run-parts: executing /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.weekly/dev-fstrim exited with return code 2
run-parts: executing /etc/cron.weekly/man-db
/etc/cron.weekly/man-db: 28: /etc/cron.weekly/man-db: start-stop-daemon: not found
run-parts: /etc/cron.weekly/man-db exited with return code 127
run-parts: executing /etc/cron.weekly/rkhunter
groucho@devuan:~$ 
groucho@devuan:~$

Yes, there we go!

Many instances of not found and Permission denied
Yes, WTF is right.

What's up with this?

Thanks a lot for your help.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... anacron start/stop script gets invoked every hour as it should, but it fails to perform.

That seems to be the case:

groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
Mon, 29 Mar 2021 17:30:01 -0300
Mon, 29 Mar 2021 18:30:01 -0300
Mon, 29 Mar 2021 19:30:01 -0300
Mon, 29 Mar 2021 20:30:01 -0300
Mon, 29 Mar 2021 21:30:01 -0300
groucho@devuan:~$

ralph.ronnquist wrote:

Add set -x on a line after your added date ... in /etc/init.d/anacron ...

Here it is:

groucho@devuan:~$ cat /etc/init.d/anacron
#! /bin/sh
--- snip ---
PATH=/bin:/usr/bin:/sbin:/usr/sbin
exec 2>>/tmp/WTF
date -R >&2
set -x
--- snip ---
groucho@devuan:~$

ralph.ronnquist wrote:

... wait for next invocation which now logs the whole script execution to /tmp/WTF.

Right.

ralph.ronnquist wrote:

... should have the line:
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s

I'll be watching a series and waiting for it.
Should happen before it ends. 8^7

ralph.ronnquist wrote:

... you would next try to force run the weekly scripts again.

ralph.ronnquist wrote:

... ensure any previous run has completed, with
pgrep -a run-parts
returning nothing ...
... then use
run-parts --verbose /etc/cron.weekly
to see the new, forced weekly run happening.

I'll do that and post back.

Q: if I change the destination from /tmp/WTF to /var/log/WTF, will it survive a reboot and append the in-between boot results?

Thanks a lot for your help.

Best,

A.

Altoid · Installation

Hello:

mknoop wrote:

I apologize.
... is the opposite ...
... ignore me, as you already ...

No, not ignoring you.

I was checking to find the link to what I had read yesterday about that so you could see it.
Moot point now.

It's the intention that counts.
Thanks for your input. 8^)

Best,

A.

Altoid · Installation

Hello:

Altoid wrote:

I'll check with /tmp/WTF tomorrow and get back with the results.

Here's what happened:
As posted previously, I set up WTF.

exec 2>>/tmp/WTF
date -R >&2

I also copied the script that should run in cron.weekly to cron.daily:

groucho@devuan:~$ ls -1 /etc/cron.daily/
--- snip ---
dev-fstrim
--- snip ---
groucho@devuan:~$

I monitored it a couple of times before I shut down the box and all I saw was a set of hourly entries such as this one:

groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
groucho@devuan:~$

The first one was at boot time.
The following one was at the next HH:30 mark and from then on, once every hour.
No errors logged.

Obviously, /tmp/WTF did not survive a reboot.

This morning I booted the box, did some work and went out to get some stuff.
When I returned, all I saw were a set of hourly entries but with no errors logged.

A look at /var/log/trim.log does not show anyhing new:

groucho@devuan:~$ cat /var/log/trim.log

On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
On Sun, 28 Mar 2021 08:46:19 -0300:
/var/log: 1.4 GiB (1473417216 bytes) trimmed on /dev/sda5
/home: 45.4 GiB (48720437248 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8660197376 bytes) trimmed on /dev/sda1
groucho@devuan:~$

From a previous post we know that the script will run if I do it manually:
Tested it again as USER so it won't really run.

groucho@devuan:~$ /etc/cron.daily/dev-fstrim
/etc/cron.daily/dev-fstrim: 7: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.daily/dev-fstrim: 8: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
groucho@devuan:~$

groucho@devuan:~$ /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
groucho@devuan:~$

Q: why am I seeing it run twice?

Head_on_a_Stick wrote:

... check if the cron.weekly script is recognised and run:
run-parts --test /etc/cron.weekly
That will show a list of the scripts to be run.

Here they are:

groucho@devuan:~$ run-parts --test /etc/cron.daily
--- snip ---
/etc/cron.daily/dev-fstrim
--- snip ---
groucho@devuan:~$

groucho@devuan:~$ run-parts --test /etc/cron.weekly
--- snip --- 
/etc/cron.weekly/dev-fstrim
--- snip ---
groucho@devuan:~$

It seems that the ownership of the scripts is correct:

groucho@devuan:~$ ls -l /sbin/fstrim
-rwxr-xr-x 1 root root 72808 Nov 27  2019 /sbin/fstrim
groucho@devuan:~$

groucho@devuan:~$ ls -l /etc/cron.daily/dev-fstrim
-rwxr-xr-x 1 root root 236 Mar 29 11:09 /etc/cron.daily/dev-fstrim
groucho@devuan:~$

groucho@devuan:/var/log$ ls -l /etc/cron.weekly/dev-fstrim
-rwxr-xr-x 1 root root 238 Mar  9 14:18 /etc/cron.weekly/dev-fstrim
groucho@devuan:/var/log$

That's all I have.
What else can I do?

Thank you both for your input.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

cron.log shows that it finds and loads and processes the /etc/cron.d/anacron scheduling, which would trigger the start/stop script if
there is an executable /etc/init.d/anacron (script) ...

It's there, the one I posted.

ralph.ronnquist wrote:

... and the pathname /run/systemd/system is not a directory (eg doesn't exist)

It doesn't.

groucho@devuan:~$ ls /run/systemd
cgroups-agent  inaccessible  machines  seats  sessions  users
groucho@devuan:~$

ralph.ronnquist wrote:

... add the following two lines into the script /etc/init.d/anacron:
exec 2>>/tmp/WTF
date -R >&2

... just after the PATH=... line.

groucho@devuan:~$ cat /etc/init.d/anacron
#! /bin/sh
--- snip ---
PATH=/bin:/usr/bin:/sbin:/usr/sbin
exec 2>>/tmp/WTF
date -R >&2
--- snip ---
groucho@devuan:~$

Done.

ralph.ronnquist wrote:

... cause an hourly logging to appear in the file /tmp/WTF, and that file will also contain any other stderr output ...
... the exec 2>>/tmp/WTF line associates standard error (for this script run) in append mode with the file ...
... the date -R >&2 line makes the date program issue a time stamp ...
... error message from the script will be appended ...

Right.
I'll check with /tmp/WTF tomorrow and get back with the results.

Thank you very much for your help.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... anacron is supposed to provide the extended cron function to make sure that the regular scripts are run even if the machine happens to be down at the nominal trigger time.

You give me too much credit, I did not know about that.
Thanks for the heads up. 8^)

ralph.ronnquist wrote:

... possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).

I see ...

Ahh ...
Must be why I got this mail from the system a couple of days ago:

From root@devuan Thu Mar 25 23:30:01 2021
Return-path: <root@devuan>
Envelope-to: root@devuan
Delivery-date: Thu, 25 Mar 2021 23:30:01 -0300
Received: from root by devuan with local (Exim 4.92)
	(envelope-from <root@devuan>)
	id 1lPcEb-0006Cr-Jd
	for root@devuan; Thu, 25 Mar 2021 23:30:01 -0300
From: root@devuan (Cron Daemon)
To: root@devuan
Subject: Cron <root@devuan> [ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
Message-Id: <E1lPcEb-0006Cr-Jd@devuan>
Date: Thu, 25 Mar 2021 23:30:01 -0300
Status: RO

invoke-rc.d: -----------------------------------------------------
invoke-rc.d: WARNING: 'invoke-rc.d anacron start' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -----------------------------------------------------
groucho@devuan:~$

Is this what you are referring to?
I get a bad shutdown every so often.
It's the crap BIOS in my Ultra24, maybe it kicked in at the right time.

ralph.ronnquist wrote:

... anacron is typically set up using the sysvinit start/stop script, once initially at boot up, and then regularly by cron with the schedule contol script /etc/cron.d/anacron.

Yes: " ... this script is to run anacron at boot so that it can catch up with missed jobs."

ralph.ronnquist wrote:

... includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something.

What would that be?
The part of /etc/init.d/anacron where it checks for on_ac_power returning a value of '0'?

What else would my workstation run on?

ralph.ronnquist wrote:

... if that something is present then your set up does not run anacron as it should ...

Surgery time?
Which lines should I comment?

groucho@devuan:~$ cat /etc/init.d/anacron
#! /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.
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin

test -x /usr/sbin/anacron || exit 0
test -r /etc/default/anacron && . /etc/default/anacron

. /lib/lsb/init-functions

case "$1" in
  start)
    if init_is_upstart 2>/dev/null; then
        exit 1
    fi
    log_daemon_msg "Starting anac(h)ronistic cron" "anacron"
    if test x"$ANACRON_RUN_ON_BATTERY_POWER" != x"yes" && test -x /usr/bin/on_ac_power
    then
        /usr/bin/on_ac_power >/dev/null
        if test $? -eq 1
        then
          log_progress_msg "deferred while on battery power"
	  log_end_msg 0
	  exit 0
        fi
    fi

    # on_ac_power doesn't exist, on_ac_power returns 0 (ac power being used)
    # or on_ac_power returns 255 (undefined, desktop machine without APM)
    start-stop-daemon --start --exec /usr/sbin/anacron -- $ANACRON_ARGS
    log_end_msg 0
    ;;
  restart|force-reload|reload)
	# nothing to do
    :
    ;;
  stop)
    if init_is_upstart 2>/dev/null && status anacron 2>/dev/null | grep -q start
    then
        exit 0
    fi
    log_daemon_msg "Stopping anac(h)ronistic cron" "anacron"
    start-stop-daemon --stop --exec /usr/sbin/anacron --oknodo --quiet --retry=USR1/90/TERM/5/KILL/5
    log_end_msg 0
    ;;
  status)
    exit 4
    ;;
  *)
    echo "Usage: /etc/init.d/anacron {start|stop|restart|force-reload|reload}"
    exit 2
    ;;
esac

exit 0
groucho@devuan:~$

ralph.ronnquist wrote:

... consequently your weekly script won't be run "automatically".
Similarly the boot up run of the script only happens at boot up if it's set up so.

This is what I see within the last 50 entries in /var/log/cron.log:

groucho@devuan:/var/log$ tail -50 cron.log | grep -i anacron
Mar 28 16:30:01 devuan CRON[10380]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 28 17:30:01 devuan CRON[20351]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 28 18:30:01 devuan CRON[5177]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
groucho@devuan:/var/log$

ralph.ronnquist wrote:

If the preconditions for the regular run/start of anacron are there ...

If I understood correctly (?), they are not.

Is there something I have to do with /etc/init.d/anacron?

Thanks a lot for your input.

Best,

A.

BTW: would it be possible to increase the logged-on time out?

Altoid · Installation

Hello:

Head_on_a_Stick wrote:

... output of this command (as root):
# crontab -l

Indeed:

[root@devuan ~]# crontab -l
no crontab for root
[root@devuan ~]#

In case you need it, here's my user's crontab -l:

groucho@devuan:~$ crontab -l

# For details see man 4 crontabs
#
# 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
#
# --------------------------------------------------------------------------------------------
# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 10Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/every-12-hours
#
# File size examples:
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb  ->  15000
# 10Mb  ->  10000
#
# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * *  [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
# ---
#
# 2. For /var/log/boot (bootlogd)
# ---
0 */23 * * *  [ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot
# ---

# 3. For /var/log/cron.log 
# ---
0 */23 * * *  [ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log
# ---
# --------------------------------------------------------------------------------------------

# Back In Time system entry, DO NOT EDIT -> will be edited by the gui:
0 */15 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
#
groucho@devuan:~$

I add comments to have a reference and keep track of 'how and why'.
Otherwise I forget. 8^/

Before writing this post I came across this:
https://www.cyberciti.biz/cloud-computi … t-working/

--- snip ---
Also add the path at the beginning of your script
PATH=/path/1:/path/2
PATH=/sbin:/usr/sbin/:/usr/local/sbin:/bin:/usr/local/bin
--- snip ---

But the page it is linked to does not say that the path has to be at the beginning of the script.
In any case, the thing is that /var/log/cron.log does not show the script being run:

groucho@devuan:~$ grep -i /sbin/fstrim /var/log/cron.log
groucho@devuan:~$

Thanks for your input.

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

... is anacron is installed?

Yes.

groucho@devuan:~$ apt list | grep -i anacron 

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

anacron/stable,now 2.3-28 amd64 [installed,automatic]
anacron/stable 2.3-28 i386
groucho@devuan:~$

Thanks for your input.

Bst,

A.

Altoid · Installation

Hello:

Head_on_a_Stick wrote:

... it's a PATH issue.
Either set PATH in the script or call the full path to fstrim in the script.

Right ...
That's what I did.

And that same day (2021-03-09) I ran it manually to check if it worked and it did:

On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
groucho@devuan:/var/log$

But as you can see, nothing has been logged since.
I should have run on the 16th and on the 23rd.

groucho@devuan:~$ cat /etc/cron.weekly/dev-fstrim
#!/bin/sh
# trim all mounted file systems which support it
# PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/trim.log
echo "On $(date -R):" >> $LOG
/sbin/fstrim -a -v >> "$LOG" 2>&1
groucho@devuan:~$

I checked again this morning:

[root@devuan ~]# /etc/cron.weekly/dev-fstrim
[root@devuan ~]# cat /var/log/trim.log
On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
On Sun, 28 Mar 2021 08:46:19 -0300:
/var/log: 1.4 GiB (1473417216 bytes) trimmed on /dev/sda5
/home: 45.4 GiB (48720437248 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8660197376 bytes) trimmed on /dev/sda1
[root@devuan ~]#

As you can see, the script runs and logs as intended.
But cron-weekly is not doing it.

What am I missing here?

Thanks in advance,

A.

The officially official Devuan Forum!

#1301 Off-topic » systemd's new feature (wtf?) » 2021-04-01 12:47:15

#1302 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 12:10:03

#1303 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 09:40:31

#1304 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 01:46:54

#1305 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 01:04:26

#1306 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 00:34:33

#1307 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 23:35:49

#1308 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 23:26:47

#1309 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 22:51:29

#1310 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 21:48:13

#1311 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 15:55:07

#1312 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 13:40:35

#1313 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 23:02:25

#1314 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 21:49:31

#1315 Re: Installation » Installing nvidia? » 2021-03-30 12:39:08

#1316 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 10:49:23

#1317 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 01:59:39

#1318 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 01:02:45

#1319 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-29 21:28:35

#1320 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-29 20:58:02

#1321 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-29 00:06:21

#1322 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 22:30:24

#1323 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 19:52:45

#1324 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 14:42:43

#1325 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 12:31:58

Board footer