Hi, > Why are these 'service' calls? Do 'service' support runit already?
No, not yet. I'm using 'service' script to test if those services, started as sysv scripts, are up. According to my testing, rsyslog, cron, udev and dbus are installed and running in the systemd testbed, so it make sense to me to test if they are running after the switch. Anyway, i'm not sure what to test to decide if the init switch is successful, ideas are welcome. As for other observations you made, i will have a look and send new patches soon Lorenzo Il giorno ven 21 giu 2019 alle ore 15:01 Dmitry Bogatov <kact...@debian.org> ha scritto: > > [2019-06-20 02:07] Lorenzo Puliti <lorenzo.r...@gmail.com> > > Hi, > > Hi! > > > while experimenting with autopkgtest i manage to write a small test > > that, starting from a systemd qemu machine, installs runit-init and > reboot into > > it, checking if there is a working getty to login with and if essential > > services (syslog, udev ..) are up. > > While the test is very simple it could be useful to have something like > > this around to make sure that the compat layer in /run/initctl will not > > get broken (by systemd) and that some future development in stage1/2 > will not > > break the runit-init boot. > > I have tested it on my pc, the last attach is the output of the test > > Sounds good, let's see. > > > Subject: [PATCH 1/3] Provide a service for a getty on serial tty > > > > diff --git a/debian/getty-ttyS0/run b/debian/getty-ttyS0/run > > new file mode 100755 > > index 0000000..31dccf6 > > --- /dev/null > > +++ b/debian/getty-ttyS0/run > > @@ -0,0 +1,8 @@ > > +#!/bin/sh > > +NAME=getty-ttyS0 > > +if pgrep -x agetty -t ttyS0; then > > + sv d getty-ttyS0 > > + echo "already another getty on ttyS0" > > +fi > > +exec 2>&1 > > +exec chpst -P fgetty /dev/ttyS0 > > As I understand it, you assume that fgetty is present. Currently, runit > does not have hard dependency of 'fgetty'. Can this runscript be made to > fallback on "getty" from util-linux? > > > >From 374b79ae1c811b668668f22f57e77a6d352670a4 Mon Sep 17 00:00:00 2001 > > From: Lorenzo Puliti <lorenzo.r...@gmail.com> > > Date: Mon, 17 Jun 2019 14:43:55 +0200 > > Subject: [PATCH 2/3] Prepare source for autopkgtest > > > > Add a stanza in debian/control and a debian/tests directory > > needed for autopkgtest > > --- > > debian/control | 1 + > > debian/tests/control | 1 + > > 2 files changed, 2 insertions(+) > > create mode 100644 debian/tests/control > > > > diff --git a/debian/control b/debian/control > > index 23300e5..0764231 100644 > > --- a/debian/control > > +++ b/debian/control > > @@ -13,6 +13,7 @@ Build-Depends: bash-completion, > > doc-base, > > Vcs-Browser: https://salsa.debian.org/debian/runit > > Vcs-Git: https://salsa.debian.org/debian/runit.git > > +Testsuite: autopkgtest > > > > Package: runit > > Architecture: any > > diff --git a/debian/tests/control b/debian/tests/control > > new file mode 100644 > > index 0000000..8d1c8b6 > > --- /dev/null > > +++ b/debian/tests/control > > @@ -0,0 +1 @@ > > Are you sure this is needed? I believe autopkgtest tests are run without > "Testsuite" field in debian/control. In my "gdbm" package, they do. > > > Subject: [PATCH 3/3] add a test for switching to runit-init > > > > Add a smoke test for the switch systemd --> runit-init > > --- > > > --- a/debian/tests/control > > +++ b/debian/tests/control > > @@ -1 +1,7 @@ > > - > > +Tests: init-switch > > +Depends: runit, > > + runit-init, > > + getty-run, > > + fgetty, > > + psmisc, > > +Restrictions: needs-root, isolation-machine, breaks-testbed > > I am positive that runit-init implies getty-run. Maybe this list could > be shinked even futher? > > > diff --git a/debian/tests/init-switch b/debian/tests/init-switch > > new file mode 100755 > > index 0000000..1e09238 > > --- /dev/null > > +++ b/debian/tests/init-switch > > @@ -0,0 +1,60 @@ > > + #!/bin/sh > > + set -e > > + > > + > > + if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then > > + if [ -d /run/systemd/system ]; then > > + init=systemd > > + elif [ -e /run/initctl ]; then > > + init=sysv > > + else > > + init=unknown-init > > + fi > > + echo "testbed is running with $init" > > + > > + if [ -e /tmp/autopkgtest-reboot ]; then > > + echo "enabling the serial getty" > > + ln -s /etc/sv/getty-ttyS0 /etc/service/ > > + echo "Done" > > + /tmp/autopkgtest-reboot-prepare runit > > + echo "reboot" > > + reboot > > + else > > + echo "testbed does not support reboot" > > + echo "can't perform this test" > > + exit 1 > > + fi > > + else > > + echo "detecting runit-init" > > + if [ -e /run/runit.stopit ]; then > > + echo "OK" > > + else > > + echo "init is not runit" && exit 1 > > + fi > > + # searching for runsvdir is pointless, since autopkgtest use serial > getty > > + #to connect with the qemu-system, and getty-S0 starts only after > runsvdir.. > > > + #echo "detecting runsvdir" > > + #if pidof runsvdir; then > > + # echo "OK" > > + #else > > + # echo "stage 2 failed to start runsvdir" && exit 1 > > + #fi > > Can we remove this commented code? > > > + echo "detecting gettys" > > + if pidof fgetty; then > > + echo "OK" > > + else > > + echo " no getty to perform login with " && exit 1 > > + fi > > + echo "Detecting active services.." > > + sv status /etc/service/* > > + service udev status > > + service rsyslog status > > + service cron status > > + service dbus status > > Why are these 'service' calls? Do 'service' support runit already? > > > + # service --status-all # not usable since some services will exit > nonzero with [?] > > + # we can test also ssh-server here if runit-init will recommend it > > Not going to happen. Many users install all recommends; pulling ssh > server without user understanding all implications is unacceptable. > > > + echo "OK" > > + echo "switching to runit init complete" > > + fi > > + echo "test done" > > Also, there are number of trailing whitespaces (are reported by git-am). > It seems that real testing will take some more time for me, since: > > (ins).. sudo autopkgtest-build-qemu unstable debian-unstable > Load spec file /tmp/tmp.MVjau2ZRda > Exec: ['qemu-img', 'create', '-f', 'raw', 'debian-unstable.raw', > '20G'] > Exec: ['parted', '-s', 'debian-unstable.raw', 'mklabel', 'msdos'] > Exec: ['parted', '-m', 'debian-unstable.raw', 'print'] > Exec: ['parted', '-s', 'debian-unstable.raw', 'mkpart', 'primary', > 'ext2', '0%', '100%'] > Exec: ['kpartx', '-asv', 'debian-unstable.raw'] > remembering /dev/mapper/loop0p1 as root > Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1'] > Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpybhuhyix'] > Exec: ['debootstrap', '--variant', '-', 'unstable', > '/tmp/tmpybhuhyix', 'http://deb.debian.org/debian'] > ERROR: Command failed: debootstrap --variant - unstable > /tmp/tmpybhuhyix http://deb.debian.org/debian > b"W: Cannot check Release signature; keyring file not available > /usr/share/keyrings/devuan-archive-keyring.gpg\nI > : Retrieving InRelease \nI: Retrieving Packages \nI: Validating > Packages \nI: Resolving dependencies of required > packages...\nI: Resolving dependencies of base packages...\nI: > Checking component main on http://deb.debian.org/d > ebian...\nE: Couldn't find these debs: devuan-keyring > devuan-baseconf\n" > b'' > Something went wrong, cleaning up! > Exec: ['umount', '/tmp/tmpybhuhyix'] > Exec: ['kpartx', '-dsv', 'debian-unstable.raw'] > > Obliviously, it is somehow related to inclusion of Devuan repos, but I > can't figure out why it affects debootstrap. > > Just grepping around did not reveal anything useful, so I will report > bug, and it may take some time before I can actually test your patch. I > am sorry about it. > > Thank you very much for your work. > -- > Note, that I send and fetch email in batch, once in a few days. >
