The officially official Devuan Forum!

You are not logged in.

#1 Re: Installation » Upgrading to Daedalus running runit-init » 2023-12-18 13:58:33

Maybe that should be 'chown -R "$USER:$GROUP" "$LOG"' to sort out the log files themselves, as well as the directory?

it was like that (chown -R) but the recursive option was removed due to symlink attacks [1] risk. But anyway I think the underlying issue is that I can't force a change in the log runscript (it's a conffile under /etc/) so there will always be a chance of a mismatch.
I'll drop an entry as NEWS file for runit to warn users.

Lorenzo
[1] For example https://github.com/OpenRC/opentmpfiles/issues/4

#2 Re: Installation » Upgrading to Daedalus running runit-init » 2023-12-14 19:18:09

Hi Geoff,

in /var/log/runit current and lock were both owned by "_runit-log adm" in the subdirectories acpid/ and ssh/
This was probably some historic set up error, but :-

cd /var/log/runit
chown runit-log:runit-log acpid/current
chown runit-log:runit-log acpid/lock
chown runit-log:runit-log ssh/current
chown runit-log:runit-log ssh/lock

soon had that fixed and after the next reboot the runsvdir command line contains the expected, clean line of dots.

Actually, 'runit-log' is being dropped and the '_runit-log' user is the right one. According to Debian policy users created by
packages should begin with _ to avoid confusion with real (uman) users. I thought I got this right but evidently I've missed
something, sorry sad
I recommend to update the log/run script of acpid and ssh with the one that is currently shipped (instead of changing permission
of current/lock), for example

cat /etc/sv/ssh/log/run

#!/bin/sh
chown _runit-log:adm '/var/log/runit/ssh'
chmod 750 '/var/log/runit/ssh'
exec chpst -u _runit-log svlogd -tt '/var/log/runit/ssh'

and then do

sv e ssh

to fix the error

#3 Re: Installation » [SOLVED] service ssh not running » 2023-10-05 21:49:20

Hi Fabien,

Using service ssh <whatever> does not do anything on daedalus.

There is no support for runit in the service wrapper, but what you are reporting
only happens if
* you have runit installed
* a runit definition for the service exists for example /etc/sv/ssh
* the service is enabled with runit ( /etc/service/ssh link exist )
otherwise the service wrapper should work

My workaround was doing touch /etc/runit/lsb.runit.sysv .

I don't recommend this unless you fully understand what it does: it will run the sysv script even if you have an active instance of the same service already managed with runit; possible side effect are:
- crash of the runit instance
- you get two instance running (only one is supervised by runit)
- the reported status of the service may be inconsistent with the one you get with 'sv status'
it also can break the upgrade of few packages - I think it was mariadb ..

The real fix would be to add runit support to the service wrapper, hopefully will happen in this cycle; for the time being I recommend to use the sv command to control services that are managed by runit.

Lorenzo

#4 Re: Hardware & System Configuration » Default dhcp client floods my syslog » 2023-09-18 14:35:30

This is a bug in dhclient script shipped with runit-services package

https://bugs.debian.org/cgi-bin/bugrepo … ug=1033542

is fixed in testing and unstable, but stable will have to wait untill the next point release hmm

To fix it, both methods suggested by Geoff will work

The version started from runit has now been removed

update-service --remove /etc/sv/dhclient

and the VM (under Xen) where I am testing it, still boots ok with just the one copy of dhclient.

Interestingly, the runit copy was earlier complaining even more about not being able to find eth1. I then spotted that the new runit setup for dhclient had a config file in conf/interfaces which contained

INTERFACES=eth1

Changing this to eth0 soon solved that.

basically disable the service or replace 'eth1' in /etc/sv/dhclient/conf/interfaces
with an interface that exists in your system (look at the output of ifconfig)

The commit that fix it is here
https://salsa.debian.org/Lorenzo.ru.g-g … e19d826ded

Said that, I see that this service is annoying a lot of people for several reason, I wonder if (for the future) it will be better to ship the dhclient service as disabled-by-default: opinions are welcome

Regards,
Lorenzo

#5 Re: Other Issues » runit-services: new package available ! » 2023-06-30 19:23:02

Hi,

As a suggestion, you may consider using

sv check dbus || exit <some_value>

instead of

sv start dbus || true

(sv start)  is equal to (sv up + sv check), so the subtle difference is that I'm forcing the wanted status to be 'up' before the check;
as for true vs exit <some_value> I'm using the latter for hard dependency and true for soft dependency. Of course I may have wrongly set a dependency as soft instead of hard..
Do you have a script that doesn't work for your use case? If yes please report it and I'll have a look again.

#6 Re: Installation » [SOLVED] Switching between init choices » 2023-06-27 19:33:55

It worked on my desktop, too.  The only problem is that I could not reboot afterwards and had to power cycle the machine.

Next time do the following:

1. install sysvinit-core (it will remove runit-init package), but don't remove the runit package (yet);
2. tell runit to reboot the system with

# /lib/runit/runit-init 6

(see man runit-init for details)

After you reboot into sysvinit you can safely remove the runit package too

Lorenzo

#7 Re: Hardware & System Configuration » [SOLVED] rsyslog, logrotate » 2023-06-21 11:32:03

Edit: I am using runit as init in case this matters.

yes it does: are you running rsyslog with a runit service or as sysv script?

If you use a runit service you may have to add a cronjob with
(assuming that your service is called 'rsyslogd')

sv hup rsyslogd

if you are using the old sysvscript, have a look at /usr/lib/rsyslog/rsyslog-rotate;
recent version of the Debian package are using code that is a noop on non-systemd systems.
if that's the case, you need to create a cron job with

if [ -x /etc/init.d/rsyslog ]; then
    invoke-rc.d rsyslog rotate > /dev/null
fi

I'm not sure if Devuan has it's own version of rsyslog package, but still worth a check

#8 Re: Hardware & System Configuration » [SOLVED][Daedalus] Laptop lid open/close issue » 2023-05-13 10:37:45

I ran all my tests also without xfce4-power-setting enabled, but I still got the striped screen

what about replacing xfce4-screensaver package with xscreensaver?

yes I am exactly him...

Ha! I remember you! I used to be on that forum too (Ombra) years ago, nice to meet you again smile

#9 Re: Hardware & System Configuration » [SOLVED][Daedalus] Laptop lid open/close issue » 2023-05-12 23:58:54

Hi,

[ sorry I don't have the solution, just some things to check ]

are you using the runit-services package, or you have your own set of runscripts or none of the two? is lightdm a runit service or is run as sysvinit script by the sysv emulation at startup?

If I g too the TTYs and I try to restart the lightdm(runit) through sudo service lightdm stop/start

if you have lightdm as runit service the right command is

sv stop/start lightdm

or (for a full restart)

sv e lightdm

I tested Debian on the same hardware, I bought to my daughter the same laptop and install Debian instead of

just to be sure, Debian + systemd?

Anyway, my suggestion is to try to replace some xfce component with some other program and see if it works:

It may be the screensaver/locker that doesn't work, for example it freezes while it should draw the window for user/passwd to unlock the screen: what are you using as screensaver/locker?
I'm using xscreensaver and it works fine with elogind (despite launching a xscreensaver-systemd), but I'm using Debian+ lxqt + runit and I'm not sure if it's lxqt-powermanagment that does the magic

another thing is to try to stop completely/kill the xfce4-power-manager daemon before closing the lid and see if elogind can handle the job;  try with elogind + xscreensaver, not sure if xfce-screensaver will work without the xfce4-power-manager

Lorenzo

OT: by any chance are you the same Danielsan of the "Debianizzati" italian forum?

#10 Re: Documentation » How to start libvirt-daemon with runit » 2023-05-10 11:16:55

The package is installed. So I would assume to find the init scripts under /etc/sv. Nothing there.

that would be the place for a run script; the sysv init script is in /etc/init.d

Lorenzo

#11 Re: Installation » install s6 init system » 2023-04-25 22:39:33

Hi,

happy to be wrong about this, but as far as I know there is no s6-init package in Devuan.. you can install the s6 package, but all the init integration is not provided, so you have to serve yourself.

According to https://www.devuan.org/os/init-freedom s6 is supported, but I cannot manage to select it.

That page says " either available or being considered for inclusion "; I think only runit and openrc are provided as alternative init *for now*

Lorenzo

#12 Other Issues » runit-services: new package available ! » 2023-02-13 22:37:02

Lorenzo
Replies: 3

Hi all,

an official package that contains runit services is finally available in unstable and testing.
Could be especially useful for runit-init users that are no expert or don't have the time
to write the scripts.
For now the number of scripts is limited [1] (other scripts will be added after
incoming Debian release); if a script for a service you are using is missing you can
file a wishlist bug report against the Debian package so that I can prioritize scripts
that are actually requested by users.
Also, reports or questions about the package are welcome too

To install just do

apt-get install runit-services

To understand how this package works I recommend to read
https://salsa.debian.org/Lorenzo.ru.g-g … ter/README
before installing.

Best,
Lorenzo

[1] available services are:
acpi-fakekey,
anacron
apache2
atd
chrony
cron
cups
dbus
dhclient
elogind
exim4
gdomap
haveged
isc-dhcp-server
lightdm
lircd
mariadb
mdadm
openntpd
postfix
preload
proftpd
rsyslog
sddm
slim
wicd
xdm

#13 Re: Packaging for Devuan » avahi-daemon doesn't have init script since v0.8-8 » 2023-02-13 21:59:14

Hi,

scripts for avahi-daemon and avahi-dnsconfd have been added
to the latest orphan-sysvinit-scripts version (0.13)

Lorenzo

#14 Re: Other Issues » runit + tor service (+apparmor) bug » 2022-07-08 10:44:32

this behavior started since latest runit upgrade in ceres, so i thought i asked you first if it's connected to the latest upgrade somehow.. (?)

Humm .. if with the last upgrade you have 2.1.2-47 there are few changes that might impact boot scripts like

runit (2.1.2-46) experimental; urgency=medium

  * ...
  * ...
  * Stage[1,3]: hook to experiment with alternative
     sets of boot scripts. Only initscript are packaged
     in Debian right now, but native sets of scripts
     can be found downstream or on github.
  * ...

but it's hard to trigger, you have to use an alternative set of boot scripts in the right directory and there must be a flag file..
I'm using initscript (from sysvinit package) to boot and shutdown the system: are you using a different set of scripts from somewhere else?
It might be that apparmor needs some initialization task or filesystem setup that are not done properly at boot.. just a random idea

Did you check the output of

/etc/init.d/apparmor status

?
and

/etc/init.d/apparmor start

or

/etc/init.d/apparmor restart

?

#15 Re: Other Issues » runit + tor service (+apparmor) bug » 2022-07-07 11:00:13

do you think i should file a bug in tor or apparmor in debian?

do you have any custom configuration on tor and/or on apparmor?
Before filing a bug report, I would try to remove + purge tor, then reinstall it and see if the problem persist;
then do the same (remove + purge) with apparmor and check again

EDIT
in case you have obfs4proxy installed, see also
https://bugs.debian.org/cgi-bin/bugrepo … ug=1004012

#16 Re: Other Issues » runit + tor service (+apparmor) bug » 2022-07-06 23:09:05

Hi,

I have tor running and it works as expected, but I don't have apparmor.
I tried to install apparmor and restart tor, and it seems to work so I can't reproduce.
( I can't reboot right now, will try later )

Do the following:
stop any running tor instance

update-service --remove /etc/sv/tor
/etc/init.d/tor stop

then try to start manually from  a root console

/usr/bin/aa-exec --profile=system_tor -- /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --Log 'notice stdout' --RunAsDaemon 0 --verify-config
/usr/bin/aa-exec --profile=system_tor -- /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --Log 'notice stdout' --RunAsDaemon 0

does it give any error?

#17 Re: DIY » Runit: dbus runscript broken » 2022-03-14 17:04:04

Hi,

I'm still affected in Debian, not sure exactly if it's a change in dbus or something else. Devuan is rebuilding dbus without systemd bits, so maybe that's why it's not affected? (just a wild guess)
In any case dbus is dropping privileges and run with the messagebus by itself, so the 'chpst -umessagebus' is useless, but as long as it doesn't cause harm..

Running xfce with lightdm here. What would you like me to check?

I'm with slim and LxQT. Not sure, as long as nobody complains, I'll just leave a warning here in case with a future upgrade things start to break.

Thanks
Lorenzo

#18 Re: Other Issues » Runit and backwards compatibility » 2022-03-14 14:21:21

(Ah! does 'wip' stand for 'work in progress', so that it doesn't match the real name?)

Exactly smile

As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).

Yes, that's the idea.

and have a check file :-

#!/bin/sh
exec dbus-send --system / org.freedesktop.DBus.Peer.Ping > /dev/null 2> /dev/null

the one that I linked in salsa.debian.org does

#!/bin/sh

test -S /var/run/dbus/system_bus_socket && exit 0

exit 1

both are fine according to my testing

Thank you for all of your work on Runit.

  smile

Reports from tinkerers and users are very helpful to improve the package but sadly I get very few on Debian..
Also I read this forum rarely, so consider to use

reportbug runit

or send a ping if you want me to join a discussion

Lorenzo

#19 DIY » Runit: dbus runscript broken » 2022-03-13 23:23:07

Lorenzo
Replies: 4

Hi all,

Just a warning to runit init users, that the dbus runscript that I provided on this forum is now broken on Debian (at least for me) and I suspect the change will hit Devuan soon: synthoms are that dbus fails to start and everything that depends on it is broken (so your DE, login manager and other dbus services too will malfunction)

in short, if you are using a dbus runscript that has an exec line like

exec chpst -umessagebus dbus-daemon --system --nofork --nopidfile

I suggest to change it to

exec dbus-daemon --system --nofork --nopidfile

Using chpst seem to break recent version of dbus as it can't access to its own socket.
Dbus is able to drop privileges by itself.

Lorenzo

#20 Re: Other Issues » Runit and backwards compatibility » 2022-03-13 22:59:06

Hi Geoff 42,

The two problems that you identified are somehow real bug in the runit package, but

Replacing /etc/sv with /etc/service in /lib/runit/run_sysv_scripts did seem to have the expected result that disabling a service in Runit caused it to be started via /etc/rc2.d on a reboot.

I don't think this is a correct solution: especially with runit as init, if a user disables a service, it should not start. A native disabled service on a runit system should definitely not start automatically at boot (even with a sysv instance); it may be different in a sysv system that uses runit as a service manager.
So the bug here is that for now, there is no tool for the sysadmin to tell the system to disable a service with runit and also with sysv (and any other init supported): it would be a job for update-rc.d, I already sent patches but they were rejected for several reason and the bug report is stuck. I plan to fix this in runit 2.1.2-46 or maybe -47.

I suspect the /etc/sv is not the correct directory to check against, as the services here have not necessarily been enabled and indeed, people like me may not have finished setting up a service!

just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.

As mentioned earlier there seem to be 2 different versions of this

sv start dbus

or

sv check dbus >/dev/null || exit 1

According to my testing

sv start dbus  ||  exit 1

will do it, or alternatively you can

sv up dbus  &&  sv check dbus  ||  exit 1

but

sv check dbus >/dev/null || exit 1

will not always work as expected, because if the requested status is down sv check can exit 0,
so before you use check make sure to set the wanted status

Also, of all dependencies, dbus is not easy to get it right, because there is a relevant time since when it reports itself as 'up' and when
it actually finishes its initialization, so you need a check file, see
https://salsa.debian.org/runit-team/run … dbus/check

Also if you use dbus from there be aware that the exec line of dbus should be

exec dbus-daemon --system --nofork --nopidfile 

without chpst. It used to work with chpst but it's broken since a recent upgrade in Debian

The other problem is that the sequencing may be wrong. So that if you have dbus set up to be run by runit and avahi has not yet been done, then avahi will fail as it will be started by run_sysv_scripts before runsv starts dbus. I am not sure what the answer might be for this.

Correct: my answer is to make native runit services available all at once, in a runit-services[1][2] package, especially services that are involved in a chain of dependency. Again, right now I'm stuck there too, but I hope it will get a sponsor in future. If not I may also consider a Devuan package if Devuan Devs allow me.

[1] https://bugs.debian.org/cgi-bin/bugrepo … bug=986656
[2] https://salsa.debian.org/runit-team/run … /tree/next   (watch out, very experimental!)
[3] https://bugs.debian.org/cgi-bin/bugrepo … ug=1005309

Lorenzo

#21 Re: Installation » runit scripts » 2021-05-29 23:21:20

denk_mal wrote:

On the internet I found this https://github.com/cloux/aws-devuan/issues/1 but unfortunally the repos from cloudx are not longer valid.

try here
https://github.com/cloux/runit-base/tree/master/etc/sv

denk_mal wrote:

I noticed that the runit stage 1 is based on the execution of rcS.d/* what looks ok for me.

    Will runit stop if some of those initscripts will fail?

    Does it make sense to implement real runit stage 1 scripts?

As long as we use sysv's initscripts for boot it works exactly as in sysv: if something is really broken during boot you'll get an emergency shell, otherwise it will spit error messages on the console and try to proceed with the boot sequence.
Implement a set o runit boot-scripts is very low priority on my TODO list simply because the advantages are very few compared with the risk of regression. The amount of work required to have a runit boot-scripts that is on par with initscripts (works on several setups and all Debian arch, including non linux kernels) is too high and I'm focusing my work on other areas where with the same amount of work users will get far more concrete advantages.
Downstream like Devuan can use the BTS to request me to adjust the dependency in a way that makes it easier to experiment with their own set of bootscript, I would consider that a valid bug.

denk_mal wrote:

in the runit stage 2 every run script should check for depencies. sysvinit scripts contains a LSB header for facility. A sysvinit script could contain for example a $syslog facility that is resolvable with rsyslog or socklog.

    what is the best way to transfer this to a runit init script?

    Is it necessary to check for LSB facilities?

    is it necessary to check for any possible facility e.g. that rsyslog has started OR socklog has started

    or is there a common way to check for e.g a started $syslog daemon indepentely from the real installed syslog daemon?

Right now there is no such thing as facilities in runit (another valid bug on BTS). This on is on top of my TODO list and I need to sort it out before uploading the runit-services package. Runit doesn't need all sysv facilities, but it needs a facility when there are 2 or more alternative runit services that have to be checked for dependencies. Syslog is an excellent example.

denk_mal wrote:

And especially for $syslog; Is it necessary to check for it if there is a log/run script for the service?

Services that can log to stdout and use svlogd don't need to depend on syslog; same for services that have their own log system (like apache2). Simple rule of thumb: if there is a log/run that execs svlogd you don't need to depend on syslog.

Lorenzo

#22 Re: Other Issues » Runit » 2021-04-06 23:35:56

andyprough wrote:
xinomilo wrote:

btw, antix did some work on runit : https://www.antixforum.com/forums/topic … lseye-iso/
seems to use antix's own packages, not the debian way of mixing sysvinit/runit..
haven't seen it yet in action, will  be trying the latest iso in the following days :
https://www.antixforum.com/forums/topic … available/

antiX has had runit ISO's available for about a year now. It's blazing fast.

As soon as I have some extra time I'll try to provide scripts for those too, except udevd because I'm not 100% sure that it's safe to do all stage 3 with udev not running

Lorenzo

#23 Re: Other Issues » Runit » 2021-04-06 23:31:11

fsmithred wrote:

Update:  I forked live-config to create live-config-runit which sets up console autologin in the live session. The code for that is in /lib/live/config/0190-runit. It works, but I did not replace the live-config init script with runscripts.

Today I tried making runscripts for live-config. It's set up as a one-shot, and it runs, but it does not run early enough. A comment in the init script says it must start before mountkernfs and in my sysvinit system, there is rcS.d/S01live-config which starts before S02mountkernfs. That link is not present in the runit system.

If it really need to run that early it need to be a script in /etc/rcS.d/ so keeping the sysvinit scripts is the most straightforward thing to do.
In case the sysvinit comment is wrong, and it can be run later, like after all the stuff in rcS.d, but before certain services (like gettys and login manager) you have two options:

  • ship as a sysv script, but in runlevel 2, and make sure that a runscript with the same name in /etc/sv/ never exists.
       This way it is granted that your script runs before any native runscript (look at the code in stage 2)

  • have it as a oneshot runscript -- you need to convert the script into a proper runscript, and then have the gettys and the
       login manager depends on that service. IMHO it doesn't worth the effort to have runscripts for services where there is nothing
       to supervise (no longrun) as you are adding (uneeded?) complexity to achieve the same result as with a plain sysv script.
       Anyway if someone is curious and wants to experiment, in runit, to do a oneshot, have a line in the run file that does
        ' sv one yourservicename'   otherwise your service will keep restarting when it's done which is pointless.
        Also you need to design some kind of readiness protocol, the easy way is to touch a file into run at the very end of your runscript, like
        ' touch /run/myservice.ok', then write the check file to test for the existence of myservice.ok and exit nonzero if it doesn't exists.
        Then make all services that you want to run after yourservice depends on yourservice with a line like
        ' sv start yourservicename  &&  sv check yourservicename  || exit 1 '
        As you see, if it's not for playing, the sysvinit script it's likely the option you want to chose

Hope the above answer your questions, it case it doesn't just ask again smile
Lorenzo

#24 Re: Other Issues » Runit » 2021-04-06 22:29:33

Geoff 42 wrote:

Are you using runit under SysVinit or are you using runit-init. With the latter you need to do some setting up of getty. When I do that in a VM under Xen, I have to set up a getty on hvc0 for the console.

Geoff

Hi,

[ also looking at the other thread  https://dev1galaxy.org/viewtopic.php?id=3628&p=2 ]
The getty-run package ships with a getty-S0 on serial that is disabled by default. Enabling it is usually enough for other virtualization environment like Qemu or Docker, but I've never run Xen so I don't know.. is the getty on hvc0 a requirement for Xen, or anyway a commonly required feature?
If that is the case I can ship a getty on hvc0 too so that the only thing left to do is to enable it.
Let me know!

Thanks,
Lorenzo

#25 Re: Other Issues » Runit » 2021-02-26 14:54:57

Hi all,

Are these scripts ok and are they missing anything, in the right locations?

Runit services in Debian and Devuan are stored under /etc/sv/ so you want to have for example

/etc/sv/network-manager/run

My run dirs are named the same as the init script. I don't know if that matters.

Yes it matters: during the boot sequence a script starts all sysv script that are enabled in Sysv runlevel 2, but when
a runscripts in /etc/sv/ with the same name exists the script is skipped (as it will be managed by runit).
Having multiple instances of the same daemon can cause conflicts or other weird malfunctioning, I suggest to keep the
same name of the sysv script.

About the runscript:

#!/bin/sh -e
exec 2>&1
exec chpst -u root NetworkManager

I don't use networkmanager, so I'm not able to test it but there are a couple of things that seems wrong to me:

You need the --no-daemon option: as a general rule runit can't supervise a service that runs in background (or daemonize), you need to use an option to run in foreground;

Is there a reason why are you using chpst -u root ? The service is already run as root, there no need to use chpst here.
Same for the log service.

There is also another problem, network manager is a Dbus-service, so you technically need to specify the dependency of this service on Dbus. In your test case will work also without the dependency, because dbus is already started as sysv service, but if you are going to have dbus managed by runit, this one will fail to start.

Something like the following could work ( not tested)

#!/bin/sh -e
## uncomment the following if you have dbus as runit service
#sv start dbus  &&  sv check dbus  ||  exit 1
exec 2>&1
exec /usr/sbin/NetworkManager --no-daemon

Hope this helps,
Lorenzo

Board footer

Forum Software