[SOLVED] Permissions for script in cron

Altoid · 2021-03-08 19:51:15

Hello:

I have put a script to run fstrim in /etc/cron.weekly/:

groucho@devuan:/$ cat /etc/cron.weekly/dev-fstrim
#!/bin/sh
# trim all mounted file systems which support it
# added 20200315
#
LOG=/var/log/trim.log
echo "* $(date -R) *" >> $LOG
fstrim -a -v >> $LOG
groucho@devuan:/var/log$

But it is not running, probably because fstrim needs admin credentials to run.
I can run the script as root but that needs my intervention and the idea is that it runs automagically one a week.

What is the proper way to achieve this?
An entry in /etc/sudoers.d for fstrim?

Thanks in advance.

A.

ralph.ronnquist · 2021-03-08 20:18:43

Normally you'd need root permissions to put scripts there, and it will, if executable, run by cron as root.

However, the PATH is a common cause of issues, see e.g. man 5 crontab.

Head_on_a_Stick · 2021-03-08 20:19:20

It's not a permissions issue, it's a PATH issue.

Either set PATH in the script or call the full path to fstrim in the script.

EDIT: gah, too slow...

Last edited by Head_on_a_Stick (2021-03-08 20:19:38)

Altoid · 2021-03-08 21:08:01

Hello:

ralph.ronnquist wrote:

... PATH is a common cause of issues, see e.g. man 5 crontab.

--

Head_on_a_Stick wrote:

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

Like this?
Belt and suspenders ...

#!/bin/sh
# trim all mounted file systems which support it
# added x 20200315
#
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
/sbin/fstrim -a -v >> $LOG

Thank you both for your input.

Cheers,

A.

Head_on_a_Stick · 2021-03-09 16:28:05

Altoid wrote:

Like this?

Well that would work but I would use either/or. If you really want to use both methods then call the full path for date as well.

And for the log you should probably record both stdout and stderr:

/sbin/fstrim -a -v >> "$LOG" 2>&1

Last edited by Head_on_a_Stick (2021-03-09 16:28:45)

Altoid · 2021-03-09 20:26:54

Head_on_a_Stick wrote:

... would use either/or.
... want to use both methods then call the full path for date ...

Yes, makes sense.
Done, will use full path to the script.

Head_on_a_Stick wrote:

... should probably record both stdout and stderr:
/sbin/fstrim -a -v >> "$LOG" 2>&1

Done.
Thanks for the heads up.

Cheers,

A.

Altoid · 2021-03-28 12:31:58

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.

ralph.ronnquist · 2021-03-28 14:15:25

Just to be sure: is anacron is installed?

Altoid · 2021-03-28 14:42:43

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.

Head_on_a_Stick · 2021-03-28 18:34:34

Can we see the output of this command (as root):

# crontab -l

Altoid · 2021-03-28 19:52:45

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.

ralph.ronnquist · 2021-03-28 21:20:32

Good. As you might know, 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. Since the scripts are not run it is possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).

The running of 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. Afaict looking at my such script, it includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something. (A small-brain idea appearing as attempted solution to cater for a range of possible installation sites other than this one, but not bad enough for the effort of forking the package)

So, if that something is present then your set up does not run anacron as it should and 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.

If the preconditions for the regular run/start of anacron are there, the next point of call would be to review and confirm anacron local configuration, at both /etc/anacrontab and /etc/default/anacron. And for debugging purposes also add/change the start/stop script so that it makes some output to, say, /tmp/WTF (eg a date stamp) whenever it's run. Further, to speed up the testing cycle you might set it up for daily trimming rather than weekly since the auto-magic is supposedly the same for that (as configured in the typical installed /etc/anacrontab).

Altoid · 2021-03-28 22:30:24

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?

ralph.ronnquist · 2021-03-28 23:08:09

Ok. 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), and
the pathname /run/systemd/system is not a directory (eg doesn't exist)

To verify that you would add the following two lines into the script /etc/init.d/anacron:

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

just after the PATH=... line.

That should cause an hourly logging to appear in the file /tmp/WTF, and that file will also contain any other stderr output that the script run generates.

In detail: the exec 2>>/tmp/WTF line associates standard error (for this script run) in append mode with the file, and the date -R >&2 line makes the date program issue a time stamp in RFC 5322 format to standard error. Any further error message from the script will be appended subsequently.

Altoid · 2021-03-29 00:06:21

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.

Head_on_a_Stick · 2021-03-29 16:17:53

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

mknoop · 2021-03-29 20:34:57

From my experience, scripts in cron.* will not run unless the file name ends in ".sh". Changing the suffix on the filename is one way to turn off the execution for a while. It looks like you script is named dev-fstrim.

Altoid · 2021-03-29 20:58:02

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.

Last edited by Altoid (2021-03-29 21:31:52)

mknoop · 2021-03-29 21:07:58

mknoop wrote:

From my experience, scripts in cron.* will not run unless the file name ends in ".sh". Changing the suffix on the filename is one way to turn off the execution for a while. It looks like you script is named dev-fstrim.

I apologize. This is the opposite of the truth. Just ignore me, as you already are.

Altoid · 2021-03-29 21:28:35

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.

ralph.ronnquist · 2021-03-30 00:25:16

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

Add set -x on a line after your added date ... in /etc/init.d/anacron, and then wait for next invocation which now logs the whole script execution to /tmp/WTF. This in particular should have the line:

+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s

Seeing that to be so you would next try to force run the weekly scripts again. First ensure any previous run has completed, with

pgrep -a run-parts

returning nothing, and then use

run-parts --verbose /etc/cron.weekly

to see the new, forced weekly run happening.

Altoid · 2021-03-30 01:02:45

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 · 2021-03-30 01:59:39

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.

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

ralph.ronnquist · 2021-03-30 10:27:49

Peculiar. Yes, the run-parts .. command if run as root would avoid the permission errors, but your test shows that the dev-fstrim does get invoked, which is enough of detail.

yes, you can use /var/log/WTF for persistent logging.

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

Altoid · 2021-03-30 10:49:23

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.

The officially official Devuan Forum!

#1 2021-03-08 19:51:15

[SOLVED] Permissions for script in cron

#2 2021-03-08 20:18:43

Re: [SOLVED] Permissions for script in cron

#3 2021-03-08 20:19:20

Re: [SOLVED] Permissions for script in cron

#4 2021-03-08 21:08:01

Re: [SOLVED] Permissions for script in cron

#5 2021-03-09 16:28:05

Re: [SOLVED] Permissions for script in cron

#6 2021-03-09 20:26:54

Re: [SOLVED] Permissions for script in cron

#7 2021-03-28 12:31:58

Re: [SOLVED] Permissions for script in cron

#8 2021-03-28 14:15:25

Re: [SOLVED] Permissions for script in cron

#9 2021-03-28 14:42:43

Re: [SOLVED] Permissions for script in cron

#10 2021-03-28 18:34:34

Re: [SOLVED] Permissions for script in cron

#11 2021-03-28 19:52:45

Re: [SOLVED] Permissions for script in cron

#12 2021-03-28 21:20:32

Re: [SOLVED] Permissions for script in cron

#13 2021-03-28 22:30:24

Re: [SOLVED] Permissions for script in cron

#14 2021-03-28 23:08:09

Re: [SOLVED] Permissions for script in cron

#15 2021-03-29 00:06:21

Re: [SOLVED] Permissions for script in cron

#16 2021-03-29 16:17:53

Re: [SOLVED] Permissions for script in cron

#17 2021-03-29 20:34:57

Re: [SOLVED] Permissions for script in cron

#18 2021-03-29 20:58:02

Re: [SOLVED] Permissions for script in cron

#19 2021-03-29 21:07:58

Re: [SOLVED] Permissions for script in cron

#20 2021-03-29 21:28:35

Re: [SOLVED] Permissions for script in cron

#21 2021-03-30 00:25:16

Re: [SOLVED] Permissions for script in cron

#22 2021-03-30 01:02:45

Re: [SOLVED] Permissions for script in cron

#23 2021-03-30 01:59:39

Re: [SOLVED] Permissions for script in cron

#24 2021-03-30 10:27:49

Re: [SOLVED] Permissions for script in cron

#25 2021-03-30 10:49:23

Re: [SOLVED] Permissions for script in cron

Board footer