Most logs in /var/log, incl syslog, daemon.log, messages not being updated

[Member entropyagent]

I hope this is the right place to ask this question: (I think I have worked around it…maybe even fixed some of it?)

I installed antix21 runit 64 full on 2 Jan (according to minstall.log), in a “Virtual Machine”, to vda drives because I could not persuade antix21 to install to my lvm drives. The root drive was then rsynced over to my lvm drive on my multiboot “Real Machine”.

On 7 Jan, I noticed most of my logfiles in /var/log seem to be idle and not being updated by the system. I prepared a post on the subject, but was unable to submit due to the warning message alleging presence of “Stuff Packaged As Meat” Some of the dates below might be from the old post, dated 7 January.

For example messages, syslog, daemon.log, kern.log were last touched 4 Jan.

[Member entropyagent]

Helpful

Up

0

::

I apologise for the many posts….For the last 2 days, I have had several iterations of the post rejected with the follwing messages:

*** Forbidden. Your IP belongs to a high spam risk network. ***
*** Forbidden. Message seems to be spam. ***
*** Forbidden. You sent forms too often. Please wait a few minutes. *** I wonder why I sent forms too often?

So I am taking Wallon’s advice about splitting my story.

[Member entropyagent]

Helpful

Up

0

::

Regarding the untouched, neglected logfiles: I would expect them to be receiving constant updates. However, it occurred to me that the world had changed and runit was still settling in as a service manager, so maybe logging was also different.
I saw quite a few of the idle logs are owned by root:adm rather than root:root – I have never noticed this ownership before, and wondered if it might be significant.

I hope my tagwork is not a mess – is there a forum post preview function?

[Member entropyagent]

Helpful

Up

0

::

OK, gave up on trying to post a file listing of the /var/log folder. Too many rejections.

I started poking around the /var/log folder because I was experiencing the “Constantly Emptied /etc/resolv.conf” problem.
After startup, I could not access the Internet. Each time, I added a nameserver to /etc/resolv.conf (ignoring the “advice” not to edit
the file, as it would be overwritten at each boot) and Internet access returned. Several suggested remedies were attempted, without
success. I wondered if there might be some clues in the log folders, and discovered the logs were not being updated. I am not sure
of the logging infrastructure, and wondered if it might be affected by the systemd/sysv/runit fancy footwork. So…I searched
running processes for anything that looked like a log, and found this:

[Member entropyagent]

Helpful

Up

0

::

$ ps -feww| grep -i log
root 1505 1 0 21:29 ? 00:00:02 runsvdir -P /etc/service log: log/./run: file does not exist chown: invalid user: ‘_runit-log:adm’ chpst: fatal: unknown user/group: _runit-log

which seems to suggest that runsvdir, and therefore runit, is probably unhappy.

[Member entropyagent]

Helpful

Up

0

::

I wondered how to check the status of my services, and got this:

$ sudo service --status-all
down: /etc/sv/acpi-support: 1s, normally up, want up
run: /etc/sv/acpid: (pid 1663) 7451s; down: log: 1s, normally up, want up
down: /etc/sv/anacron: 7448s, normally up
run: /etc/sv/avahi-daemon: (pid 1734) 7448s
down: /etc/sv/bluetooth: 7451s
run: /etc/sv/connman: (pid 1710) 7448s; run: log: (pid 1692) 7449s
run: /etc/sv/cron: (pid 1599) 7451s
run: /etc/sv/cups: (pid 1619) 7451s
run: /etc/sv/dbus: (pid 1620) 7451s
warning: /etc/sv/dhclient: unable to open supervise/ok: file does not exist
run: /etc/sv/elogind: (pid 1628) 7451s
warning: /etc/sv/getty-hvc0: unable to open supervise/ok: file does not exist
run: /etc/sv/getty-tty1: (pid 1591) 7451s
run: /etc/sv/getty-tty2: (pid 1582) 7451s
run: /etc/sv/getty-tty3: (pid 1583) 7451s
run: /etc/sv/getty-tty4: (pid 1584) 7451s
down: /etc/sv/getty-tty5: 7451s
down: /etc/sv/getty-tty6: 7451s
warning: /etc/sv/getty-ttyS0: unable to open supervise/ok: file does not exist
run: /etc/sv/gpm: (pid 1604) 7451s
run: /etc/sv/haveged: (pid 1676) 7450s
run: /etc/sv/ntp: (pid 1616) 7451s
run: /etc/sv/rpcbind: (pid 1615) 7451s
down: /etc/sv/rsync: 7448s, normally up
fail: /etc/sv/rsyslog: runsv not running
run: /etc/sv/saned: (pid 1614) 7451s
run: /etc/sv/slimski: (pid 1621) 7451s
down: /etc/sv/smartmontools: 7448s, normally up
run: /etc/sv/ssh: (pid 1669) 7450s; down: log: 1s, normally up, want up
down: /etc/sv/sudo: 1s, normally up, want up
run: /etc/sv/udevd: (pid 1597) 7451s
down: /etc/sv/ufw: 7448s, normally up

This confused me (more than usual) for some time, but, eventually, I noticed the /etc/service folder was full of symlinks which seemed to be important
to runit. However, it had none for rsyslog and dhclient. Holding trembling thumbs, I created the links in /etc/service.
sudo ln -s /etc/sv/rsyslog rsyslog
sudo ln -s /etc/sv/dhclient /etc/service/dhclient

After a reboot (OK, it’s now a day later) rsyslog and dhclient seem to be running, logs are being updated, and /etc/resolv.conf
is working fine with a suitable nameserver.

• This reply was modified 1 year, 3 months ago by entropyagent. Reason: experimenting with tags
• This reply was modified 1 year, 3 months ago by entropyagent.

[Member entropyagent]

Helpful

Up

0

::

I wonder if my issue with /etc/resolv.conf getting regenerated “empty” after every boot was due to problems with starting dhclient?
I will have to investigate further with the other machines where it has been a problem (they were also runit setups, IIRC)

I will also like to ask about the other discouraging messages in the output of “sudo service –status-all”. Perhaps after recovering from the day’s activities and the hours spent trying to ninja my way past the spam filter. That spam filter is also worth some questioning. Perhaps the dollar signs in the various outputs excited it too much?

[Author]

Posts