Hi.
I'm using artix-dinit and wanted to use zramctl. To do so, I've found the zramen wrapper. And since I'm using dinit, I just installed zramen-dinit package. It works, but it uses always default values, so I can't define stuff like size, compression algorithm, etc.
I've taken a look at the PKGBUILD of zramen-dinit package (here in artix gitea). And also at the source code of zramen (in github) and came to the conclusion that the config is lost in the zramen-dinit package. What I mean is:
- In github, the zramen base package has a folder sv/zramen with three files inside. One of the files is just a plain config file (just defining ZRAM_ variables for compression algorithm, size, number of compression streams, etc). The other two files are sh scripts, start and stop wrappers called "run" and "finish" respectively. The "run" script sources the config file if present.
- In gitea, the zramen-dinit "subpackage", so to speak, has just two files: the zramen "unit" file (I don't know how they are called in dinit) and a zramen.script which is just a shell script that takes one parameter (start or stop) and just executes something similar to what the "run" and "finish" files from zramen base package, but the config portion is missing.
What I've tried:
- Manually editing the file /etc/dinit.d/zramen to include a "env-file" clause pointing to a config file I put inside /etc/dinit.d/config/zramen.conf. But for however reason, it doesn't work. It gets ignored and just starts zramctl with default clauses. I've tried with two formats: with "export ZRAM_WHATEVER=value" and just "ZRAM_WHATEVER=value", like in the zramen github repository)
- Manually editing the file /etc/dinit.d/scripts/zramen to source the config file (same config file in same location, /etc/dinit.d/config/zramen.conf). And it works (only with the "export ZRAM_WHATEVER=value" format, the other one without "export" doesn't work). But this would be potentially be broken in case someone updates zramen-dinit package, right? Or am I wrong?
Can we improve the zramen-dinit package? Or can I somehow contribute to make it use the three zramen files (config, finish, run)?
Thanks in advance.
Newb here. Just joined.
I edited the bin script, not sure if that is the right way for zramen but works.
sudo nano /usr/bin/zramen
Then change the values for constants such as below code block from script.
# constants {{{
# use this compression algorithm for zram by default
readonly COMP_ALGORITHM='lz4'
readonly ZRAM_COMP_ALGORITHM="${ZRAM_COMP_ALGORITHM:-$COMP_ALGORITHM}"
# give zram swap device highest priority
readonly PRIORITY=32767
readonly ZRAM_PRIORITY="${ZRAM_PRIORITY:-$PRIORITY}"
# allocate this percentage of memory for zram by default
readonly SIZE=25
readonly ZRAM_SIZE="${ZRAM_SIZE:-$SIZE}"
# set the maximum number of compression streams for zram
readonly STREAMS=$(nproc)
readonly ZRAM_STREAMS="${ZRAM_STREAMS:-$STREAMS}"
# zramen version number
readonly VERSION=0.2.1
# set TMPDIR to work directory for mktemp
readonly WORK_DIR='/var/run/zramen'
TMPDIR="$WORK_DIR"
# end constants }}}
Hi steve_
It was also my first message in this forum, just joined as well haha. Welcome and thanks for your reply.
Doing that also works but the problem is what happens if there is an update for the zramen package itself. I understand it would overwrite the script and the values you entered would be lost. Right? Does it work that way or if it finds the file already present, it skips installing it again?
Hi, yeah i didnt factor in updates. That might be an issue.
But you are right, in the zramen --help, there are options to change algo and size but they dont persist over reboots.
My init is openrc and it also has the issue, so not just dinit.
I've just opened an issue in the zramen repository (in github) to see how the developer would prefer to deal with this:
https://github.com/atweiden/zramen/issues/8
But anyways, I'll need to somehow contribute to zraman main package and zramen-xxx subpackages here in gitea.artixlinux. I tried logging in but apparently forum and gitea do not share user database (which is logical, now that I think about it). So I don't actually know how to contribute to those PKGBUILD files that will need a little tweak if zramen creator hears my suggestion.
Cloning + PR works without the ability to log in in gitea?
And now I'm realiizing this post may be in the wrong subforum. Maybe a mod can move it to the Packages subforum here https://forum.artixlinux.org/index.php/board,8.0.html
For me it complains during early boot that the log file reaches a read only file system, it starts fine manually afterwards.
What init system? Also dinit?
Yes.
Not much in the zramen.log file, it does get to "attempting to initialize...device" weirdly.
Maybe you can try to manually run the zramctl command (at the end of the day, that's what zramen is, I think: a wrapper around zramctl)
In this line of code you can see what command is run:
https://github.com/atweiden/zramen/blob/master/zramen#L245
Same here. It seems zramen is starting too early.
I don't think this is the best way to do it but it works.
Changing the following line in the service file seems to do the trick:
- waits-for = pseudofs
+ waits-for = fsck
Is there a way to make the changes to a dinit service file persist after updates?
I initially wanted to ignore this since
zramen is not an Arch package (and I didn't add it initially), however since the alternative is
systemd-zram-generator, I took a second look at this and rewritten the dinit service itself (I don't know why a
script file is needed when we can invoke the binary script itself).
type = scripted
command = /usr/bin/zramen make
stop-command = /usr/bin/zramen toss
env-file = /etc/dinit.d/config/zramen.conf
logfile = /var/log/dinit/zramen.log
depends-on = early-devices.target
after = early-fs-local.target # can be removed if logfile is removed/log-type is buffer
ZRAM_COMP_ALGORITHM=zstd # for testing purposes
#ZRAM_PRIORITY=32767
#ZRAM_SIZE=25
#ZRAM_MAX_SIZE=4096
#ZRAM_STREAMS=1
It works for me.
Though from this PR (https://github.com/atweiden/zramen/pull/4) I found the zramen author's response odd. Why doesn't
zramen just read the config file (https://github.com/atweiden/zramen/blob/master/sv/zramen/conf) directly from the bash script (just put it in
/etc and name it
/etc/zramen.conf)? Why isn’t it (I quote) "designed to be sourced outside of a runit service context"?
Also, zramen can be a POSIX sh script instead of bash script, but that's outside this topic and can be discussed another day.
As for packaging, I'll need to contact whoever last packaged zramen (and its scripts).
Thanks for your reply.
Yeah, I also added an "issue" to the zramen repo in github, promising a PR that I never did ::)
Maybe I can take a look now. But my idea was to convince the zramen developer to just add a simple line:
config_file_path="/etc/zramen.conf"
[ -r "${config_file_path}" ] && . "${config_file_path}"
near the top of the script, so default values can always be provided with a config file, instead of the miriad of parameters zramctl has (algo, size, streams, etc).
But I like your approach a lot more since it's specific for dinit. I just wanted to help the guy with s6 also in that PR you mentioned hahaha
@konimex I think the author means "./conf isn't designed to be sourced from outside of a shell script". Since we can get the same effect of sourcing ./conf by prepending
envfile /etc/s6/config/zramen.conf to the s6 command, or using
env-file = in dinit, I don't think this needs zramen's maintainer to step in and say "this is the canonical config file everywhere".
Yeah, but why shouldn't it be the "canonical config file everywhere"? I honestly prefer
@migmolrod's solution of that simple line instead of making an init-specific solution of using
envfile for s6,
env-file for dinit, different conf location for every single init. I don't really mind (and frankly, it's just one line ultimately). But the reasoning is odd to me. That's all.