[moving the privite discussion on BTS after D.Bogatov request] [Lorenzo Puliti] Hi! As already anticipated, i'm working on a converter capable of generating runscripts from systemd units. In fact it's a set of script for automating the whole process, from the downloading of the unit up to the creation of a patch suitable for BTS. The idea is to improve the converter engine and then open a mass-bug thread on debian-devel with few hundred patch provided. Unfortunately the task revealed to be more complex than I expect, so the whole project is still in WIP status, usable but one has to carefully review and integrate the runscripts. https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.2 Each script takes as argument a space separated list of basenames as the one in /etc/init.d/ (but a unit with the basename must exists) the correct order is fetch --> converter --> finalize --> hackit I'm looking for ideas, suggestions or bug report to improve the code ( watch out, the converter code is messy, I haven't had the time to do the cleanup) ; in case you are interested, attached is the list of the services that i'm using for testing Among others, i have the following questions: * does it worth the effort of making a .deb package? ( for now it's just 'git clone' and it's ready for use ) * hackit: - are patches generated like that (with diff) ok for BTS? It looks I can't preserve the file mode for example.. any better way? - should I edit the changelog? * converter: - What to do with Oneshot units? runit-init doesn't need those, but i suspect runit-sysv does.. - there are hardening features in units files, like "capabilities".. not sure those are usable in runit, but in case, should i care? - Do I need to 'set -e' in run script, or it's inherited from invoke-run? Anyway, if you want to contribute directly I can move the project under /runit namespace in Salsa. Lorenzo [Dmitry reply] I doubt it will be possible. For as little runscripts I managed to push (tor, irqbalance, acpid), there are always some quirks. Some experiments. Created runscript for mariadb. It got following line /bin/sh -c "systemctl unset-environment _WSREP_START_POSITION" || exit 160 But before patch can be submitted to maintainer, automatic testing is must. I suggest salsa.debian.org/kaction/daemons. Some suggestions on code: * you seem to invent yet-another templating engine with those #dep1# tokens. I suggest you to re-use something already established, like mustache or jinja2. bin:ionit may be interested. * please do not print "Starting $NAME". It goes to log, quite pointless and may confuse scripts/tools that want to analyze log. * please make scripts return != 0 in case of failure. `./fetch foo' exiting with 0 is very confusing. No, I do not think so. You will have to deal with Lintian and FTP team for little gain. Well, they are fine, but inconvenient. Ideal patch is one maintainer can just 'git am'. Patches generated with diff(1) or debdiff(1), require more work: * patch -p1 < your_patch.patch * git add . * git commit -m '<Invent commit message>' Personally, I find last part the most tiresome. May I suggest using git? `debcheckout`, if maintainer uses Salsa, or `gbp import-dsc apt:foo` otherwise. Extra points for making Salsa merge request in addition to BTS bug. Definitely not. Otherwise your patch will stop applying clean after a release. Also, many (myself included) use `gbp dch` to regenerate changelog before release. I think, one-shot units can be translated to #/usr/bin/env /lib/runit/invoke-run ... do stuff ... exec sv down . I ignore them. Actually, when I create runscripts, I read init.d script, not unit file. Simplier for human, impossible for machine, yeah. No, it is not. Do you think invoke-run should? I am fine with patches. Code review is good thing. PS. You know that I already got runscript into src:tor and src:acpid?
Package: runit Version: 2.1.2-33rescan1 Followup-For: Bug #935958 I have updated the code[1], all script now return nonzero in case of failure. Also there is some improvement on the hackit script. Thanks for the suggestion, I will add this in version 0.3, WIP code will be in [2]. Also I will focus on improving the converter. Didn't know about mustache, jinja2 and ionit. It's a lot of new things to learn, and I don't have the time now, maybe in the future.. Is there any instruction on how to use it? Mmm, I don't have an strong opinion on that, I think it's fine as it is now. I know it goes to log, that was exactly my idea but i didn't thought about scripts that want to analyze logs. Runit is absolutely mute and in some case it's hard for me to understand what is wrong with a service. For example, if in the log there is no `Starting NAME` message i know something is wrong with the run file; if i see a stream of `starting NAME Stopping NAME` i know there is some permanent failure condition. I'm not sure I will be able to help in solving bug that users will send about runit services without those markers. Maybe I can change the message into something less confusing like `runsv: starting NAME` and `runsv: NAME stopped` ? yes I've noticed that :) I've send a couple of patches too and have few others ready (but those need the fix for #934173). Maybe you can help with Anacron? It's QA maintained. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934231 [1] https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/nopackage [2] https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.3 Thanks, Lorenzo
[2019-08-30 02:11] Lorenzo Puliti <lorenzo.ru.g@gmail.com> https://salsa.debian.org/kaction/tor-runscript/commit/460ad44c8046fd91baf053b44ec6ce3d5215753d Key point is this line in .gitlab-ci.yml: include: - https://salsa.debian.org/kaction/daemons/raw/master/pipeline.yml So you import package on Salsa (or just fork, but Tor does not use Salsa), add CI, add runscript and tweak it until `daemons` job pass. Note of warning: tests are run in Docker, not in full virtual machine, so at least netlink sockets do not work. Maybe you will discover some other limitations :) Albeit non-ideal, this CI caught my stupid error, when I forgot to create /run/tor in runscript, because it worked on my box. Okay. Let's leave it as-is. I have two ideas: * Check for $VERBOSE variable. If you have issues with services {foo}, you can # mkdir -p /etc/sv/foo/conf # echo 1 > /et/sv/foo/conf/VERBOSE * You can write to /dev/tty63 (or some other unused tty). It is hard to copy-paste from there, though. Either way, 'runsv:' is improvement, imho. I am fine doing QA upload, but can you please add CI test? Also, I am worried about runscripts being so repetive. We already know historic study case: classic init.d scripts and init-d-script(5). At minimum, I think we need something like 'invoke-finish' in bin:runit and dh_runit to create one-line `finish` script by default. Variable 'NAME' should be exported by `invoke-run'.
Il giorno dom 1 set 2019 alle ore 15:25 Dmitry Bogatov <KAction@disroot.org> ha scritto: Ok, I'll propose some suitable solution for this before sending other patches with runscripts.
control: reassign 935958 runit-services I'm reassigning to runit-services, a converter best fits there.
control: retitle 935958 runit-services: please add a unit2run converter control: clone 935958 -1 control: reassign -1 dh-runit control: retitle -1 dh-runit: dev-tools to help generating runscripts
control: found -1 runit-services/0.5.5
After a couple of attempts in the past, I think a converter does not work for complex systemd units: * it would require runit to provide clones of many (if not all) systemd features, which are out of scope for runit * it would require to stick with systemd internal design choices, which is pointless (one would just use systemd then) However a converter that only works with simple services files is probably feasible; this way most popular services will be manually converted and shipped by this package, while a converter could cover a large(?) number of rarely used but simple enough systemd services.