I can confirm that I have the same behavior since some days. Stratos. On Mon, Nov 18, 2019 at 6:56 PM Takashi Iwai wrote:

On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:

...

Hi all.

A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).

My Tumbleweed is up to date. What do I need to change to get the permissions back?

Cheers, Michael

The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.

english would be something like: reading of kernel buffer failed: operation not permitted

Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.

thanks,

Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

What's wrong exactly with dmesg requiring sudo ? Even if this wasn't the previous behavior ? On 11/18/19 5:56 PM, Takashi Iwai wrote:

On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:

...

Hi all.

A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).

My Tumbleweed is up to date. What do I need to change to get the permissions back?

Cheers, Michael

The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.

english would be something like: reading of kernel buffer failed: operation not permitted Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.

thanks,

Takashi

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 19.11.19 um 09:13 schrieb Martin Wilck:

On Mon, 2019-11-18 at 18:13 +0100, Michael Pujos wrote:

...

What's wrong exactly with dmesg requiring sudo ? Even if this wasn't the previous behavior ?

And what's wrong with using "journalctl -k -b"?

First, it does not work. seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. -- Logs begin at Wed 2019-09-18 14:47:35 CEST, end at Mon 2019-11-18 15:38:08 CET. -- -- No entries -- Second, performance. Try this on a 500-days-uptime machine running on slow rotating rust.

Martin

N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩrg==--

Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2019 11.26, Martin Wilck wrote:

On Tue, 2019-11-19 at 10:01 +0100, Stefan Seyfried wrote:

...

...

And what's wrong with using "journalctl -k -b"?

First, it does not work.

seife@vbox-seife:/local> journalctl -k -b Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice.

Well, it tells you what to do to make it work, does it not?

...

Second, performance.

Try this on a 500-days-uptime machine running on slow rotating rust.

You should update more often :-) Joke aside, I haven't tried. I'm curious, how long does it take?

Up to half an hour with just a month of logs, last time I tried on rotating rust.

Anyway, would "dmesg" actually be useful on such a machine? The kernel log buffer might have wrapped and lost messages after such a long uptime. More often than not, you're only interested in the latest messages, for which you can use something like "journalctl --since -10m -k", which is much quicker than "journalctl -b -k".

It takes a bit of changing habits, but I've come to like the journalctl command a lot.

I'll have to remember that one. I just tried, but the journal doesn't have all the text. journal

Nov 19 12:51:55 Telcontar kernel: snd_hda_intel 0000:03:00.0: CORB reset timeout#1, CORBRP = 0 Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.3:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.2:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) Nov 19 12:51:55 Telcontar kernel: pciehp 0000:00:1c.4:pcie004: Timeout on hotplug command 0x0018 (issued 1912 msec ago) Nov 19 12:51:55 Telcontar kernel: serial 00:02: activated Nov 19 12:51:55 Telcontar kernel: r8169 0000:07:00.0 eth1: link down Nov 19 12:51:55 Telcontar kernel: r8169 0000:06:00.0 eth0: link down Nov 19 12:51:55 Telcontar kernel: ata6: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata8: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata7: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: ata5: SATA link down (SStatus 0 SControl 300) Nov 19 12:51:55 Telcontar kernel: r8169 0000:06:00.0 eth0: link up Nov 19 12:51:55 Telcontar kernel: PM: restore of devices complete after 4106.678 msecs Nov 19 12:51:55 Telcontar kernel: PM: Trampoline freed Nov 19 12:51:55 Telcontar kernel: OOM killer enabled. Nov 19 12:51:55 Telcontar kernel: Restarting tasks ... done.

dmesg:

[50647.969674] snd_hda_intel 0000:03:00.0: CORB reset timeout#1, CORBRP = 0 [50647.973469] pciehp 0000:00:1c.3:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) [50647.973471] pciehp 0000:00:1c.2:pcie004: Timeout on hotplug command 0x0018 (issued 1904 msec ago) [50647.981468] pciehp 0000:00:1c.4:pcie004: Timeout on hotplug command 0x0018 (issued 1912 msec ago) [50647.985588] serial 00:02: activated [50648.001725] r8169 0000:07:00.0 eth1: link down [50648.025736] r8169 0000:06:00.0 eth0: link down [50648.295594] ata6: SATA link down (SStatus 0 SControl 300) [50648.295597] ata8: SATA link down (SStatus 0 SControl 300) [50648.295641] ata7: SATA link down (SStatus 0 SControl 300) [50648.295648] ata5: SATA link down (SStatus 0 SControl 300) [50650.182723] r8169 0000:06:00.0 eth0: link up [50650.301711] PM: restore of devices complete after 4106.678 msecs [50650.302013] PM: Image restored successfully. ********** [50650.302015] PM: Trampoline freed [50650.302042] PM: Basic memory bitmaps freed ********** [50650.302043] OOM killer enabled. [50650.302044] Restarting tasks ... done.

The "**********" mark missing lines on the journal. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXdPo1gAKCRC1MxgcbY1H 1ZWCAJ0dY3xLFONA1ao1Th9u/epUFJjgKQCdGaThOuBuebiPMVaVgTHX3A+FJWw= =YFl1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:

I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).

Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request? Martin N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�

On Tue, 2019-11-19 at 17:32 +0100, Michal Suchánek wrote:

On Tue, Nov 19, 2019 at 03:25:19PM +0000, Martin Wilck wrote:

...

On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:

...

I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).

Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?

State of the art fix is 'zypper in rsyslog'. Then you can use cp which has performance orders of magnitude better than journalctl.

I don't think fixing systemd journal design is something somebody would seriously consider by now. It is not like nobody has tried, is it?

I haven't followed the development close enough to tell. But it's such a central element of modern Linux distros that it's a real shame it performs so badly. Martin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/2019 16.25, Martin Wilck wrote:

On Tue, 2019-11-19 at 15:47 +0100, Stefan Seyfried wrote:

...

I've come to thoroughly hate it since I had to tame landscapes with SOC6 and SOC7 (where the journal was in RAM only, but still the ridiculous amount of logging in openstack combined with the ridiculous performance of journalctl made running "supportconfig" an 8hours+ job. Most of the time was spent in something like "journalctl -b > journal.txt". I believe we even got a PTF for supportutils working around the issue).

Yuck. Looks like a thing someone should fix, some time. Have you considered filing a bug or feature request?

That journalctl is absurdly slow in rotating disk has been known for years. I remember mail threads discussing it long ago. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXdQkYgAKCRC1MxgcbY1H 1RdKAJ9ltHoakLhcwaZm8Mm37dmLBe5NVwCfSvfzl6ROK10XuXaarguNY506UlM= =Eedj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Montag, 18. November 2019, 17:56:26 CET schrieb Takashi Iwai:

On Mon, 18 Nov 2019 17:51:47 +0100,

Michael Born wrote:

...

Hi all.

A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).

My Tumbleweed is up to date. What do I need to change to get the permissions back?

Cheers, Michael

The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.

english would be something like: reading of kernel buffer failed: operation not permitted

Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.

thanks,

Takashi

fwiw I think it's actually reasonable to restrict kernel buffer access to privileged users in openSUSE too.

I filed bug 1157066. https://bugzilla.opensuse.org/show_bug.cgi?id=1157066 Cheers, Michael Am 18.11.19 um 17:56 schrieb Takashi Iwai:

On Mon, 18 Nov 2019 17:51:47 +0100, Michael Born wrote:

...

Hi all.

A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).

My Tumbleweed is up to date. What do I need to change to get the permissions back?

Cheers, Michael

The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.

english would be something like: reading of kernel buffer failed: operation not permitted

Care to open a bugzilla entry? This must be a kernel config change (wrt CONFIG_SECURITY_DMESG_RESTRIC) that was incorrectly inherited from SLE kernel.

thanks,

Takashi

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 18 Nov 2019 20:05:58 +0100, Adam Mizerski wrote:

W dniu 18.11.2019 o 17:51, Michael Born pisze:

...

Hi all.

A few days ago I realised that I'm not allowed to see kernel messages any more. I'm absolutely sure I could see them before (with dmesg).

My Tumbleweed is up to date. What do I need to change to get the permissions back?

Cheers, Michael

The german message reads: dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt.

english would be something like: reading of kernel buffer failed: operation not permitted

Is it bad?

"In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far

Basically such a change shouldn't have been done without announcement or proper discussion even if it's an intended change. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Отправлено с iPhone

18 нояб. 2019 г., в 20:11, Takashi Iwai написал(а):



...

Is it bad?

"In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access" https://www.phoronix.com/scan.php?page=news_item&px=Dmesg-Unrestricted-2019-So-Far

Basically such a change shouldn't have been done without announcement or proper discussion even if it's an intended change.

But the change is already there, so what is the point of bug report *now*? To revert, announce and then revert revert? I’d say, it becomes documentation bug - it should be mentioned in release notes.-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thank you. That is useful. Michael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org