The error msgs using "Cockpit Client Kauncher
Let’s try this:
sudo zypper in -t pattern -f cockpitto force a reinstall of the full cockpit pattern- Take a look and see if you have an
/etc/nsswitch.conffile - if you do, share the contents of that file. - While logging into cockpit, have a terminal window open running the command
sudo journalctl -g "avc: .*denied"
[sudo] password for studio-t:
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
Forcing installation of 'pattern:cockpit-16.0-160000.2.2.x86_64' from repository 'repo-oss (16.0)'.
Resolving package dependencies...
The following package is going to be reinstalled:
patterns-cockpit
The following pattern is going to be reinstalled:
cockpit
1 package to reinstall.
Package download size: 8.4 KiB
Package install size change:
| 53 B required by packages that will be installed
0 B | - 53 B released by packages that will be removed
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): y
Preloading: patterns-cockpit-16.0-160000.2.2.x86_64.rpm [done]
Preload finished. [success (1.4 KiB/s) ] ...............................................................[done]
Retrieving: patterns-cockpit-16.0-160000.2.2.x86_64 (repo-oss (16.0)) (1/1), 8.4 KiB
Checking for file conflicts: ...........................................................................[done]
(1/1) Installing: patterns-cockpit-16.0-160000.2.2.x86_64 ..............................................[done]
Running post-transaction scripts .......................................................................[done]
studio-t@Production:~>
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# Valid databases are: aliases, ethers, group, gshadow, hosts,
# initgroups, netgroup, networks, passwd, protocols, publickey,
# rpc, services, and shadow.
#
# Valid service provider entries include (in alphabetical order):
#
# compat Use /etc files plus *_compat pseudo-db
# db Use the pre-processed /var/db files
# dns Use DNS (Domain Name Service)
# files Use the local files in /etc
# hesiod Use Hesiod (DNS) for user lookups
# nis Use NIS (NIS version 2), also called YP
# nisplus Use NIS+ (NIS version 3)
#
# See `info libc 'NSS Basics'` for more information.
#
# Commonly used alternative service providers (may need installation):
#
# ldap Use LDAP directory server
# myhostname Use systemd host names
# mymachines Use systemd machine names
# mdns*, mdns*_minimal Use Avahi mDNS/DNS-SD
# resolve Use systemd resolved resolver
# sss Use System Security Services Daemon (sssd)
# systemd Use systemd for dynamic user option
# winbind Use Samba winbind support
# wins Use Samba wins support
# wrapper Use wrapper module for testing
#
# Notes:
#
# 'sssd' performs its own 'files'-based caching, so it should generally
# come before 'files'.
#
# WARNING: Running nscd with a secondary caching service like sssd may
# lead to unexpected behaviour, especially with how long
# entries are cached.
#
# Installation instructions:
#
# To use 'db', install the appropriate package(s) (provide 'makedb' and
# libnss_db.so.*), and place the 'db' in front of 'files' for entries
# you want to be looked up first in the databases, like this:
#
# passwd: db files
# shadow: db files
# group: db files
passwd: compat systemd
group: compat [SUCCESS=merge] systemd
shadow: compat systemd
# Allow initgroups to default to the setting for group.
# initgroups: compat
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files dns
aliases: files usrfiles
ethers: files usrfiles
gshadow: files usrfiles
netgroup: files
protocols: files usrfiles
publickey: files
rpc: files usrfiles
services: files usrfiles
automount: files
bootparams: files
netmasks: files
last but not least " journalctl -g "avc: .*denied""
weird output:
studio-t@Production:~> sudo journalctl -g "avc: .*denied"
[sudo] password for studio-t:
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.583:4): avc: denied { getattr } for p>
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.583:5): avc: denied { getattr } for p>
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.584:6): avc: denied { getattr } for p>
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.584:7): avc: denied { getattr } for p>
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.584:8): avc: denied { getattr } for p>
Mar 21 10:28:41 Production kernel: audit: type=1400 audit(1774049321.584:9): avc: denied { getattr } for p>
-- Boot 38923cdb6fcb4798a035456836375baf --
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.383:4): avc: denied { getattr } for p>
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.383:5): avc: denied { getattr } for p>
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.384:6): avc: denied { getattr } for p>
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.384:7): avc: denied { getattr } for p>
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.384:8): avc: denied { getattr } for p>
Mar 22 09:29:22 Production kernel: audit: type=1400 audit(1774132162.384:9): avc: denied { getattr } for p>
-- Boot 8a923a5c20984f7db72c856a46cf7c16 --
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.182:4): avc: denied { getattr } for p>
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.182:5): avc: denied { getattr } for p>
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.183:6): avc: denied { getattr } for p>
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.183:7): avc: denied { getattr } for p>
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.183:8): avc: denied { getattr } for p>
Mar 23 07:40:21 Production kernel: audit: type=1400 audit(1774212021.183:9): avc: denied { getattr } for p>
-- Boot cab1513ac4ea4c239f784d675060952a --
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.337:4): avc: denied { getattr } for p>
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.337:5): avc: denied { getattr } for p>
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.338:6): avc: denied { getattr } for p>
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.338:7): avc: denied { getattr } for p>
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.338:8): avc: denied { getattr } for p>
Mar 23 11:08:16 Production kernel: audit: type=1400 audit(1774224496.338:9): avc: denied { getattr } for p>
-- Boot c30811dfaa994504b1fcdb9f67d781f2 --
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.139:4): avc: denied { getattr } for p>
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.139:5): avc: denied { getattr } for p>
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.140:6): avc: denied { getattr } for p>
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.140:7): avc: denied { getattr } for p>
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.140:8): avc: denied { getattr } for p>
Mar 23 18:40:07 Production kernel: audit: type=1400 audit(1774251607.140:9): avc: denied { getattr } for p>
-- Boot 0f527757998547398c30b7f258063a4b --
Mar 24 06:47:46 Production kernel: audit: type=1400 audit(1774295266.183:4): avc: denied { getattr } for p>
Mar 24 06:47:46 Production kernel: audit: type=1400 audit(1774295266.183:5): avc: denied { getattr } for p>
Mar 24 06:47:46 Production kernel: audit: type=1400 audit(1774295266.187:6): avc: denied { getattr } for p>
Mar 24 06:47:46 Production kernel: audit: type=1400 audit(1774295266.187:7): avc: denied { getattr } for p>
studio-t@Production:~>
In Cockpit launcher same error msg ==>Authentication failed: internal-error: Error in service module
What “service module” is being referred to ?
thanks
The output you got here matches what I got when I reinstalled in my test Leap 16.0 setup.
Your output here is identical to what I have on my system.
What I was looking for here was an indication that there was an selinux issue (not likely, but worth checking). That the dates are a month old tells me this is not likely the problem.
At a guess, the service module is referring to the pam configuration. Have you made any changes to how pam configuration is set up on this system? In particular, /etc/pam.d/common-auth (which on my system links to /etc/pam.d/common-auth-pc) or /etc/pam.d/common-session-pc?
Was this a fresh installation or an upgrade?
You might try running sudo journalctl -t cockpit-ws -t cockpit-session -f and then attempt the login; that might give us some additional information.
1 Like
…found the problem as follows :
ok, the output
Apr 26 12:30:09 Production cockpit-session[2910]: cockpit-session: couldn't open session: studio-t: Error in service module
Apr 26 18:07:39 Production cockpit-session[8419]: pam_kwallet5(cockpit:auth): pam_kwallet5: pam_sm_authenticate
Apr 26 18:07:39 Production cockpit-session[8419]: pam_kwallet5(cockpit:auth): pam_kwallet5: Couldn't get password (it is empty)
Apr 26 18:07:39 Production cockpit-session[8419]: pam_kwallet5(cockpit:setcred): pam_kwallet5: pam_sm_setcred
Apr 26 18:07:39 Production cockpit-session[8419]: pam_limits(cockpit:session): cannot read settings from /usr/etc/security/limits.d/99-audio.conf: Permission denied
Apr 26 18:07:39 Production cockpit-session[8419]: pam_limits(cockpit:session): error parsing the configuration file: '/usr/etc/security/limits.d/99-audio.conf'
Apr 26 18:07:39 Production cockpit-session[8419]: pam_unix(cockpit:session): session opened for user studio-t(uid=1001) by studio-t(uid=0)
Apr 26 18:07:39 Production cockpit-session[8419]: pam_kwallet5(cockpit:session): pam_kwallet5: pam_sm_open_session
Apr 26 18:07:39 Production cockpit-session[8419]: pam_kwallet5(cockpit:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this.
Apr 26 18:07:39 Production cockpit-session[8419]: cockpit-session: couldn't open session: studio-t: Error in service module
*** Now I start Cockpit Client, enter username and password
==> msg Authentication failed: internal-error: Error in service module
Apr 26 18:10:29 Production cockpit-session[8742]: pam_kwallet5(cockpit:auth): pam_kwallet5: pam_sm_authenticate
Apr 26 18:10:29 Production cockpit-session[8742]: pam_kwallet5(cockpit:auth): pam_kwallet5: Couldn't get password (it is empty)
Apr 26 18:10:29 Production cockpit-session[8742]: pam_kwallet5(cockpit:setcred): pam_kwallet5: pam_sm_setcred
Apr 26 18:10:29 Production cockpit-session[8742]: pam_limits(cockpit:session): cannot read settings from /usr/etc/security/limits.d/99-audio.conf: Permission denied
Apr 26 18:10:29 Production cockpit-session[8742]: pam_limits(cockpit:session): error parsing the configuration file: '/usr/etc/security/limits.d/99-audio.conf'
Apr 26 18:10:29 Production cockpit-session[8742]: pam_unix(cockpit:session): session opened for user studio-t(uid=1001) by studio-t(uid=0)
Apr 26 18:10:29 Production cockpit-session[8742]: pam_kwallet5(cockpit:session): pam_kwallet5: pam_sm_open_session
Apr 26 18:10:29 Production cockpit-session[8742]: pam_kwallet5(cockpit:session): pam_kwallet5: not a graphical session, skipping. Use force_run parameter to ignore this.
Apr 26 18:10:29 Production cockpit-session[8742]: cockpit-session: couldn't open session: studio-t: Error in service module
Note the …" cannot read settings from /usr/etc/security/limits.d/99-audio.conf: Permission denied "
99-audio.conf was added on the advice of “ARDOUR” development to eliminate X-RUNS
Content of 99-audio.conf
# /usr/etc/security/limits.d/99-audio.conf
#
# Applied 10th March 2026 Otto Hase
#
#Ardour mod 24 Aug 2022
#
@audio - rtprio 99
# for rosegarden 18/9/22 and Ardour 5th Jan 2026
@audio - nice -15
@audio - memlock unlimited
#
# End of Mod
#
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
#
#Where:
#<domain> can be:
# - a user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
# - the wildcard %, can be also used with %group syntax,
# for maxlogin limit
#
#<type> can have the two values:
# - "soft" for enforcing the soft limits
# - "hard" for enforcing hard limits
#
#<item> can be one of the following:
# - core - limits the core file size (KB)
# - data - max data size (KB)
# - fsize - maximum filesize (KB)
# - memlock - max locked-in-memory address space (KB)
# - nofile - max number of open file descriptors
# - rss - max resident set size (KB)
# - stack - max stack size (KB)
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - as - address space limit (KB)
# - maxlogins - max number of logins for this user
# - maxsyslogins - max number of logins on the system
# - priority - the priority to run user process with
# - locks - max number of file locks the user can hold
# - sigpending - max number of pending signals
# - msgqueue - max memory used by POSIX message queues (bytes)
# - nice - max nice priority allowed to raise to values: [-20, 19]
# - rtprio - max realtime priority
#
#<domain> <type> <item> <value>
#
#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#@student - maxlogins 4
# End of file
I removed 99-audio.conf from folder “limits.d”
And … bingo ==> Cockpit Client is working
Thank you !! …and.all of you who have contributed
Now the next question is " Do I get X-runs ? i have to take it up with ARDOUR
1 Like
That snippet needs to be in /etc/security/limits.d/, snippets should never be in /usr/etc.
1 Like
Thanks ! done it … Ardour is not complaining
Questution : in 15.6 there was only one limits.d under /etc/security/.
that has changed with 16.0 why ?
thanks
PS. moving the snippet to /etc/security => 
Cockpit client will not work
same msg:Authentication failed: internal-error: Error in service module
ok we got Cockpit to work , now we need to get Ardour working without xruns
life is full of challanges 
Defaults are in /usr/etc now so that package updates that include new defaults don’t clobber user-defined configurations. The only place you should put updates is in /etc. The /usr/etc defaults are managed exclusively by the packages.
… which I did (today). … with the result
Under /etc/security I created folder /limits.d and placed 99-audio.conf in the folder
…and Cockpit client failed
I wonder why
cheers
That would indicate to me there’s something wrong with the snippet you have added to the 99-audo.conf file. I would investigate that (in a separate topic).
Here I added that snippet on Tumbleweed and everything looks OK, including Cockpit.
May I suggest to test a snippet with just:
@audio - rtprio 95
@audio - nice -19
@audio - memlock 4194304
Values are copied from /usr/etc/security/limits.d/25-pw-rlimits.conf and work here for pipewire.
1 Like
Thanks for that. I 'll check it out
cheers
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.