5.1.8: kresd throwing many ERRORs in /var/log/messages

Hi,

Five months ago I raised this same topic in Community Office : Testing Branches.

5.1.0: kresd throwing many ERRORs in /var/log/messages

I thought a software update fixed the problem, but I’ve just been looking around /var/log/messages again today and the error messages are back.

root@turris:/tmp/log# head -5 /var/log/messages ; tail -5 /var/log/messages
Feb  4 18:12:01 turris syslog-ng[8649]: syslog-ng starting up; version='3.30.1'
Feb  4 18:12:21 turris kresd[6675]: ERROR: udp sendmmsg() sent -1 / 2; Permission denied
Feb  4 18:12:21 turris kresd[6675]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  4 18:12:21 turris kresd[6675]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  4 18:12:24 turris kresd[6675]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  4 22:00:01 turris crond[30284]: (root) CMD (/usr/bin/notifier)
Feb  4 22:00:01 turris crond[30283]: (root) CMD (/bin/sh -c "source /lib/functions/sentinel.sh; allowed_to_run "nikola" && exec sentinel-nikola --random-sleep")
Feb  4 22:00:01 turris crond[30278]: (root) CMDOUT (There is no message to send.)
Feb  4 22:00:11 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  4 22:00:13 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 2; Permission denied
root@turris:/tmp/log# cat /var/log/messages | grep "ERROR: udp sendmmsg" | cut -c24- | sort | uniq -c
    240 kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
     27 kresd[22227]: ERROR: udp sendmmsg() sent -1 / 2; Permission denied
      1 kresd[22227]: ERROR: udp sendmmsg() sent -1 / 3; Permission denied
    436 kresd[6675]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
     72 kresd[6675]: ERROR: udp sendmmsg() sent -1 / 2; Permission denied
root@turris:/tmp/log#

So 207 messages per hour.

Omnia is fully updated on HBT, so running 5.1.8 at the moment.

Any help/guidance appreciated.

Duncan

This continues the thread


I’ll assume that you still haven’t noticed any DNS problems (just such logs).


I found some instance of the lines in my log archive, and my understanding is that they happened when the LAN was down temporarily. Some requests arrived when it was OK but now the replies could not be sent and (perhaps surprisingly) kernel marked that with “Permission denied”.

Network device 'eth2' link is down

It’s perhaps weird that that it’s “Permission denied”, but disabling IPv6 also causes that message. I’m not sure why the errors get classified this way (on Turris OS).

You are right - I haven’t noticed any DNS issues. It’s just these log messages that I see.

None of my network devices have been down in the last 3 days:

root@turris:/tmp/log# zcat messages.?.gz  | grep device
Feb  1 13:37:57 turris kernel: [    0.000334] Console: colour dummy device 80x30
Feb  1 13:37:57 turris kernel: [    3.120700] usbcore: registered new device driver usb
Feb  1 13:37:57 turris kernel: [    4.243466] 2 fixed-partitions partitions found on MTD device spi0.0
Feb  1 13:37:57 turris kernel: [    4.725645] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
Feb  1 13:37:57 turris kernel: [    4.845379] marvell-cesa f1090000.crypto: CESA device successfully registered
Feb  1 13:37:57 turris kernel: [    6.266472] Waiting 2 sec before mounting root device...
Feb  1 13:37:57 turris kernel: [    8.375183] BTRFS: device fsid e52b34d6-a58c-46ea-8994-bf7facde3adb devid 1 transid 1724 /dev/root
Feb  1 13:37:57 turris kernel: [    8.384780] BTRFS info (device mmcblk0p1): disk space caching is enabled
Feb  1 13:37:57 turris kernel: [    8.391509] BTRFS info (device mmcblk0p1): has skinny extents
Feb  1 13:37:57 turris kernel: [    8.402083] BTRFS info (device mmcblk0p1): enabling ssd optimizations
Feb  1 13:37:57 turris kernel: [    8.411956] VFS: Mounted root (btrfs filesystem) on device 0:12.
Feb  1 13:37:57 turris kernel: [   12.070098] BTRFS info (device mmcblk0p1): disk space caching is enabled
Feb  1 13:37:57 turris kernel: [   13.738921]     input device check on
Feb  1 13:37:57 turris kernel: [   14.072947] pci 0000:00:02.0: enabling device (0140 -> 0142)
Feb  1 13:37:57 turris kernel: [   16.100160] pci 0000:00:01.0: enabling device (0140 -> 0142)
Feb  1 13:37:57 turris kernel: [   18.121686] device lan0 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.126320] device eth1 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.213925] device lan1 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.321437] device lan2 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.421422] device lan3 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.553051] device lan4 entered promiscuous mode
Feb  1 13:37:57 turris kernel: [   18.557683] device eth0 entered promiscuous mode
Feb  1 13:38:18 turris netifd: Network device 'eth2' link is down
Feb  1 13:38:22 turris netifd: Network device 'eth2' link is up
root@turris:/tmp/log# cat messages.1  | grep device
root@turris:/tmp/log# cat messages  | grep device
root@turris:/tmp/log# tail messages | grep ERROR
Feb  5 15:36:34 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:37:34 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:37:34 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:37:47 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:37:47 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:37:53 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:38:06 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:38:06 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:38:08 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
Feb  5 15:38:08 turris kresd[22227]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied
root@turris:/tmp/log#

Current logs show there were 15 similar messages around the time of the last reboot (Feb 1st), but then nothing again until Feb 3rd. Then I get an average 228 similar messages per hour.

My wifi is disabled, but IPv6 is enabled. I haven’t noticed any degradation in service from the Omnia. Just these messages

1 Like

Well, I don’t know what causes those lines for you. Maybe if the client who asked disappears from LAN before the answer is sent, or something like that.

In the end I came to conclusion that these (default-mode) logs are both extraneous and insufficient, so we decided to remove them. Extraneous at least in the sense that there apparently could be way too many of them, and perhaps it could log events that aren’t normally interesting at all. Insufficient in the sense that they contain too little information to find why the sending failed.