The officially official Devuan Forum!

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

Ok that looks like the "normal" installed files. Hmmmm....

Do you use apparmor or selinux? Either one can do ugly things.

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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

Good thing then.

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

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

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

I keep my apparmor purged. I would purge selinux too had it been possible; it stays disabled.

For testing you might want to try changing /etc/default/anacron to say

ANACRON_RUN_ON_BATTERY_POWER=yes

just for the possibility that anacron misreads something.

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

I'm running out of ideas ...
I've set up an anacron test myself now and we'll see in a couple of days if I have a similar problem.

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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?

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

How to check it is effectively disabled?

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

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

... running out of ideas ...

Imagine me.

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.

Last edited by Altoid (2021-03-30 23:55:05)

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

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.

Last edited by Altoid (2021-03-31 15:06:26)

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: [SOLVED] Permissions for script in cron

Test with run-parts using root rather than your normal user. Root should have the /sbin directories in PATH, unlike your normal user. Note that either sudo -i or su - (the dash is important) are needed to obtain a root shell with the correct PATH.

---

Brianna Ghey — Rest In Power

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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

Will do.

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.

Last edited by Altoid (2021-03-31 16:00:33)

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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.

Last edited by Altoid (2021-03-31 21:49:41)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

You seem to mix up non-root and root user; the user's cron jobs ar run as that user and only root's cron jobs are run as root.

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

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

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

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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

Not surprised.
Sorry.

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

I see ...

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

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

My test showed nothing ...

But I 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)

Which package version do you have?

apt-cache policy anacron |& grep Installed

Is there an anacron running?

pstree -ap | grep -A 3 anacron

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

My test showed nothing ...

Thanks for the effort.

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

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

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

|   |   |-grep,13714 --color=always -A 3 anacron

that was the grepping itself, so no "real" anacron running.

Try again with

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

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

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

Following that we'll need to go deep diving with

sudo strace -f start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f >& /tmp/strace.log 

Possibly you'll need to install the strace package first.

That log will be long as it includes all the system calls by the execution, so the best is if you can paste it somewhere rather than include here. It looks like there's something just a little bit off on your system and this will give as a haystack to look in.

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

|   |   |-grep,13714 --color=always -A 3 anacron

that was the grepping itself ...

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

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

It doesn't.

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

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.

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

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

Last edited by Altoid (2021-04-01 00:36:07)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

Hmm. obviously your /usr/sbin/anacron dies before it starts, or while it about to start, seemingly at the point where it should allocate memory.

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

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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

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

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

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

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

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.

Last edited by Altoid (2021-04-01 01:04:46)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

Right; that's the right one... next check would be first to verify that the problem is with anacron, by seeing

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.

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

Right; that's the right one...

Good thing.

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

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

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

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

The warning can be ignored. But I expected to see the output "Anacron 2.3 started on 2021-04-01" after the "transferring control", and not seeing that is peculiar... which architecture do you have?

uname -a

file /usr/sbin/anacron

file $(readlink -f /lib64/ld-linux-x86-64.so.2)

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

The warning can be ignored.

I see.

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

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

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

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.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,351  

Re: [SOLVED] Permissions for script in cron

Good. So when the start script runs /usr/sbin/anacron it actuallly runs /bin/true which is doing bugger all...

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

Altoid

Member

Registered: 2017-05-07

Posts: 1,677  

Re: [SOLVED] Permissions for script in cron

Hello:

Good.
So when the start script runs /usr/sbin/anacron it actuallly runs /bin/true which is doing bugger all...

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

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

I see.

... two options:
... change the link by:

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

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

I could eventually pin it ...

... change /etc/init.d/anacron to use /usr/sbin/anacron.orig.anacron as binary;

... change start-stop-daemon --start command line to be

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

... more sticky fix than changing the link ...
... probably breaks if the live-config package is uninstalled.

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.