Package: rsyslog
Version: 8.2504.0-1
Severity: normal
X-Debbugs-Cc: [email protected]

Hi Richard,

for some context see https://salsa.debian.org/debian/rsyslog/-/merge_requests/7#note_634371

Building rsyslog on debusine results in an autopkgtest failure:

44s System Events
44s =-=-=-=-=-=-=
44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]: imklog: cannot open kernel log (/proc/kmsg): Permission denied.
44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]: activation of module imklog failed [v8.2506.0 try https://www.rsyslog.com/e/2145 ]
44s
44s * FAIL: unmatched lines - logcheck rules may need updating
44s This email is sent by logcheck. If you no longer wish to receive
44s such mail, you can either uninstall the logcheck package or modify
44s its configuration file (/etc/logcheck/logcheck.conf).


It appears, debusine.debian.net uses LXD/LXC but access to /proc/kmsg is
more restricted than on debci.


I see 3 possible ways forward

1/ Add isolation-machine to Restrictions in debian/tests/control
Apparently isolation-container (as provided by debci and debusine) is
not guaranteed to provide an accessible /proc/kmsg
This significantly reduces test coverage though, as isolation-machine
requires qemu, which is currently only available on amd64 and
currently only available on debci if explicitly requested

2/ Add this error message to rsyslog.logcheck.ignore.server, i.e. treat
this as an expected error. Looks wrong to me, but I'm not a logcheck
user.

3/ Modify the rsyslog configuration we use for debian/tests/logcheck and
remove the `module(load="imklog")` line from /etc/rsyslog.conf.
I.e. we would run rsylog with a slightly different configuration as
is the default.

4/ Drop the autopkgtest again. Not a fan of this option.



On a cursory glance, I think 3) would be the best option but I would
welcome your opionion on this matter.

Regards,
Michael

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 31 Jul 2025, 16:05 Michael Biebl, <[email protected]> wrote:


44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]: imklog: cannot

open kernel log (/proc/kmsg): Permission denied.
44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]: activation of module imklog failed [v8.2506.0 try https://www.rsyslog.com/e/2145 ]

It appears, debusine.debian.net uses LXD/LXC but access to /proc/kmsg is
more restricted than on debci.

I see 3 possible ways forward

1/ Add isolation-machine

(agree with you that this would not be best)

2/ Add this error message to rsyslog.logcheck.ignore.server, i.e. treat
this as an expected error. Looks wrong to me, but I'm not a logcheck
user.

definitely agree it shouldnt be in the rules shipped by the package -
exactly as you suggest, users would want to know if this error was being
made - see beloe

3/ Modify the rsyslog configuration we use for debian/tests/logcheck and
remove the `module(load="imklog")` line from /etc/rsyslog.conf.
I.e. we would run rsylog with a slightly different configuration as
is the default.

could work, but then you'll be less sure that the logcheck rules are right
for users

On a cursory glance, I think 3) would be the best option but I would
welcome your opionion on this matter.

How about a variant of 2 --- change the logcheck rules inside the test,
only if /proc/kmesg is restricted


if [ "/proc/kmesg" is readable (?) ] ; then
echo "rules matching the error" > /etc/logcheck/ignore.d.server/foo
fi
# rest of test as before

then the logcheck in the test will ignore those messages in debusine, but
be unaffected on salsa (i dont know what the test should be though). and if debusine changes it will then be a no-op.

(i havnt looked at the test, but from what i remember this should work, can have a look)

<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 31 Jul 2025, 16:05 Michael Biebl, &lt;<a href="mailto:[email protected]" target="_blank" rel="noreferrer">[email protected]</a>&gt; wrote:<br></div><div dir="ltr" class=
"gmail_attr"><br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]:
imklog: cannot open kernel log (/proc/kmsg): Permission denied.<br>
 44s Jul 30 20:28:18 autopkgtest-lxd-lryznw rsyslogd[1999]: activation of module imklog failed [v8.2506.0 try <a href="https://www.rsyslog.com/e/2145" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.rsyslog.com/e/2145</a> ]<br></
blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
It appears, <a href="http://debusine.debian.net" rel="noreferrer noreferrer noreferrer" target="_blank">debusine.debian.net</a> uses LXD/LXC but access to /proc/kmsg is<br>
more restricted than on debci.<br>


I see 3 possible ways forward<br>

1/ Add isolation-machine</blockquote></div></div><div dir="auto">(agree with you that this would not be best)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,
204);padding-left:1ex"><br>
2/ Add this error message to rsyslog.logcheck.ignore.server, i.e. treat<br>
   this as an expected error. Looks wrong to me, but I&#39;m not a logcheck<br>
   user.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">definitely agree it shouldnt be in the rules shipped by the package - exactly as you suggest, users would want to know if this error was being made - see  beloe</div><div
dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

3/ Modify the rsyslog configuration we use for debian/tests/logcheck and<br>
   remove the `module(load=&quot;imklog&quot;)` line from /etc/rsyslog.conf.<br>
   I.e. we would run rsylog with a slightly different configuration as<br>
   is the default.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">could work, but then you&#39;ll be less sure that the logcheck rules are right for users</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On a cursory glance, I think 3) would be the best option but I would<br> welcome your opionion on this matter.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">How about a variant of 2 --- change the logcheck rules inside the test, only if /proc/kmesg is restricted </div><div dir="auto"><br></div><div
dir="auto"><br></div><div dir="auto">if [   &quot;/proc/kmesg&quot; is readable (?) ]  ; then</div><div dir="auto">echo &quot;rules matching the error&quot; &gt; /etc/logcheck/ignore.d.server/foo</div><div dir="auto">fi</div><div dir="auto"># rest of
test as before</div><div dir="auto"><br></div><div dir="auto">then the logcheck in the test will ignore those messages in debusine, but be unaffected on salsa (i dont know what the test should be though). and if debusine changes it will then be a no-op.</

<div dir="auto"><br></div><div dir="auto">(i havnt looked at the test, but from what i remember this should work, can have a look)</div><div dir="auto"><br></div><div dir="auto"><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 1 Aug 2025 at 19:57, Michael Biebl <[email protected]> wrote:

Am 01.08.25 um 19:01 schrieb Richard Lewis:

if [ "/proc/kmesg" is readable (?) ] ; then echo "rules matching
the error" > /etc/logcheck/ignore.d.server/foo fi # rest of test as
before

That said, I don't know, how access to /proc/kmsg is restricted inside debusine and how we can devise a robust check for that.

The error message indicates, that the file exists but is not even
accessible to root.

I dont know how debusine works either, but looking at proc_kmesg(5)
and dmesg(1), i would try

dmesg --since '1s ago' 2>/dev/null

this exits with 0 'normally' (even if there is no output to show), and
1 inside an 'unshare -r' (even if run by root)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)