December 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1180014] New: OpenSuSE 15.2 imposes unexpectedly low open files limit (1024) , causing MariaDB / MySQL to crash with errors: Too many open files
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1180014 Bug ID: 1180014 Summary: OpenSuSE 15.2 imposes unexpectedly low open files limit (1024) , causing MariaDB / MySQL to crash with errors: Too many open files Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: glenbarney(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Consider an upgraded or freshly-loaded OpenSuSE 15.2 installation, running MariaDB, with all current updates applied. The MariaDB system is in high volume use, with a large number of databases running. As a result, the /etc/my.cnf file has been modified to show, among other things: open_files_limit = 32768 On OpenSuSE 15.1 and previous, this limit was honored, or at least functional. Checking in the MySQL client, we see: MariaDB [(none)]> show global variables like '%open_files_limit%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | open_files_limit | 98617 | +------------------+-------+ However, after upgrading to OpenSuSE 15.2, *OR* after doing a fresh install of OpenSuSE 15.2, that limit is no longer honored. With the same /etc/my.cnf, we see: MariaDB [(none)]> show global variables like '%open_files_limit%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | open_files_limit | 1024 | +------------------+-------+ This is reproducible on a fresh reload of the OS. Needless to say, on a high-volume system, our databases quickly started crashing, and MariaDB quickly became hung and unresponsive, filling up with stuck mysqld processes consuming high CPU, and filling the logs with "Too many open files" messages. This was especially visible during nightly backup dumps (mysqldump) of our databases for archive purposes. Now although this might be seen as a MariaDB bug, I am not certain. Because the fix seems to be to modify /usr/lib/systemd/system/maria*service (2 files) and add the following lines to the bottom of the file: LimitNOFILE=infinity LimitMEMLOCK=infinity and then running the usual: systemctl --system daemon-reload systemctl restart mariadb Once that is done, we see a normal return to: MariaDB [(none)]> show global variables like '%open_files_limit%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | open_files_limit | 32839 | +------------------+-------+ Given the fix location, I wonder if this is something either in the Kernel, or in SystemD. My problem here, of course, is that any time there is an update to MariaDB going forward, /usr/lib/systemd/system/maria*service will be removed and reinstalled, despite my edits, resulting in MariaDB ulimit starvation again. Other processes on the server may well be impacted as well, I am unable to tell. I've examined /etc/systemd/*conf and see no changes between the two OS versions that would trigger this. In particular, lines such as: #DefaultLimitNOFILE= #DefaultLimitMEMLOCK= are commented out in both 15.1 and 15.2, everywhere I can see them. The only possibly relevant difference I can see is between the two mariadb.service files: > diff mariadb.service.15.1 mariadb.service.15.2 41a56,61 > # CAP_IPC_LOCK To allow memlock to be used as non-root user > # CAP_DAC_OVERRIDE To allow auth_pam_tool (which is SUID root) to read /etc/shadow when it's chmod 0 > # does nothing for non-root, not needed if /etc/shadow is u+r > # CAP_AUDIT_WRITE auth_pam_tool needs it on Debian for whatever reason > CapabilityBoundingSet=CAP_IPC_LOCK CAP_DAC_OVERRIDE CAP_AUDIT_WRITE Although if I comment out CapabilityBoundingSet, that does not solve the problem. So to summarize, there are two problems here: 1. The default installation of 15.2, plus MariaDB, limits MariaDB open files ignoring /etc/my.cnf 2. Changes made to the systemd service file to work around #1 are reverted on every update. Thank you! Glen -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1179925] Suspend to disk is broken on Thinkpad T495 vega 10 gpu
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179925 https://bugzilla.suse.com/show_bug.cgi?id=1179925#c13 --- Comment #13 from Takashi Iwai <tiwai(a)suse.com> --- Thanks. The kernel is being rebuilt with two more backport patches in the same OBS repo. Let's see whether it works better. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179925] Suspend to disk is broken on Thinkpad T495 vega 10 gpu
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179925 https://bugzilla.suse.com/show_bug.cgi?id=1179925#c12 --- Comment #12 from Ali Abdallah <ali.abdallah(a)suse.com> --- Created attachment 844446 --> https://bugzilla.suse.com/attachment.cgi?id=844446&action=edit hwinfo -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179925] Suspend to disk is broken on Thinkpad T495 vega 10 gpu
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179925 https://bugzilla.suse.com/show_bug.cgi?id=1179925#c11 --- Comment #11 from Takashi Iwai <tiwai(a)suse.com> --- Then something in powerplay stuff, maybe. Meanwhile, could you give hwinfo output? I guess your chip isn't properly supported by 5.3.x base in anyway, but it's better to improve something, of course. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179328] Problem: redshift-gtk-1.12-6.2.i586 requires python3-xdg, but this requirement cannot be provided
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179328 https://bugzilla.suse.com/show_bug.cgi?id=1179328#c4 --- Comment #4 from OBSbugzilla Bot <bwiedemann+obsbugzillabot(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1179328) was mentioned in https://build.opensuse.org/request/show/855787 Factory / redshift -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179293] Unlock disk by entering password only once
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179293 https://bugzilla.suse.com/show_bug.cgi?id=1179293#c2 Jos� Iv�n L�pez Gonz�lez <jlopez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jlopez(a)suse.com Resolution|--- |WONTFIX --- Comment #2 from Jos� Iv�n L�pez Gonz�lez <jlopez(a)suse.com> --- There are 2 options to avoid entering the encryption password twice: a) Create a separate (non-encrypted) /boot partition. b) Provide a key file as described in [1], although I am not sure about security concerns with this. Ideally, this would be accomplished by making the bootloader to automatically pass the encryption key to the kernel while booting. But such feature request was already rejected for SLE 15 SP1. AFAIK, nothing has been requested for openSUSE yet, so maybe you are interested on opening a new feature request [2] for openSUSE. Of course, YaST could be improved to somehow force a separate boot partition when root is encrypted. But again, a feature request is needed for this. Thanks for reporting. [1] https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the… [2] https://en.opensuse.org/openSUSE:Submitting_feature_requests -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179973] HSQLDB installation don't start properly
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179973 https://bugzilla.suse.com/show_bug.cgi?id=1179973#c3 Pedro Monreal Gonzalez <pmonrealgonzalez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast2-maintainers(a)suse.de |pmonrealgonzalez(a)suse.com Flags|needinfo?(pmonrealgonzalez@ | |suse.com) | --- Comment #3 from Pedro Monreal Gonzalez <pmonrealgonzalez(a)suse.com> --- I didn't know I was set as bugowner for this package. /sqltool.rc(In reply to Luca Forzano from comment #0) > HSQLDB installed by YAST, so standard repository fails to start, due to > error in the service file: > /usr/lib/systemd/system/hsqldb.service > > in > 9,11c9,11 > < ExecStart=/usr/libexec/hsqldb/hsqldb-wrapper > < ExecStartPost=/usr/libexec/hsqldb/hsqldb-post > < ExecStop=/usr/lib/hsqldbexec/hsqldb-stop > --- > > ExecStart=/usr/lib/hsqldb/hsqldb-wrapper > > ExecStartPost=/usr/lib/hsqldb/hsqldb-post > > ExecStop=/usr/lib/hsqldb/hsqldb-stop > > so the real path of the file listed is: > /usr/libexec/hsqldb/ The libexec change was not propagated properly here. I'll modify the service file and I'll check if its required somewhere else. > There is also the warning that the file permissions: > /var/lib/hsqldb/sqltool.rc > owned by hsqldb user must be changed in 600. Should be installed with 600: install -m 600 %{SOURCE4} %{buildroot}%{_localstatedir}/lib/%{name} -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179737] HDMI audio output inactive (Nvidia)
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179737 https://bugzilla.suse.com/show_bug.cgi?id=1179737#c4 --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- OK, then could you give alsa-info.sh output? Run the script with --no-upload option, and attach to Bugzilla (don't paste). At best, run on both states with HDMI connected and disconnected, and upload both results. Also, please give the output from hwinfo command, and the dmesg output, too. And, I wonder whether it's really Nvidia GPU that actually does output. In many cases, it's Intel GPU that does the modesetting including HDMI output, while Nvidia is only for rendering. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179925] Suspend to disk is broken on Thinkpad T495 vega 10 gpu
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179925 https://bugzilla.suse.com/show_bug.cgi?id=1179925#c10 Ali Abdallah <ali.abdallah(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ali.abdallah@suse | |.com) | --- Comment #10 from Ali Abdallah <ali.abdallah(a)suse.com> --- Created attachment 844441 --> https://bugzilla.suse.com/attachment.cgi?id=844441&action=edit dmesg failed resume from hibernate kernel 5.3.18-lp152.2.g53cb342 I gave it a try, but unfortunately hibernate is still broken. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179328] Problem: redshift-gtk-1.12-6.2.i586 requires python3-xdg, but this requirement cannot be provided
by bugzilla_noreply＠suse.com 14 Dec '20

14 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179328 https://bugzilla.suse.com/show_bug.cgi?id=1179328#c3 Tejas Guruswamy <masterpatricko(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Flags|needinfo?(suseino(a)riseup.ne | |t) | --- Comment #3 from Tejas Guruswamy <masterpatricko(a)gmail.com> --- (In reply to Sergey Savkin from comment #2) > I can give a little info for it. > When i had this conflict, i am selected deinstallation of conflicted > packages and install python3-xdg. Then i decide to install all conflicted > packages again with ignoring dependencies like python3-pyxdg, and they dont > work because they uses python and python3-xdg dont have needed modules. > Next step, i decide to return python3-pyxdg and ignore dependencies for > packages that requires python3-xdg, and 'zypper in python3-pyxdg' failed > with file conflicts, because packages (python3-pyxdg and python3-xdg) > contains few same files with diffetent contents. Thank you! I understand the problem now. Yes, I see now python3-pyxdg and python3-xdg provide very similar but incompatible apis under the same library name. > Actually, looks like python3-pyxdg contains all modules from python3-xdg > (python3-xdg is a part of python3-pyxdg), and package that requires only > python3-xdg can work with python3-pyxdg installed, but package that requires > python3-pyxdg cant work with only python3-xdg installed. Sadly I think they are mutually incompatible in the actual code. I have changed redshift to only recommend python3-pyxdg since that seems to be the upstream intention The incompatibility between xdg and pyxdg remains however. -- You are receiving this mail because: You are on the CC list for the bug.

1 0