Posts by Altoid

Altoid · Installation

Hello:

Head_on_a_Stick wrote:

Why not?
What happens when you comment-out the wtmp & btmp stanzas?

Don't know.
I did not edit anything, I just renamed the original as logrotate.old and copied the new one in.

Head_on_a_Stick wrote:

Altoid wrote:
What does your logrotate.conf look like?
https://salsa.debian.org/debian/logrota … otate.conf

My Devuan Beowulf has logrotate 3.14.0:

groucho@devuan:~$ sudo logrotate --version
logrotate 3.14.0

    Default mail command:       /usr/bin/mail
    Default compress command:   /bin/gzip
    Default uncompress command: /bin/gunzip
    Default compress extension: .gz
    Default state file path:    /var/lib/logrotate/status
    ACL support:                yes
    SELinux support:            yes
groucho@devuan:~$

But for some strange reason, the logrotate.conf file I have is the logrotate.conf file packaged with logrotate 3.13.0, without this line:

--- snip ---
# use date as a suffix of the rotated file    <---- | x |
dateext
--- snip ---

The rest is the same.

See: https://github.com/logrotate/logrotate/ … 3.0.tar.gz

I'll get the .*conf file from logrotate 3.14.0 and use that.
Will report back once done.

Edit:
Works, no errors.
But my logrotate.conf file was the wrong version.

Thanks for your input.

Best,

A.

Altoid · Installation

Hello:

Head_on_a_Stick wrote:

Have you actually tried ...

Yes.
At least in my system it is not a drop-in replacement.

There is at least one thing I noticed.
And the fixed logrotate.conf has this:

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog

In Devuan Beowulf there is not syslog group (at least I can't find it).

groucho@devuan:~$ grep syslog /etc/group
groucho@devuan:~$

Also, syslog is owned by root but belongs to the adm group:

groucho@devuan:~$ ls -l /var/log/syslog
-rw-r----- 1 root adm 4816 Apr  1 13:30 /var/log/syslog
groucho@devuan:~$

That's why I think someone esle with proper skills has to have a look.

Head_on_a_Stick wrote:

... don't have any wtmp lines in /etc/logrotate.conf in my bullseye ...

My Devuan Beowulf has it:

roucho@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 {   <----- | x |
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {   <----- | x |
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

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

So apparently that is why we get the mail I posted.

What does your logrotate.conf look like?

Thanks for your input.

Best,

A.

Altoid · Installation

Hello:

There is a bug in the logrotate.conf configuration.
See here: https://bugs.launchpad.net/ubuntu/+sour … ug/1915759

ralph.ronnquist pointed it out to me here: https://dev1galaxy.org/viewtopic.php?pid=28663#p28663 while helping me with an anacron problem caused (probably) live-config.
The error shows up when logrotate is run in /etc/cron.whatever and then you get notifocaton from the system:

From root@devuan Thu Apr 01 11:31:07 2021
Envelope-to: root@devuan
Delivery-date: Thu, 01 Apr 2021 11:31:07 -0300
From: Anacron <root@devuan>
To: root@devuan
Subject: Anacron job 'cron.daily' on devuan
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 01 Apr 2021 11:31:07 -0300

/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

The problem is that the fix posted is an Ubuntu fix.
ie: probably will not run properly in Devuan without adjusting it

Anyone know how to edit it so it will run?

Thanks in advance.

Cheers,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

One confirmation would be that your fstrim logging shows up.
... manual forced test would be like before, i.e. if live-config is uninstalled, then ...
sudo /usr/sbin/anacron -s -d -n -f
... should be telling about running the cron.{daily,weekly,monthly} jobs.

Right.

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

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

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

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

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

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

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

It seems to be working. 8^D!

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

----

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

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

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

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

Best,

A.

Altoid · Installation

Hello:

ralph.ronnquist wrote:

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?

ralph.ronnquist wrote:

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

I see.

ralph.ronnquist wrote:

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

ralph.ronnquist wrote:

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

Altoid · Off-topic

Hello:

fsmithred wrote:

Over here it's 04/01 ...

fsmithred wrote:

This "new" implementation sounds like it might be a useful addition ...

With the obvious proviso that your opinion with respect to this has much more weight that mine, I just see it as yet another one of systemd tentacles.
Reminds me so much of the MS registry.

Thanks for your input.

Best,

A.

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.

The officially official Devuan Forum!

#1326 Re: Installation » [SOLVED] Duplicate log entry for /var/log/wtm - logrotate.conf error » 2021-04-01 19:06:29

#1327 Re: Installation » [SOLVED] Duplicate log entry for /var/log/wtm - logrotate.conf error » 2021-04-01 16:54:49

#1328 Installation » [SOLVED] Duplicate log entry for /var/log/wtm - logrotate.conf error » 2021-04-01 15:43:43

#1329 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:56:31

#1330 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:23:00

#1331 Re: Off-topic » systemd's new feature (wtf?) » 2021-04-01 13:16:18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer