Artix Linux Forum

This thread will be used as a tracker for a fully-working Runit support. This thread is constantly improved as time goes.

Installation

See https://wiki.artixlinux.org/Runit/Runit

Note for anyone with encrypted partitions: unlike OpenRC, which reads encrypted partition from /etc/conf.d/dmcrypt, Runit reads it from /etc/crypttab. Make sure you do changes as needed.

Differences between Runit in Artix and Runit in other system
Unlike Void's Runit and Gentoo's Runit, Artix's Runit reads /run/runit/service by default. So, while you can use their wikis as reference, keep in mind that when you symlink a runscript, make sure to do it to /run/runit/service to make it work with runit.

Differences between OpenRC and Runit
TBA

Known Issues
TBA

References

• https://smarden.org/runit
• https://wiki.voidlinux.eu/runit

Any help would be appreciated. Thanks.

there is a separate package I believe called artix-runit-scripts https://github.com/artix-linux/runit-artix/
The readme reads:

I believe that runit can run ontop of openrc, redundant as a second init, or as supervisor of the existing init system.
I am not sure what happens if you remove openrc leaving runit behind.  As you say if elogind fails till there is a substitute that would be a  problem.  Do you know what void has in place of it, or have they forked their own version?

runit-artix is the initscript needed for runit (since runit package only provides the binaries), runit depends on runit-artix.


Sure, the Gentoo Wiki has some guides so runit can be used as the service supervisor for OpenRC. In fact, Runit can replace OpenRC as an init, while retaining OpenRC's feature as service supervisor. See these files (https://github.com/cromnix/packages/tree/master/runit/runit-cromnix-openrc) for more information.


I'm running Artix with Runit right now. I need to mount a cgroup with the name OpenRC so elogind can run. (The source of the problem seems to be the --with-cgroup-controller=openrc build flag in Artix's elogind PKGBUILD)

Void still uses ConsoleKit2 by default, but they have vanilla elogind package in their repos.

A little bit of update since 3 months ago.

Most of OpenRC's scripts in system should have its runit equivalent. However keep in mind that most of these are untested, especially wpa_supplicant. Any help in testing would be appreciated. I'm also still working for [world] and [galaxy] equivalent runscripts from OpenRC to runit.

WARNING: Before PR #4 (https://github.com/artix-linux/runit-artix/pull/4) is merged and rolled out to packages, Remove OpenRC from your system (that is, if you want to use runit instead) or alternatively, remove getty instances from OpenRC if you still want to use OpenRC to prevent collision between getty instances spawned by runit and OpenRC.

This is a good candidate for a wiki article on runit. @konimex PM me a password and I'll open you an account (once I fix the breakage php-7.2 caused in the wiki auth mechanism).

Sure, PM sent.

---

Alright, after looking at some documentations for runit and s6, it is possible for daemontools-style scripts to have similar runscripts (hence, runscripts-{system,world,galaxy} as opposed to runit-{system,world,galaxy} or s6-{system,world,galaxy}), however this behavior is untested. Also, in some runscripts, the commands for dependencies are strictly runit (starting a service with dependency uses sv (http://smarden.org/runit/sv.8.html) which is exclusive to runit) and s6 uses s6-svc (http://skarnet.org/software/s6/s6-svc.html) with a very different command, I'm not sure what to do here so any help would be appreciated, thanks.

ATM the wiki is open to edit. Just use your username if you want credit for your edits.

It seems I cannot add (or edit) any articles at the moment, everytime I tried to create an article it just redirects to a blank page.

---

As of now most runscripts in [world] and [galaxy] should be available in the testing repositories. I'll work on documentations once the wiki problem is resolved.

If your runit-artix package is at version 20180108 or newer, all runit binaries has moved to /usr/lib/runit-artix/bin. Please symlink all binaries there to your standard /usr/bin directory. However, if you still have OpenRC installed, make sure to make the symlinks for halt, shutdown, poweroff and reboot in /usr/local/bin instead for easier deletion..

Will look into it as soon as I finish with the mail server.

Huge thank you for making this happen! I've been using runit-only Artix for a day now and so far everything is working flawlessly (I migrated from arch's systemd straight to artix runit).

 I have tried installing the runit, but to no avail. I tried a live iso installation, followed all the steps of the wiki, loaded the grub, but it did not reach the login screen, I tried with slim, lxdm and lightdm and it did not work. I tried the startx and nothing, I also have no internet connection after the installation, even following the steps for ip static.
  Then I tried with an installation with openrc, change to runit and after following the steps of the wiki, and installing artix-runit, I uninstalled openrc and again neither lxdm or slim login screen, again without internet. I'm with internet via ethernet cable, it's failing something, but I have not figured it out yet. I will follow this topic to know of news.  :'(

Can you provide your steps on how to activate LXDM/LightDM? SLiM's runit-scripts are not yet provided, but both LXDM and LightDM should work normally.

Also, how do you configure your networking? Have you seen this page? (http://wiki.artixlinux.org/runit/NetworkConfiguration)

I'll make a migration guide later.

 Yes I followed the wiki, either for the version of installing runit in an Openrc installation. Wants for the net install version only with runit. And always following the wiki, the errors were similar without internet access cable or wifi and never got to the display manager, lxdm, slim, sddm, xdm. As I said I always followed the steps of the wiki and did not solve. I wanted to test an Artix with runit, but I have to make do with Void.

How about S6, have you ever tried it?
In theory S6 is better than runit, in practice I can't notice any difference in performance.
You can install obarun then keep obarun repositories on top for S6, use artix (instead of arch) below for everything else.  Void is a good system but the variety of pkgs you find here you may never see in void.  If you think void boots up fast wait until you see obarun.

Someone is probably going to scream at me for promoting an other distribution here, but it is a safe way to use S6 in artix, till someone makes the S6-bundle a plug and play item here.  Just make sure you indicate that you have done so, when you are asking for help, so people know who to blame for the problem :)

Again, without any logs (or how to reproduce things), I cannot help you.


I have tried s6 some time ago, and while I have interest in supporting s6 for Artix, I have several constraints.

1. I have to make time for trial-and-error, but I can't afford to do so since I have a very hectic schedule in uni atm, and I have to build a support for building iso for runit systems, and fix possible bugs that happened in the runit builds I maintain.

2. S6 requires two different programs (execline and skalibs), as opposed to runit.

3. I need to find a way so Artix can switch init between two existing init systems easily. (I have a prototype, but I cannot consider it production ready since it isn't polished)

4. Someone had tried to do it, and I'll just have to follow the footsteps when I finally step into s6 in case there's no one to step up.

I will eventually try s6 for Artix, but not now, or any time soon.

Please give konimex a little time with his runit packages.
Once these are finished, fine, matured, we gonna focus on supporting iso building with runit.
buildiso used to support systemd, apart from openrc, and it basically has all the stuff in it to easily throw in runit.
We just haven't done any work with runit iso, and I will definitely be the first who built runit iso and tried, apart from konimex, hehe.

If you are talking to me, I was responding to @slblxs not @konimex
I have been following the development of konimex's work and appreciate the effort.
I was suggesting an alternative experiment to slblxs while his runit attempts were failing.

Anyway, here is some good bed-time reading to what I am referring to https://skarnet.org/software/s6/s6-svscan-1.html

On the other hand, running the same desktop, as far as I can tell the same services, daemons, etc. between void, obarun, and artix, in terms of initial resources used at starting idle the score is in the same order.  Small differences and a fraction of what it is with systemd, but runit (for reasons I can't yet explain) comes 1st, S6 a close 2nd, and sysvinit/openrc third.  I think there are more advantages in sticking with one of them, learning to fine tune it, than to be switching back and forth like it is a tire brand on a motorcycle.  Good analogy?  It is what keeps you and your vehicle off the pavement unless speed comes to 0 and you put the stand down.

NOTICE TO ALL RUNIT USERS:

We are now migrating our naming scheme from package_name-runscripts to package_name-runit.

If you are using [gremlins], you should notice that pacman will ask if you want to replace the associated runscript package with runit package, answer yes.

Also, we are moving our available runit-scripts directory from /etc/sv to /etc/runit/sv, this is done to ensure there are no collisions if we add support for s6 systems.

This migration will be completed and the new package should land in [system], [world], and [galaxy] respectively at the end of March or the beginning of April.

In the meantime, all new packages with new naming scheme and new directory are on hold in [gremlins] and [galaxy-gremlins], respectively.

COMPLETED:
- [system], now on [gremlins]

IN PROGRESS:
- [world], some on [gremlins]

NOT STARTED YET:
- [galaxy]

 I'm going to wait a little longer and then try to install runit from scratch. 8)

That is great news I just love S6 and runit, But will wait a while before doing a clean install

 I installed artix openrc in a virtualbox, I followed the wiki to install runit. I did all the steps, but when I go to uninstall openrc, this message appears.

[sl slb]# ln -s /usr/lib/runit-artix/bin/halt /usr/bin/halt
ln: failed to create symbolic link '/usr/bin/halt': File exists
[sl slb]# ln -s /usr/lib/runit-artix/bin/pause /usr/bin/pause
[sl slb]# ln -s /usr/lib/runit-artix/bin/shutdown /usr/bin/shutdown
ln: failed to create symbolic link '/usr/bin/shutdown': File exists
[sl slb]# ln -s /usr/lib/runit-artix/bin/modules-load /usr/bin/modules-load
[sl slb]# ln -s /usr/lib/runit-artix/bin/zzz /usr/bin/zzz
[sl slb]# ln -s halt /usr/bin/poweroff
ln: failed to create symbolic link '/usr/bin/poweroff': File exists
[sl slb]# ln -s halt /usr/bin/reboot
ln: failed to create symbolic link '/usr/bin/reboot': File exists
[sl slb]# ln -s runit-init /usr/bin/init
ln: failed to create symbolic link '/usr/bin/init': File exists
[sl slb]# 
[sl slb]#  /etc/sv/NetworkManager/run
bash: /etc/sv/NetworkManager/run: No such file or directory
[sl slb]# 
   

 And then

[sl slb]# pacman -R openrc
a verificar dependências...
erro: falhou ao preparar a transação (não foi possível cumprir as dependências)
:: acpid-openrc: ao remover openrc quebra a dependência 'openrc'
:: alsa-utils-openrc: ao remover openrc quebra a dependência 'openrc'
:: cronie-openrc: ao remover openrc quebra a dependência 'openrc'
:: dbus-openrc: ao remover openrc quebra a dependência 'openrc'
:: dhcpcd-openrc: ao remover openrc quebra a dependência 'openrc'
:: haveged-openrc: ao remover openrc quebra a dependência 'openrc'
:: kmod-openrc: ao remover openrc quebra a dependência 'openrc'
:: mdadm-openrc: ao remover openrc quebra a dependência 'openrc'
:: ntp-openrc: ao remover openrc quebra a dependência 'openrc'
:: openrc-settingsd: ao remover openrc quebra a dependência 'openrc'
:: openssh-openrc: ao remover openrc quebra a dependência 'openrc'
:: rpcbind-openrc: ao remover openrc quebra a dependência 'openrc'
:: rsync-openrc: ao remover openrc quebra a dependência 'openrc'
:: syslog-ng-openrc: ao remover openrc quebra a dependência 'openrc'
:: wpa_supplicant-openrc: ao remover openrc quebra a dependência 'openrc'
[sl slb]# 
  

 I apologize, but the system is in Portuguese so the answer of the dependencies is in Portuguese. How can I solve it without breaking the system?

Change the ln -s to ln -sf, this will foce it to replace those symlinks.

 Thanks for the help, but I continue without accessing the login screen and without internet. Here photos of how it is;

https://imgur.com/a/FqZ7F
 https://imgur.com/a/EI0N8

As far as internet goes, you need to install the runit scripts for networking. In my particular case I needed NetworkManager and dhcpcd. On a notebook you would probably need something like wpa_supplicant for wifi. Without these service scripts running internet cannot be achieved.

Sorry for late reply. It's midterms right now so I'm quite busy.

AFAIC Xorg is not a runit issue (unless you're trying to use a DM) but for networking, see also: https://wiki.artixlinux.org/Runit/NetworkConfiguration

Also, I'm migrating the runitscript folders so expect the directories to be changed and the wikis to be updated at the end of March/beginning of April.


Did you see the wiki page for runit?

 Yes @konimex, I followed every step of the wiki, even in the wakeup call to leave the network manager functional. Even before rebooting, I took a look at the Void linux wiki. But still, the same problems remain, I'll wait a few weeks and then try again. Thanks again for your help.

Hey guys. An update here.

As I said earlier some time ago, we are moving our whole runitscripts to /etc/runit/sv from /etc/sv, also we are changing the naming schemes from "package-runscripts" to "package-runit".

Today, we have finished migrating our runit (now [system], but [world] and [galaxy] should be finished before midnight UTC) packages to its own PKGBUILD as I promised (at the end of March or the beginning of April).

If you're on [gremlins] and you don't have any runitscript in [galaxy], you probably don't have to do this again. However, if you are on stable or if you have a runitscript in [galaxy] installed, you will need to move your symlinks.

For example, if you have the package "openntpd-runit" (used to be "openntpd-runscripts"), overwrite your symlink:

ln -sf /etc/runit/sv/openntpd /run/runit/service

The other changes are just some internal restructuring on our runit-artix stage 3. That's it.

Any questions? Feel free to ask!


I think I forgot a step in the docs. Did you install the package "runit-artix"?

I just wanted to say thanks for the work on runit support. I've just started testing it out on one of my machines and I really like it a lot so far. Switching was really simple and I'll be sure to migrate everything else soon.

Just a quick question. Is there any reason to be concerned about this error? On boot, I get this message and I don't know why.

[    3.670727] elogind[605]: Failed to connect to system bus: No such file or directory
[    3.670770] elogind[605]: Failed to fully start up daemon: No such file or directory

As far as I can tell, this does absolutely nothing. I have dbus and elogind up and running just fine over here. I don't know why it's giving me that message unless I'm just forgetting a service.

The only reason for that is because runit services are started in parallel, elogind immediately looks for a dbus service, while dbus was still initializing. So, no, that error should not concern you, but I'm looking for way to turn that message off.

Ah, that makes sense. It might not be a clean fix, but I just slapped "sleep 1s" before the dbus check and there's no error message for me anymore.

A new runit-artix package (20180414) has been released and is now in [gremlins].

An important change in this release is binaries for pause, modules-load, and zzz has been moved back to /usr/bin, this is after I determined that there are no packages in Artix that uses the same binary names as runit-artix.

We'll move it to [system] this Monday.

If you symlinked /usr/bin/pause, /usr/bin/modules-load, and /usr/bin/zzz, please remove it before running pacman -Syu.

We're sorry for your inconvenience.

Also, we're testing a new runit-only image for Artix, expect a new post in the upcoming week.

A runit release iso is not too far away, some minor issues to sort out.
Great job konimex.

(https://s17.postimg.cc/6ctmfsoqj/Screenshot_20180415_172927.png) (https://postimg.cc/image/6ctmfsoqj/)

Would it possibly ever be one installer that would provide the choice of the init system?  It would be one installer for two distributions and I don't think this ever existed.
Fascinating when most others struggle with one.

Personally I'm not a fan of Calamares (manual install using the old strapping way gives me more control), but it should be possible. In fact, I'm aiming so both openrc-init and runit-init can be placed in the same iso, and give choice to users on which init to use during boot.

Not with calamares as it is.

https://wiki.artixlinux.org/Runit/Runit    -->
After installing runit, make sure to copy these directories to /usr/bin. 

This seems a little vague, which directories? 

ls -la /usr/bin
lrwxrwxrwx 1 root root        10 Apr 18 17:26  init -> runit-init
lrwxrwxrwx 1 root root        29 Apr 18 18:03  halt -> /usr/lib/runit-artix/bin/halt
lrwxrwxrwx 1 root root        30 Apr 18 18:03  pause -> /usr/lib/runit-artix/bin/pause
lrwxrwxrwx 1 root root        33 Apr 18 18:03  shutdown -> /usr/lib/runit-artix/bin/shutdown
lrwxrwxrwx 1 root root        37 Apr 18 18:03  modules-load -> /usr/lib/runit-artix/bin/modules-load
lrwxrwxrwx 1 root root        28 Apr 18 18:03  zzz -> /usr/lib/runit-artix/bin/zzz
lrwxrwxrwx 1 root root         4 Apr 18 18:04  poweroff -> halt
lrwxrwxrwx 1 root root         4 Apr 18 18:04  reboot -> halt
lrwxrwxrwx 1 root root         3 Apr 18 18:07  bin -> bin

Does this look right?

ls -al /etc/runit/sv
total 60
drwxr-xr-x  6 root root 4096 Apr 18 17:14 ..
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty6
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty4
drwxr-xr-x 15 root root 4096 Apr 18 17:14 .
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-console
drwxr-xr-x  2 root root 4096 Apr 18 17:14 sulogin
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-ttyUSB0
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-ttyS0
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty5
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty2
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty1
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-generic
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-ttyAMA0
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-tty3
drwxr-xr-x  2 root root 4096 Apr 18 17:14 agetty-serial

I did what the wiki said, forced removal of openrc otherwise it will not be replaced, edite the init line in grub,
then system would halt after trying to boot.  I only caught a couple of lines from the top that looked like runit before it halted.
chroot was not easy either, it seems as it lost the ln for bash so artools-chroot /mnt  /usr/bin/bash   eventually worked
there seems to be a directory instead of a link called bin that had a link to the init system in it, I have no clue how it got there.

lrwxrwxrwx  1 root root   10 Apr 16 10:54 init -> runit-init

I took all my service scripts (thinking anythin with -openrc will have an -runit) and rename them into -runit trying to install them:

error: target not found: inetutils-runit
error: target not found: kmod-runit
error: target not found: openvpn-runit
error: target not found: eudev-runit
error: target not found: displaymanager-runit
error: target not found: cryptsetup-runit

The rest were ok.

Sorry, the wiki is not yet updated. I've updated the wiki.


Not "directory" per se, but "files". That's correct.


Yes.


Please elaborate.


Most of them are handled directly by runit's stage 1 so it doesn't make sense to add them manually. As for Display Manager, the service script for the respective DM (lxdm-runit, gdm-runit) should suffice.

The system is locked in read only mode, somehow, and /usr/bin /bin link is missing
The only way to chroot is if I specify where a shell is #artools-chroot /mnt /usr/bin/bash
When I attempt to boot in either normal or recovery I get 2-3 lines on top (same as I did with void) and within 2-3" the systems shutsdown.  It is so fast I doubt runit has saved any logs, but I am willing to look if you tell me where.
I did add the line in grub under linux UUID...... for the init system as the wiki said yesterday
The only problem I had was that OpenRC did not want to move over for runit so I had to force runit and remove openrc afterwards, as they were in conflict.

That sounds like something is wrong with your system, but not from the runit side. And because /bin is owned by the filesystem package, it should be there and symlinks to /usr/bin. You don't forget installing the runit-artix package, right?


Were you trying to install a fresh instance? Why are you trying to chroot?


Runit doesn't save any logs for stage1, but again, maybe you forgot to install the runit-artix package.

No both runit and runit artix were installed, also all the relevant -runit files except for the services I didn't find any, as listed above.
The system never had a problem before, sddm, openbox, and I followed all steps.
It was updated/upgraded just the day before.
Why am I chrooting?  Because instead of boot it just shutsdown.
The /usr/bin link was there, for sure, before the runit installation.  I have no idea what went wrong, I just followed the steps on wiki like you mention earlier on the post.  When I tried to reboot  --- puff ---  nada --

Should I try through chroot (artools) to reinstall openrc ?

I just left it as it was so I don't do anything to harm it more.  How do you recreate the link from chroot?  It says it can't because it is a read only system.

I cannot reproduce this on any of my machine or VMs.
Can you test this on a VM and see if your problem is also there?

It shouldn't be read-only because root is remounted rw or you'll be dropped to emergency shell.

1  https://smarden.org/runit  that you have in the wiki is dead

After figuring out a way to remake the symlink for /bin I also thought that my problems may be for using gremlins.  So I # gremlins and got runit and runit-artix from system, 1 version back each.  This is all artools-chroot.  When I replaced the link for /bin and exited chroot worked normally whithout specifying a path for bash.
The services *-runit that I had installed had to be reinstalled, so I did that.  At first they were giving me some trouble because of conflict with openrc, but openrc was removed since yesterday.  What was left were 3-4 runscripts that didn't have a runit equivalent.  So I removed them and reinstalled all -runit scripts by force.
So finally I reboot to the system and all is functional but no network.  Somehow networkmanager-runit was not there.
No halt or reboot would work either.  Neither killing #1 worked.  But ctrlaltdel at console did work, I am glad that was symlinked.
I chrooted again and installed networkmanager and corresponding -runit file and tried it again.  No network yet, so this time I downloaded the wiki page but the link for further reference as listed above does not exist.


I just have a hard time understanding how anyone used these particular packages and got the system to work.
To double check the problem went back to gremlins and reinstalled your artix runit pkg and runit istelf and it did the same exact thing again.  It removed the bin link, made a bin directory and placed the init link inside the /bin.
So I moved the init link into /usr/bin and recreated the bin link to /usr/bin
It is your package that screwes this up, not me!

I am getting close to putting this together but it is a homemade garage job at this stage.  It is wearing me down!


Here is a piece of the Void grub.cfg

linux	/boot/vmlinuz-4.15.15_1 root=UUID=*********************  ro  loglevel=1 slub_debug=P page_poison=0 net.ifnames=0
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initramfs-4.15.15_1.img

and this is void's fstab

UUID=******************************	/	ext4	defaults,noatime	0	1
tmpfs						/tmp		tmpfs	defaults,nosuid,nodev 0 0

That page poison=0/2 I think zeros out ram for meltdown/spectre protection.  Irrelevant to runit I think

Yes, go reproduce what I am saying with the gremlins pkgs.  It doesn't say anywhere that those are useless.
This was the source of all this trouble, once the /bin link is broken any software related to pacman etc. is bound to mess installation and removal up as it is calling /bin/bash etc.. that don't exist.

I don't like vms because they are just vms not 'real" systems on real hardware. 

I managed to get s6 working on a standard new manjaro-lxde installation.  It rocks :)  Read my article on sysdfree

I gave up, everything working but can't get networkmanager to work.
I did start the service, it is there in /run/runit with all the other services, eth0 seems active, has a mac address, no connection.
Maybe I should try something like connman ?
Tired of rebooting though.

Instead of making 3 separate post, can't you just edit your latest post in case there are no new replies? Seriously.

I want to check if we have the same runit-artix package. Do you have the latest runit-artix installed in [gremlins] (20180414-4)? Here's the PKGBUILD (https://github.com/artix-linux/packages/blob/master/runit-artix/repos/testing-x86_64/PKGBUILD).

The 20180414-2 package is faulty, but it should be fixed in the latest 20180414-4, your mirror seems not to be syncing with our builds.

Try http://smarden.org/runit/


I don't know. Try to ask one of the early runit testers @CustomerServiceRobot.

Also, if you want something stable, don't use [gremlins].

Did you install networkmanager-runit? If you have, try to check what's wrong with nmtui. NetworkManager is out of this thread's scope since "works on my machine". You may want to go to the IRC.

This is live now 10:42 GMT 11:42 London time

1 gremlins/runit-artix 20180414-2 (init) [installed]
    Runit initscripts for Artix
2 system/runit-artix 20180414-1 [installed: 20180414-2]
    Runit initscripts for Artix

is your -4 pkg in goblins?

This is what I installed before with chroot when I got a net connection, on top of the networkmanager and wicd (that never worked) that I had before.

[2018-04-20 11:43] [ALPM] installed libnfnetlink (1.0.1-2)
[2018-04-20 11:43] [ALPM] installed libnetfilter_conntrack (1.0.6-1)
[2018-04-20 11:43] [ALPM] installed dnsmasq (2.79-1)
[2018-04-20 11:43] [ALPM] installed dnsmasq-runit (20180226-1)
[2018-04-20 11:43] [ALPM] installed dhcp (4.4.1-4)
[2018-04-20 11:43] [ALPM] installed dhcp-runit (20180226-1)

I had to activate eth0 manually though, all that appeared in ifconfig was lo when I logged in.

I don't know which actually helped and which is unnecessary yet, I just loaded things to get a connection somehow.

1 more question:  Is there anything around the original networkmanager used by artix (at least on the older installers) that is OpenRC dependent and I may have taken it off by removing OpenRC?
I noticed that:

system/netifrc 0.6.0-1 (base)
    Gentoo Network Interface Management Scripts

Will not install  unless I remove runit-artix  (that deffective -2 version that I am currently running on after patching the /bin link issue).

There we go. It seems mirror1 is acting up again. It doesn't sync anything since 16 April. -4 is currently in gremlins, but the mirror isn't syncing right now.


NetworkManager should be init-agnostic (unless you're using systemd, ofc). netifrc is a OpenRC-specific package.

:)

I've never seen this before, my networking is ipv6 only, I can reach artixlinux.org but can't reach startpage ecosia or duckduckgo  :)

 ping -c 4 2a01:7e01::f03c:91ff:febc:322
PING 2a01:7e01::f03c:91ff:febc:322(2a01:7e01::f03c:91ff:febc:322) 56 data bytes
64 bytes from 2a01:7e01::f03c:91ff:febc:322: icmp_seq=1 ttl=52 time=83.8 ms
64 bytes from 2a01:7e01::f03c:91ff:febc:322: icmp_seq=2 ttl=52 time=84.0 ms
64 bytes from 2a01:7e01::f03c:91ff:febc:322: icmp_seq=3 ttl=52 time=82.9 ms
64 bytes from 2a01:7e01::f03c:91ff:febc:322: icmp_seq=4 ttl=52 time=83.7 ms

--- 2a01:7e01::f03c:91ff:febc:322 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 82.905/83.622/84.070/0.522 ms
[artix2@7010 ~]$ ping -c 4 51.255.48.78
connect: Network is unreachable

Unless ww4 is declared and DOD brought down the internet (ipv4)  :)

I don't know if this is intended by NM, but it seems NM just stopped trying IPv4 after detecting an IPv6 IP. A workaround would be use NM with dhclient as its DHCP resolver. Or using nmtui, in Wired connection (particularly in IPv4 Configuration Section), enable the "Require IPv4 addressing for this connection" checkbox.

This is out of scope of this thread so I suggest you to go to #artix IRC channel.

I know it is not relevant to the thread but never in 9 months had I ever had networking issues till I switched to runit, so it is related.
On my other artix installation, a clone of the original, netifrc is installed, so I am wondering whether it is related.

Personally, I've always found NetworkManager to be a giant pain that mysteriously breaks. I just use dhcpcd and the wpa_supplicant hook.

warning: dnscrypt-proxy-runit: local (20180406-1) is newer than galaxy-gremlins (20180330-1)


# yaourt runit artix
1 gremlins/halt 0.2-1 [installed]
    Artix Linux's wrapper program for OpenRC and runit's shutdown scheme
2 gremlins/runit-artix 20180414-4 (init) [installed]
    Runit initscripts for Artix
3 system/runit-artix 20180414-1 [installed: 20180414-4]
    Runit initscripts for Artix

It is broken again.  After the the new package (runit-artix-----4) came in, together with other upgrades, it did the same exact thing again, it removed the /bin link, and then I replaced it yet again. 
Now on boot it says it is waiting for the uuid=...  (the root partition) and then it says (10s) it is not responding and crashes at stage 1.

I asked before and you said you have modified the wiki, although I did not notice anything being modified.

https://wiki.artixlinux.org/Runit/Runit#runit-artix


These files has no reference, which files are you talking about?

$ pacman -Qi
Name            : runit-artix
Version         : 20180414-4
Description     : Runit initscripts for Artix
Architecture    : x86_64
URL             : https://github.com/artix-linux/runit-artix/
Licenses        : custom:CC0
Groups          : init
Provides        : runit-init
Depends On      : procps-ng  awk  runit  sh  eudev  opentmpfiles
Optional Deps   : None
Required By     : elogind-runit
Optional For    : runit
Conflicts With  : openrc
Replaces        : None
Installed Size  : 169.00 KiB
Packager        : Unknown Packager
Build Date      : Fri 20 Apr 2018 06:33:01 AM WIB
Install Date    : Fri 20 Apr 2018 06:33:36 AM WIB
Install Reason  : Installed as a dependency for another package
Install Script  : Yes
Validated By    : None

$ pacman -Ql
runit-artix /etc/
runit-artix /etc/runit/
runit-artix /etc/runit/1
runit-artix /etc/runit/2
runit-artix /etc/runit/3
runit-artix /etc/runit/core-services/
runit-artix /etc/runit/core-services/00-pseudofs.sh
runit-artix /etc/runit/core-services/01-static-devnodes.sh
runit-artix /etc/runit/core-services/02-kmods.sh
runit-artix /etc/runit/core-services/02-udev.sh
runit-artix /etc/runit/core-services/03-console-setup.sh
runit-artix /etc/runit/core-services/03-filesystems.sh
runit-artix /etc/runit/core-services/04-swap.sh
runit-artix /etc/runit/core-services/05-misc.sh
runit-artix /etc/runit/core-services/08-sysctl.sh
runit-artix /etc/runit/core-services/99-cleanup.sh
runit-artix /etc/runit/crypt.awk
runit-artix /etc/runit/ctrlaltdel
runit-artix /etc/runit/functions
runit-artix /etc/runit/rc.conf
runit-artix /etc/runit/rc.local
runit-artix /etc/runit/rc.shutdown
runit-artix /etc/runit/reboot
runit-artix /etc/runit/runsvdir/
runit-artix /etc/runit/runsvdir/current
runit-artix /etc/runit/runsvdir/default/
runit-artix /etc/runit/runsvdir/default/agetty-tty1
runit-artix /etc/runit/runsvdir/default/agetty-tty2
runit-artix /etc/runit/runsvdir/default/agetty-tty3
runit-artix /etc/runit/runsvdir/default/agetty-tty4
runit-artix /etc/runit/runsvdir/default/agetty-tty5
runit-artix /etc/runit/runsvdir/default/agetty-tty6
runit-artix /etc/runit/runsvdir/single/
runit-artix /etc/runit/runsvdir/single/sulogin
runit-artix /etc/runit/shutdown-services/
runit-artix /etc/runit/shutdown-services/00-stop-services.sh
runit-artix /etc/runit/shutdown-services/01-random-seed.sh
runit-artix /etc/runit/shutdown-services/02-hwclock.sh
runit-artix /etc/runit/shutdown-services/03-stop-udev.sh
runit-artix /etc/runit/shutdown-services/04-killall.sh
runit-artix /etc/runit/shutdown-services/97-mount-ro.sh
runit-artix /etc/runit/shutdown-services/98-deactivate-crypt.sh
runit-artix /etc/runit/stopit
runit-artix /etc/runit/sv/
runit-artix /etc/runit/sv/agetty-console/
runit-artix /etc/runit/sv/agetty-console/conf
runit-artix /etc/runit/sv/agetty-console/finish
runit-artix /etc/runit/sv/agetty-console/run
runit-artix /etc/runit/sv/agetty-console/supervise
runit-artix /etc/runit/sv/agetty-generic/
runit-artix /etc/runit/sv/agetty-generic/finish
runit-artix /etc/runit/sv/agetty-generic/run
runit-artix /etc/runit/sv/agetty-serial/
runit-artix /etc/runit/sv/agetty-serial/conf
runit-artix /etc/runit/sv/agetty-serial/finish
runit-artix /etc/runit/sv/agetty-serial/run
runit-artix /etc/runit/sv/agetty-tty1/
runit-artix /etc/runit/sv/agetty-tty1/conf
runit-artix /etc/runit/sv/agetty-tty1/finish
runit-artix /etc/runit/sv/agetty-tty1/run
runit-artix /etc/runit/sv/agetty-tty1/supervise
runit-artix /etc/runit/sv/agetty-tty2/
runit-artix /etc/runit/sv/agetty-tty2/conf
runit-artix /etc/runit/sv/agetty-tty2/finish
runit-artix /etc/runit/sv/agetty-tty2/run
runit-artix /etc/runit/sv/agetty-tty2/supervise
runit-artix /etc/runit/sv/agetty-tty3/
runit-artix /etc/runit/sv/agetty-tty3/conf
runit-artix /etc/runit/sv/agetty-tty3/finish
runit-artix /etc/runit/sv/agetty-tty3/run
runit-artix /etc/runit/sv/agetty-tty3/supervise
runit-artix /etc/runit/sv/agetty-tty4/
runit-artix /etc/runit/sv/agetty-tty4/conf
runit-artix /etc/runit/sv/agetty-tty4/finish
runit-artix /etc/runit/sv/agetty-tty4/run
runit-artix /etc/runit/sv/agetty-tty4/supervise
runit-artix /etc/runit/sv/agetty-tty5/
runit-artix /etc/runit/sv/agetty-tty5/conf
runit-artix /etc/runit/sv/agetty-tty5/finish
runit-artix /etc/runit/sv/agetty-tty5/run
runit-artix /etc/runit/sv/agetty-tty5/supervise
runit-artix /etc/runit/sv/agetty-tty6/
runit-artix /etc/runit/sv/agetty-tty6/conf
runit-artix /etc/runit/sv/agetty-tty6/finish
runit-artix /etc/runit/sv/agetty-tty6/run
runit-artix /etc/runit/sv/agetty-tty6/supervise
runit-artix /etc/runit/sv/agetty-ttyAMA0/
runit-artix /etc/runit/sv/agetty-ttyAMA0/conf
runit-artix /etc/runit/sv/agetty-ttyAMA0/finish
runit-artix /etc/runit/sv/agetty-ttyAMA0/run
runit-artix /etc/runit/sv/agetty-ttyAMA0/supervise
runit-artix /etc/runit/sv/agetty-ttyS0/
runit-artix /etc/runit/sv/agetty-ttyS0/conf
runit-artix /etc/runit/sv/agetty-ttyS0/finish
runit-artix /etc/runit/sv/agetty-ttyS0/run
runit-artix /etc/runit/sv/agetty-ttyS0/supervise
runit-artix /etc/runit/sv/agetty-ttyUSB0/
runit-artix /etc/runit/sv/agetty-ttyUSB0/conf
runit-artix /etc/runit/sv/agetty-ttyUSB0/finish
runit-artix /etc/runit/sv/agetty-ttyUSB0/run
runit-artix /etc/runit/sv/agetty-ttyUSB0/supervise
runit-artix /etc/runit/sv/sulogin/
runit-artix /etc/runit/sv/sulogin/run
runit-artix /etc/runit/sv/sulogin/supervise
runit-artix /usr/
runit-artix /usr/bin/
runit-artix /usr/bin/init
runit-artix /usr/bin/modules-load
runit-artix /usr/bin/pause
runit-artix /usr/bin/zzz
runit-artix /usr/lib/
runit-artix /usr/lib/runit-artix/
runit-artix /usr/lib/runit-artix/bin/
runit-artix /usr/lib/runit-artix/bin/halt
runit-artix /usr/lib/runit-artix/bin/poweroff
runit-artix /usr/lib/runit-artix/bin/reboot
runit-artix /usr/lib/runit-artix/bin/shutdown
runit-artix /usr/share/
runit-artix /usr/share/licenses/
runit-artix /usr/share/licenses/runit-artix/
runit-artix /usr/share/licenses/runit-artix/LICENSE
runit-artix /usr/share/man/
runit-artix /usr/share/man/man1/
runit-artix /usr/share/man/man1/pause.1.gz
runit-artix /usr/share/man/man8/
runit-artix /usr/share/man/man8/modules-load.8.gz
runit-artix /usr/share/man/man8/zzz.8.gz

It doesn't even touch /bin, and I've done no modifications to /etc/runit/core-services/03-filesystem.sh (https://github.com/artix-linux/runit-artix/blob/master/core-services/03-filesystems.sh). I don't know what happened to your system, but I'm sure it's not because, I quote "it's your package fault, not me!".


Either it's stuck on initramfs (which shouldn't), or it doesn't want to remount /. But it shouldn't crash and go to stage3 since it'll launch an emergency shell instead.

This one.
(https://ptpb.pw/CBOK.png)

it goes to emergency cell but nothing works, no commands, no ttys nothing, only the power button works.
It says it can't locate the root partition, although it is there, the uuid is correct and it is checking fine.
Three different installations of runit-artix (2 of the -3 and 1 of the -4) did exactly the same thing, removed bin link.  The -3 version would replace it with a directory /bin/ that had the init link in it.  The -4 just removed it.  The system worked fine before the transaction with runit.  Should I attempt to put openrc back in it?  Other than following the instructions (partially) of moving from manjaro or arch to artix (disregarding the systemd removal) it is the only instructions I have in getting the system back. 

You do remember that it worked yesterday with the older runit-artix except for ipv4 connectivity, I only had ipv6.  When the repositories refreshed and brought the new gremlins files and I updated that is when it locked up.

This was not a fresh install, it is an old system, it had 11GB of files in it without /var/cache which is in a separate partition and without /home.  According to what you are circling above I just followed all the instructions, but I had to use --force to get it installed and removing openrc, which is not mentioned on the instructions.  Partially I think it was due some of the ***-openrc/-runscript files that had no -runit equivalents.

You know, there's a reason I only provide -1 (system) and -4 (gremlins). Both -2 and -3 are faulty, and are not supported.
If you directly installed -4 from a faulty -3 and -2 package, it would "remove" /bin. But if you installed -4 (after yet another symlink from /bin to /usr/bin) after -1, it shouldn't happen as the only transaction happened is the symlink from /usr/bin/init to runit-init.

But for now, you can either go back to -1 or go back to openrc. runit builds are still in transitionary period and eventually OpenRC and runit will have one halt/poweroff/reboot/shutdown system so you and I both don't have to deal with this headache.


That's NM, and has no relevance in your problem now.


Clearly you didn't read the wiki. If you used -4, runit-artix would conflict with openrc anyway.
I explained the *-openrc files not existing in runit because of it being handled directly by /etc/runit/1.

The wiki says nothing about invalid pkgs in the repository and the only mention of -4 in the wiki is a coincidental match in the uuid example.
It says in the wiki that there are pkgs in gremlins or should they be utilized, which were on my case, no it doesn't.
Does it say in the wiki that openrc conflicts with runit-artix?  Quite the opposite, it says IF you want to remove openrc and leave runit, you should add a modification in grub etc...

What is it in wiki that makes you think I did not read or follow?

The wiki didn't say anything about gremlins. Neither did the wiki mentions -4.


The wiki was intended to follow stable releases, not testing.

The wiki also never said "IF you want to remove openrc", but to use runit as your init system.

But if you look at the PKGBUILD (or even take a careful look at pacman since if you installed openrc the conflict will trigger), it does conflict with runit-artix.
https://github.com/artix-linux/packages/blob/master/runit-artix/repos/testing-x86_64/PKGBUILD#L13

In the next packaging, both OpenRC and runit-artix will depend on one package which handles shutdown/halt/poweroff/reboot, but  testing will be needed.

Ok, I don't understand, just yesterday you were telling me the right package (20180414-4) should be in gremlins but the repository is not updated yet, now you are saying it is based on stable?
So 20180414-1 would have been fine it was 20180414-2 that messed me up?

If so, then I just picked the wrong damn day to try runit, didn't I?

For the rest of you not knowing what we are talking about, up until 36 hrs ago the pkg in gremlins was "a faulty one", what other faulty packages were there in gremlins since 4/16?

 gremlins/runit-artix 20180414-4 (init) [installed]
    Runit initscripts for Artix
 system/runit-artix 20180414-1 [installed: 20180414-4]
    Runit initscripts for Artix

It's the wiki page that is based on stable. But the right unstable package is on gremlins (-4).


Yes.

Ok, I managed by going back and forth to get it back and it is booting fine now, although my networking is still a mess and I need to clear this out still.  I will start another topic but under the runit hierarchy as it pertains to problems that developed from the runit transition.  Right now I have inet4 and inet6 but I have 3 lines of commands in autostart to get to have network access after X start.  Which means at console at stage 2 I have no access unless I run those commands. 

Ram use is comparable to that with OpenRC, by far higher than it is with Void with about the same exact things running on start.
To me that translates to the need to strip unnecessary crud off of it.

While utilizing some of the instructions systemd-free.artixlin...  for moving from that "other" init system into OpenRC, sddm and xorg settings went out of wack.  I was trying to go "back there" so I can move forward again.  I am still running on Gremlins and I will continue to report on development.
Right now I feel like the basement got flooded and I have just been able to move the water out but there is work to do.

On the rc.conf file why can't there be options of what to run on stage 1 and what not?  (ie lvm, swap, btrfs, raid, etc)

Here is a clip of the s6 .conf file:

# Apply kernel runtime [yes|no]
KERNELRUNTIME=yes

# Boot with dmraid support [yes|no]
USEDMRAID=no

# Boot with btrfs support [yes|no]
USEBTRFS=no

# Boot with lvm support [yes|no]
# Do not forget to remake your initramfs with lvm2 hook on it
USELVM=no

#swap support [yes|no]
USESWAP=yes

#enable cgroups [yes|no]
CGROUPS=yes

Instead we get just error messages with runit of things that may not apply to our system.
Now I understand that you don't do runit development here, you just apply what comes from upstream, but can there be a modification?

There are shell scripts in /etc/runit/core-services/ that are executed as stage one. I think every example you named is already handled by default (swap, the filesystems, etc.). Not sure about raid though, you might have to configure that one.

I simply think it isn't necessary.

If you look carefully into our filesystems stage1 (https://github.com/artix-linux/runit-artix/blob/master/core-services/03-filesystems.sh), some will only be triggered if certain binaries are there (read: you installed it through a package). If you don't use btrfs you can uninstall btrfs-progs. If you don't have LVM don't install lvm2.

I would consider it unnecessary bloat.

No I have run it with # .. same thing, but dbus is running, it is not like it isn't.
If dbus wasn't running should I or should I not have had network on console.  The problem was at the start of stage 2, not on desktop.

Here is some sv status now, when the problem is not there anymore, but what fixed it I am still trying to find out

# sv status /etc/runit/runsvdir/default/*  
run: /etc/runit/runsvdir/default/acpid: (pid 602) 15668s
run: /etc/runit/runsvdir/default/agetty-tty1: (pid 595) 15669s
run: /etc/runit/runsvdir/default/agetty-tty2: (pid 581) 15669s
run: /etc/runit/runsvdir/default/agetty-tty3: (pid 584) 15669s
run: /etc/runit/runsvdir/default/agetty-tty4: (pid 582) 15669s
run: /etc/runit/runsvdir/default/agetty-tty5: (pid 585) 15669s
run: /etc/runit/runsvdir/default/agetty-tty6: (pid 583) 15669s
run: /etc/runit/runsvdir/default/alsa: (pid 658) 15666s
down: /etc/runit/runsvdir/default/avahi-daemon: 0s, normally up, want up
run: /etc/runit/runsvdir/default/cronie: (pid 605) 15668s
fail: /etc/runit/runsvdir/default/dbus: unable to change to service directory: file does not exist
down: /etc/runit/runsvdir/default/dhclient: 1s, normally up, want up
fail: /etc/runit/runsvdir/default/dhcp: unable to change to service directory: file does not exist
run: /etc/runit/runsvdir/default/dhcpcd: (pid 603) 15668s
fail: /etc/runit/runsvdir/default/dhcpd: unable to change to service directory: file does not exist
down: /etc/runit/runsvdir/default/dhcpd4: 1s, normally up, want up
down: /etc/runit/runsvdir/default/dhcpd6: 1s, normally up, want up
run: /etc/runit/runsvdir/default/dmeventd: (pid 32448) 1268s
down: /etc/runit/runsvdir/default/elogind: 0s, normally up, want up
run: /etc/runit/runsvdir/default/haveged: (pid 645) 15667s
down: /etc/runit/runsvdir/default/ip6tables: 1s, normally up, want up
down: /etc/runit/runsvdir/default/iptables: 1s, normally up, want up
down: /etc/runit/runsvdir/default/lm_sensors: 1s, normally up, want up
fail: /etc/runit/runsvdir/default/lvm: unable to change to service directory: file does not exist
fail: /etc/runit/runsvdir/default/lvm2: unable to change to service directory: file does not exist
run: /etc/runit/runsvdir/default/lvmetad: (pid 654) 15666s
run: /etc/runit/runsvdir/default/mdadm: (pid 642) 15667s
run: /etc/runit/runsvdir/default/nfs-server: (pid 609) 15668s
down: /etc/runit/runsvdir/default/ntpd: 1s, normally up, want up
run: /etc/runit/runsvdir/default/rpcbind: (pid 601) 15668s
run: /etc/runit/runsvdir/default/rsyncd: (pid 631) 15667s
down: /etc/runit/runsvdir/default/sddm: 1s, normally up, want up
run: /etc/runit/runsvdir/default/sshd: (pid 596) 15669s
run: /etc/runit/runsvdir/default/statd: (pid 666) 15666s

If you really symlinked all directories in /etc/runit/sv to /run/runit/service, then you didn't install dbus-runit and NetworkManager-runit, plain and simple.

If you have both dbus and NetworkManager service running (and by running I meant properly in a runsv process) you should have something like this in your pstree -a output.

runit,1
  |-compton,1254
  |-dbus-daemon,1274 --syslog-only --fork --print-pid 5 --print-address 7 --session
  |-dbus-launch,1271 --autolaunch=c22ecdc4b8715fda2bdd99c05a7e7132 --binary-syntax --close-stderr
  |-elogind,1037 --daemon
  |-runsvdir,772 -P /run/runit/service...
  |   |-runsv,778 alsa
  |   |   `-pause,802
  |   |-runsv,779 acpid
  |   |   |-acpid,864 -f
  |   |   `-svlogd,801 -tt /var/log/acpid
  |   |-runsv,780 agetty-tty5
  |   |   `-agetty,804 tty5 38400 linux
  |   |-runsv,781 openntpd
  |   |   |-logger,797 -t openntpd -p daemon notice
  |   |   `-ntpd,863 -d -s
  |   |       `-ntpd,947      
  |   |           `-ntpd,950     
  |   |-runsv,782 socklog
  |   |   |-socklog,862 unix /dev/log
  |   |   `-svlogd,799 /var/log/socklog/cron /var/log/socklog/daemon /var/log/socklog/debug /var/log/socklog/errors ...
  |   |-runsv,783 NetworkManager
  |   |   `-NetworkManager,800 -n
  |   |       |-{NetworkManager},1018
  |   |       `-{NetworkManager},1020
  |   |-runsv,784 agetty-tty1
  |   |   `-login,803     
  |   |-runsv,785 tlp
  |   |   `-pause,796
  |   |-runsv,786 agetty-tty3
  |   |   `-agetty,793 tty3 38400 linux
  |   |-runsv,787 agetty-tty4
  |   |   `-agetty,792 tty4 38400 linux
  |   |-runsv,788 dbus
  |   |   `-dbus-daemon,798 --system --nofork --nopidfile
  |   |-runsv,789 dnscrypt-proxy
  |   |   |   `-{dnscrypt-proxy},1528
  |   |   `-svlogd,805 -t /var/log/dnscrypt-proxy
  |   |-runsv,790 agetty-tty6
  |   |   `-agetty,794 tty6 38400 linux
  |   `-runsv,791 agetty-tty2
  |       `-agetty,795 tty2 38400 linux
  |-udevd,291 --daemon
  `-wpa_supplicant,1043 -u

Note that there are two different dbus processes. One is a child process of a runsv process (PID 798) and one is a direct child of runit (PID 1274). The dbus process with PID 1274 are launched (in this case) by Firefox (and Firefox immediately closed after I manually killed the dbus process), this means that your "running" dbus process will listen to Firefox and only Firefox, and will not work with any other processes (elogind, NetworkManager, wicd, etc.)

So no. In your case, dbus is not running as a proper service. It is likely that you're not installing both dbus-runit and networkmanager-runit and you didn't enable both services (because the service doesn't even exist).

fail: /etc/runit/runsvdir/default/dbus: unable to change to service directory: file does not exist

Also, the problem is likely fixed by enabling the dhcpcd runit service.

What I did (remember the day the reps weren't working and got the bad runit-artix ---3 instead of 4) was to make a list of all the runscripts I had installed and find the corresponding -runit pkgs.  Except for a few that had no match, I removed ALL the -openrc and replaced them with -runit + runit + runit-artix
Then I had no network and decided to get rid of networkmanager
Then I still had problems with dhcpd which was running, but something was missing and by enabling (linking all services I had installed and available somehow cured the network problem). 
I have no firefox, I have palemoon, which might be working the same way.
But dbus-runit was installed all along.  If I hadn't linked dbus or any of those other ones that produce the error it wouldn't show up in sv status when I run it for the whole run directory
A week has gone by and the only thing I get is that I did something wrong, and I am not asking for blame, but I did follow ALL instructions on the wiki, just did it when a bad runit-artix file was in the repositories.

Now WHAT?

Could you post your output of a couple of things?

$ ls /run/runit/service

And also

$ pstree -a

Need I remind you that the installation does not have functionality problems now, but the way I fixed it was by linking pretty every service there was to the active directory
I just replace some of the ids with 111s and 000s

$ ls  /run/runit/service
acpid        agetty-tty4  avahi-daemon  dhcp    dhcpd6    ip6tables   lvm2        ntpd     sshd
agetty-tty1  agetty-tty5  cronie        dhcpcd  dmeventd  iptables    lvmetad     rpcbind  statd
agetty-tty2  agetty-tty6  dbus          dhcpd   elogind   lm_sensors  mdadm       rsyncd
agetty-tty3  alsa         dhclient      dhcpd4  haveged   lvm         nfs-server  sddm



$ pstree -a
runit
  |-at-spi-bus-laun
  |   |-dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf 
--nofork--print-addre
  |   `-3*[{at-spi-bus-laun}]
  |-at-spi2-registr --use-gnome-session
  |   `-2*[{at-spi2-registr}]
  |-conky -c /home/artix2/.conky/TeejeeTech/ProcessPanel
  |   `-3*[{conky}]
  |-conky -c /home/artix2/.conky/TeejeeTech/CpuPanel
  |   `-8*[{conky}]
  |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
  |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
  |-dbus-launch --autolaunch 1111111111111111111111111 --binary-syntax --close-stderr
  |-dbus-launch --autolaunch=1111111111111111111111111 --binary-syntax --close-stderr
  |-gconfd-2
  |-lxpolkit
  |   `-2*[{lxpolkit}]
  |-runsvdir -P /run/runit/service...
  |   |-runsv agetty-tty4
  |   |   `-agetty tty4 38400 linux
  |   |-runsv agetty-tty2
  |   |   `-agetty tty2 38400 linux
  |   |-runsv nfs-server
  |   |   `-rpc.mountd --foreground
  |   |-runsv sshd
  |   |   `-sshd -D
  |   |-runsv agetty-tty6
  |   |   `-agetty tty6 38400 linux
  |   |-runsv dhcpcd
  |   |   `-dhcpcd -B -M
  |   |-runsv dhclient
  |   |-runsv dhcpd4
  |   |-runsv rpcbind
  |   |   `-rpcbind -f
  |   |-runsv agetty-tty3
  |   |   `-agetty tty3 38400 linux
  |   |-runsv mdadm
  |   |   `-mdadm --monitor --scan --syslog
  |   |-runsv iptables
  |   |-runsv dmeventd
  |   |   `-dmeventd -f
  |   |-runsv haveged
  |   |   `-haveged -w 1024 -v 1 -F
  |   |-runsv dhcpd6
  |   |-runsv agetty-tty5
  |   |   `-agetty tty5 38400 linux
  |   |-runsv rsyncd
  |   |   `-rsync --daemon --no-detach
  |   |-runsv alsa
  |   |   `-pause
  |   |-runsv elogind
  |   |-runsv ip6tables
  |   |-runsv sddm
  |   |-runsv statd
  |   |   `-rpc.statd -F -d
  |   |-runsv cronie
  |   |   `-crond -n
  |   |-runsv lm_sensors
  |   |-runsv lvmetad
  |   |   `-lvmetad -f
  |   |-runsv agetty-tty1
  |   |   `-login     
  |   |       `-bash
  |   |           `-sudo sddm
  |   |               `-sddm
  |   |                   |-Xorg -nolisten tcp -auth ...
  |   |                   |   `-4*[{Xorg}]
  |   |                   |-sddm-helper --socket 
/tmp/sddm-auth00000000000000000000000000000 ...
  |   |                   |   `-openbox --startup /usr/lib/openbox/openbox-autostart OPENBOX
  |   |                   |       `-lxterminal
  |   |                   |           |-bash
  |   |                   |           |   `-pstree -a
  |   |                   |           |-bash
  |   |                   |           |   `-nano /tmp/tmpnote
  |   |                   |           `-{lxterminal}
  |   |                   `-{sddm}
  |   |-runsv ntpd
  |   |-runsv acpid
  |   |   `-acpid -f
  |   `-runsv avahi-daemon
  |-sh /home/artix2/.config/openbox/autostart
  |   `-conky -c /home/artix2/.conky/Gotham/Gotham
  |       `-3*[{conky}]
  `-udevd --daemon


$ sudo sv status *
run: acpid: (pid 627) 1712s
run: agetty-tty1: (pid 623) 1713s
run: agetty-tty2: (pid 622) 1713s
run: agetty-tty3: (pid 620) 1713s
run: agetty-tty4: (pid 624) 1713s
run: agetty-tty5: (pid 621) 1713s
run: agetty-tty6: (pid 625) 1713s
run: alsa: (pid 641) 1712s
down: avahi-daemon: 1s, normally up, want up
run: cronie: (pid 645) 1712s
fail: dbus: unable to change to service directory: file does not exist
down: dhclient: 1s, normally up, want up
fail: dhcp: unable to change to service directory: file does not exist
run: dhcpcd: (pid 642) 1712s
fail: dhcpd: unable to change to service directory: file does not exist
down: dhcpd4: 1s, normally up, want up
down: dhcpd6: 1s, normally up, want up
run: dmeventd: (pid 639) 1712s
down: elogind: 1s, normally up, want up
run: haveged: (pid 638) 1712s
down: ip6tables: 1s, normally up, want up
down: iptables: 1s, normally up, want up
down: lm_sensors: 0s, normally up, want up
fail: lvm: unable to change to service directory: file does not exist
fail: lvm2: unable to change to service directory: file does not exist
run: lvmetad: (pid 643) 1712s
run: mdadm: (pid 636) 1712s
run: nfs-server: (pid 646) 1712s
down: ntpd: 1s, normally up, want up
run: rpcbind: (pid 640) 1712s
run: rsyncd: (pid 631) 1712s
down: sddm: 1s, normally up, want up
run: sshd: (pid 628) 1712s
run: statd: (pid 632) 1712s

Looking at that output, I honestly don't know how your system is running okay because it just looks completely broken to me. Here's my output right now (with admittedly much fewer services but you get the picture).

$ ls /run/runit/service 
agetty-tty1  agetty-tty2  agetty-tty3  agetty-tty4  agetty-tty5  agetty-tty6  cgmanager  cupsd	dbus  dhcpcd  elogind


$ pstree -a
runit
  ├─at-spi-bus-laun
  │   ├─dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
  │   └─3*[{at-spi-bus-laun}]
  ├─at-spi2-registr --use-gnome-session
  │   └─2*[{at-spi2-registr}]
  ├─dbus-daemon --syslog --fork --print-pid 4 --print-address 6 --session
  ├─dconf-service
  │   └─2*[{dconf-service}]
  ├─gconfd-2
  ├─git-credential- /home/user/.cache/git/credential/socket
  ├─gvfs-udisks2-vo
  │   └─2*[{gvfs-udisks2-vo}]
  ├─gvfsd
  │   ├─gvfsd-dnssd --spawner :1.2 /org/gtk/gvfs/exec_spaw/5
  │   │   └─2*[{gvfsd-dnssd}]
  │   ├─gvfsd-network --spawner :1.2 /org/gtk/gvfs/exec_spaw/2
  │   │   └─3*[{gvfsd-network}]
  │   ├─gvfsd-trash --spawner :1.2 /org/gtk/gvfs/exec_spaw/0
  │   │   └─2*[{gvfsd-trash}]
  │   └─2*[{gvfsd}]
  ├─gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
  │   └─5*[{gvfsd-fuse}]
  ├─gvfsd-metadata
  │   └─2*[{gvfsd-metadata}]
  ├─ibus-daemon -drx
  │   ├─ibus-dconf
  │   │   └─3*[{ibus-dconf}]
  │   ├─ibus-engine-sim
  │   │   └─3*[{ibus-engine-sim}]
  │   ├─ibus-extension-
  │   │   └─3*[{ibus-extension-}]
  │   ├─ibus-ui-gtk3
  │   │   └─3*[{ibus-ui-gtk3}]
  │   ├─python /usr/share/ibus-anthy/engine/main.py --ibus
  │   │   └─3*[{python}]
  │   └─2*[{ibus-daemon}]
  ├─ibus-portal
  │   └─2*[{ibus-portal}]
  ├─ibus-x11 --kill-daemon
  │   └─2*[{ibus-x11}]
  ├─palemoon
  │   └─55*[{palemoon}]
  ├─pcmanfm
  │   └─2*[{pcmanfm}]
  ├─polkitd --no-debug
  │   └─15*[{polkitd}]
  ├─pulseaudio --start
  │   └─{pulseaudio}
  ├─runsvdir -P /run/runit/service...
  │   ├─runsv agetty-tty2
  │   │   └─agetty tty2 38400 linux
  │   ├─runsv cgmanager
  │   │   └─cgmanager -q -m name=systemd
  │   ├─runsv agetty-tty6
  │   │   └─agetty tty6 38400 linux
  │   ├─runsv agetty-tty1
  │   │   └─login     
  │   │       └─sway
  │   │           ├─Xwayland :0 -rootless -terminate -listen 32 -listen 33 -wm 37
  │   │           │   └─9*[{Xwayland}]
  │   │           ├─sway
  │   │           ├─swaybar -b bar-0
  │   │           │   └─sh -c while :; do date +'%Y-%m-%d %H:%M:%S %p'; sleep 1; done
  │   │           │       └─sleep 1
  │   │           ├─swaybg 0 /usr/share/backgrounds/warty-final-ubuntu.png fill
  │   │           └─{sway}
  │   ├─runsv dhcpcd
  │   │   └─dhcpcd -B -M
  │   ├─runsv agetty-tty5
  │   │   └─agetty tty5 38400 linux
  │   ├─runsv cupsd
  │   │   └─cupsd -f
  │   ├─runsv agetty-tty3
  │   │   └─agetty tty3 38400 linux
  │   ├─runsv elogind
  │   │   └─elogind
  │   ├─runsv dbus
  │   │   └─dbus-daemon --system --nofork --nopidfile
  │   └─runsv agetty-tty4
  │       └─agetty tty4 38400 linux
  ├─udevd --daemon
  ├─udisksd
  │   └─4*[{udisksd}]
  ├─urxvt
  │   └─zsh
  │       └─weechat
  │           └─8*[{weechat}]
  ├─urxvt
  │   └─zsh
  │       └─R -q
  └─urxvt
      └─zsh
          └─pstree -a


$ sudo sv status *
run: agetty-tty1: (pid 639) 28256s
run: agetty-tty2: (pid 643) 28256s
run: agetty-tty3: (pid 640) 28256s
run: agetty-tty4: (pid 641) 28256s
run: agetty-tty5: (pid 642) 28256s
run: agetty-tty6: (pid 638) 28256s
run: cgmanager: (pid 647) 28256s
run: cupsd: (pid 646) 28256s
run: dbus: (pid 644) 28256s
run: dhcpcd: (pid 649) 28256s
run: elogind: (pid 645) 28256s

Looking at the output of the /run/runit/service directory, I don't know where in the world "dhcp", "dhcpd", "dhcpd4",  "dhcpd6", "lvm", or "lvm2" came from. Those aren't proper names for any of those. The dhcpcd-runit package gives you the "dhcpcd" directory which is the correct one. It also looks like dbus and elogind are both down which is probably not good and will give you trouble later. Try force reinstalling the dbus-runit and elogind-runit packages. There may be some other things wrong in there but I don't use most of those services so I don't really know for sure.

I had already tried reinstalling, from what I had in cache.  No difference.
dbus now is giving me the correct output.  What I did was using sv restart
The screen turned black and everything controlling anything valished.  I had to kill it with the button.
When I rebooted dbus was running fine, (it was running before as well but was giving the error about directory not found, although it was there)?
I tried the same with lvm* and dhcp* but no change.
If dhcp is not running, although I see the processes going up and down the process list) how come I have a flawless connection now?

You also have "dhcpcd" in your directory which is the correct name of the service (which is why you have internet). The other ones are extra folders you should get rid of. It's good that you have dbus working properly. Is elogind running ok now as well? If you get rid of those extra/unneeded directories ("dhcp", "dhcpd", "dhcpd4",  "dhcpd6", "lvm", and "lvm2"),  I think your output should be normal.

Calm down. You seem to be very worked up. Be patient.


runit-artix has nothing to do with this. We're talking purely about dbus-runit since your problem is with NetworkManager (and really, why go back to this thread when we have a separate thread). When you did something and you're corresponding with someone over the forums to troubleshoot your problem about your "network problems", you immediately notfiy them. You're a little too late.


Did you even read your own error?

fail: /etc/runit/runsvdir/default/dbus: unable to change to service directory: file does not exist

However, since your problem is resolved, I'm not replying to you anymore for this matter since this discussion is quickly turning into a flamefest (if it isn't a flamefest already).

I am not worked up, because luckily I have another system to work with.  If this was my only system and it was down for a week I would be.
The question does not pertain to networkmanager as networkmanager has been removed for a long time, I have mentioned it 3 times and it is nowhere in the output, why bring it up.

Following the steps, even with a bad runit-artix in the repository which was unfortunate, I installed all the *-runit pkgs that replaced the -openrc packages.  Then linked them to run/runit as it is desrcibed.  Why did I get those errors and how come they go away when I use sv restart?  Is using restart a way that runit redefines where things are and discovers directories that are there but it thought as missing?  Because I sure didn''t change anything else for it to find dbus, even though dbus-daemon was started as soon as X went up. I could see it on conky without even starting a terminal.

Since in actual working on the system it seems functional, despite of what @Dudemanguy says about being broken, I may have too many services up, which may be a ram problem, I don't have the expertise to say what is needed and what not.  I'd say based on this experience there is a whole section in the wiki that is missing.

Maybe there is a whole other chapter for that matter and I only did this once.  Since there may be a runit.iso coming up, how does one go from runit to openrc?  In the same fashion there should be a little more analysis that fits every system, to switch init systems without altering the rest of the system further.  What services exactly are under openrc handling that should translate to active runit services.  Obviously having a runscript pkg installed does not mean it is a necessary idling service that is needed to be active on boot. 

ATTENTION TO ALL RUNIT USERS:

See announcement (https://forum.artixlinux.org/index.php/topic,520.new.html)

Since this thread has served its purpose, I'm going to close this thread by the time runit-artix-20180414-9 lands in [system].

Before we close this thread, turns out there is two more important announcements following feedback from both devs and users alike.

Note: All of the following only happened in [gremlins].

1. runit and runit-artix have been combined into a single package: runit.
2. elogind-runit and dbus-runit have been updated.

Before you upgrade elogind-runit, dbus-runit, and runit, please make sure to do the following (if and only if you're in [gremlins]).

Do the following commands (if and only if you activated the services)

# rm /run/runit/service/elogind
# rm /run/runit/service/dbus

If you're using Xorg, it will close. This is normal. Proceed into tty (tty2-6).

After that you can do an upgrade to elogind-runit, dbus-runit and the runit package itself as normal.

It may take a while to for the mirrors to reach our main repo to fetch the packages (dbus-runit-20180429-2, elogind-runit-20180429-2, runit-2.1.2-5) so please be patient.

Also, I won't be available until this Friday for personal reasons. I'm sorry for my unavailability but if there's any issue I'll fix it after Friday.

This thread is now locked since it has served its purpose. Any new announcements in runit systems will be posted in a new thread.