Bugzilla – Bug 1193402
systemd-zram-service fails to start
Last modified: 2022-07-27 13:19:40 UTC
The effort in https://bugzilla.opensuse.org/show_bug.cgi?id=1181400 prevents the service from systemd-zram-service from working correctly. The underlying script still works. It loads a kernel module, modifies devices, etc. I suggest the changeset to be reverted entirely: half the privileges must be available, the others don't offer much gain.
More reports of this bug here: https://www.reddit.com/r/openSUSE/comments/ra81qo/cannot_startenable_systemdzramswapservice/ Dec 06 19:34:00 computer zramswapon[5322]: swapon: cannot open /dev/zram0: No such file or directory Dec 06 19:34:00 computer zramswapon[5323]: swapon: cannot open /dev/zram1: No such file or directory Dec 06 19:34:00 computer zramswapon[5324]: swapon: cannot open /dev/zram2: No such file or directory Dec 06 19:34:00 computer zramswapon[5325]: swapon: cannot open /dev/zram3: No such file or directory Dec 06 19:34:00 computer systemd[1]: zramswap.service: Main process exited, code=exited, status=255/EXCEPTION Dec 06 19:34:00 computer systemd[1]: zramswap.service: Failed with result 'exit-code'. Dec 06 19:34:00 computer systemd[1]: Failed to start Service enabling compressing RAM with zRam.
(In reply to André Werlang from comment #0) depends a bit on what we need to remove. Can you please give home:jsegitz:branches:systemdhardening:filesystems/systemd-zram-service a try to see if that works for you?
(In reply to Johannes Segitz from comment #2) > (In reply to André Werlang from comment #0) > depends a bit on what we need to remove. Can you please give > home:jsegitz:branches:systemdhardening:filesystems/systemd-zram-service > a try to see if that works for you? Thanks for looking into this! I tried it, and this is what I get: ========================== × zramswap.service - Service enabling compressing RAM with zRam Loaded: loaded (/usr/lib/systemd/system/zramswap.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2021-12-09 20:46:21 EST; 21s ago Process: 731 ExecStart=/usr/sbin/zramswapon (code=exited, status=255/EXCEPTION) Main PID: 731 (code=exited, status=255/EXCEPTION) CPU: 34ms Dec 09 20:46:21 sam-virtualbox systemd[1]: Starting Service enabling compressing RAM with zRam... Dec 09 20:46:21 sam-virtualbox zramswapon[731]: /usr/sbin/zramswapon: line 23: /sys/block/zram0/disksize: Read-only file system Dec 09 20:46:21 sam-virtualbox zramswapon[801]: mkswap: error: swap area needs to be at least 40 KiB Dec 09 20:46:21 sam-virtualbox zramswapon[805]: swapon: /dev/zram0: read swap header failed Dec 09 20:46:21 sam-virtualbox systemd[1]: zramswap.service: Main process exited, code=exited, status=255/EXCEPTION Dec 09 20:46:21 sam-virtualbox systemd[1]: zramswap.service: Failed with result 'exit-code'. Dec 09 20:46:21 sam-virtualbox systemd[1]: Failed to start Service enabling compressing RAM with zRam.
Thanks for testing this so quickly. Looks like ProtectKernelTunables is the culprit. Can you please retest the current package?
(In reply to Johannes Segitz from comment #4) > Thanks for testing this so quickly. Looks like ProtectKernelTunables is the > culprit. Can you please retest the current package? Thanks very much! I confirm that systemd-zram-service-0.2.1-9.1.noarch.rpm fixes the problem.
(In reply to Johannes Segitz from comment #2) > (In reply to André Werlang from comment #0) > depends a bit on what we need to remove. Can you please give > home:jsegitz:branches:systemdhardening:filesystems/systemd-zram-service > a try to see if that works for you? Hi, I see you only left these options: ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelLogs=true ProtectControlGroups=true RestrictRealtime=true While these allow for ZRAM to activate they don't allow for it to deactivate properly. Particularly these ones: ProtectSystem=full ProtectHome=true ProtectKernelLogs=true ProtectControlGroups=true When running > sudo systemctl stop zramswap.service the swap space is still there ant status shows: > systemd[1]: Stopping Service enabling compressing RAM with zRam... > zramswapoff[24556]: rmmod: ERROR: Module zram is in use > systemd[1]: zramswap.service: Control process exited, code=exited, status=1/FAILURE > systemd[1]: zramswap.service: Failed with result 'exit-code'. > systemd[1]: Stopped Service enabling compressing RAM with zRam. Temporary fix: > sudo swapoff /dev/zram* ; sudo zramswapoff I've tested all 10 of the hardening options one by one and the only ones that work alone and in combination are: > ProtectHostname=true > RestrictRealtime=true Everything else breaks either starting or stopping.
hm it's strange that ProtectHome has this impact. But okay, if it's the two listed at the end it's pretty much useless. I'll revert my patch and will get back to this in 2022 once the log4j scare is over
I've looked at zramswapoff and saw that it's just a simple shell script so I did some more testing by replicating the steps manually. https://build.opensuse.org/package/view_file/filesystems/systemd-zram-service/zramswapoff?expand=1 I've found that when you add ProtectHome=true /proc/swaps gets populated with different file names: With ProtectHome=true: > cat /proc/swaps > Filename Type Size Used Priority > /zram0 partition 1359220 0 100 > /zram1 partition 1359220 0 100 > /zram2 partition 1359220 0 100 > /zram3 partition 1359220 0 100 > /zram4 partition 1359220 0 100 > /zram5 partition 1359220 0 100 > /zram6 partition 1359220 0 100 > /zram7 partition 1359220 0 100 > /zram8 partition 1359220 0 100 > /zram9 partition 1359220 0 100 > /zram10 partition 1359220 0 100 > /zram11 partition 1359220 0 100 Without ProtectHome=true: > cat /proc/swaps > Filename Type Size Used Priority > /dev/zram0 partition 1359220 0 100 > /dev/zram1 partition 1359220 0 100 > /dev/zram2 partition 1359220 0 100 > /dev/zram3 partition 1359220 0 100 > /dev/zram4 partition 1359220 0 100 > /dev/zram5 partition 1359220 0 100 > /dev/zram6 partition 1359220 0 100 > /dev/zram7 partition 1359220 0 100 > /dev/zram8 partition 1359220 0 100 > /dev/zram9 partition 1359220 0 100 > /dev/zram10 partition 1359220 0 100 > /dev/zram11 partition 1359220 0 100 Line 11 in zramswapoff greps specifically for /dev/zram$i so since it can't find any ZRAM devices they aren't removed from swap and the module can't be removed. If I change line 11 to: > if [ "$(grep /zram$i /proc/swaps)" != "" ]; then then it works with and without ProtectHome=true. As for why the /dev part is missing in /proc/swaps with ProtectHome=true I haven't figured it out.
*** Bug 1193704 has been marked as a duplicate of this bug. ***
(In reply to Johannes Segitz from comment #7) Request to drop is in sr#940303, still open
Problem also exists in Leap 15.4 Adding these overrides # /etc/systemd/system/zramswap.service.d/override.conf [Service] ProtectKernelModules=false ProtectKernelTunables=false PrivateDevices=false ProtectHome=false RestrictRealtime=true DeviceAllow=block-blkext r DeviceAllow=block-device-mapper r DeviceAllow=block-loop DeviceAllow=block-sd r DeviceAllow=block-virtblk r DeviceAllow=block-zram allow "interactive" start of the zramswap.service but the service still fails at boot.
This is an autogenerated message for OBS integration: This bug (1193402) was mentioned in https://build.opensuse.org/request/show/984580 Backports:SLE-15-SP3 / systemd-zram-service
Filed 989328 to get this out of 15.4
This is an autogenerated message for OBS integration: This bug (1193402) was mentioned in https://build.opensuse.org/request/show/989328 Backports:SLE-15-SP4 / systemd-zram-service
openSUSE-RU-2022:10066-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1193402 CVE References: JIRA References: Sources used: openSUSE Backports SLE-15-SP4 (src): systemd-zram-service-0.2.1-bp154.3.3.1