gentoo openrc runit

I decided to have another go at runit, this time on my gentoo.

I had been thinking about this, since I saw this bit in the gentoo wiki article on openrc:
It does not function as a replacement for the /sbin/init

I keep wanting to trim everything down, and have been integrating busybox to replace userspace utilities. The gentoo wiki says:
Busybox can be used to replace most of the userspace utilities needed by OpenRC (init, shell, awk and other POSIX tools), by using a complete Busybox as shell for OpenRC all the calls that normally would cause a fork/exec would be spared, improving the overall speed. This process is not yet streamlined.
Please note that there are currently many Busybox applets that are incompatible with OpenRC.

It was that last bit which concerned me, and I didn't want to risk hacking it too much.

But I could hack /bin/init provided by sys-apps/sysvinit. I do like runit, and decided to install sys-process/runit which provides /sbin/runit-init.

The install was pretty simple:
# emerge --ask sys-process/runit

I was very surprised when my regular clean up routine gave me a prompt to unmerge sys-apps/sysvinit.

# emerge --depclean --ask 
>>> Calculating removal order... 

>>> These are the packages that would be unmerged: 

    selected: 2.88-r9 
   protected: none 
     omitted: none 

All selected packages: =sys-apps/sysvinit-2.88-r9 

>>> 'Selected' packages are slated for removal. 
>>> 'Protected' and 'omitted' packages will not be removed. 

Would you like to unmerge these packages? [Yes/No] n

Was it not needed anymore?

Wanting to see what gentoo does out of the box, I rebooted and appended init=/sbin/runit-init to the kernel cmdline.

My system booted up cleanly, and I could login and startx.

However, I realised that I had no network. But I could manually start my network, and all was fine.

# /etc/init.d/net.wlp3s0 start

Subsequently, I realised that none of my other services had started. I narrowed them all down to the default runlevel.

It seems that all the services in sysinit and boot runlevels had started, but the default runlevel had not been triggered.

So this was the only thing to do, in order to have runit instead of sysvinit on gentoo out of the box. Impressive!

I had a look at runit's runlevel 1.

$ cat /etc/runit/1                                                                                                                                                                                   
# system one time tasks


RUNLEVEL=S /sbin/rc sysinit
RUNLEVEL=S /sbin/rc boot

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

It looks like runit runlevel 1 is triggering the openrc runlevels sysinit and boot, but default is not listed there. So I just added it in there.

$ cat /etc/runit/1                                                                                                                                                                                   
# system one time tasks


RUNLEVEL=S /sbin/rc sysinit
RUNLEVEL=S /sbin/rc boot
RUNLEVEL=S /sbin/rc default

touch /etc/runit/stopit
chmod 0 /etc/runit/stopit

I rebooted again to test. All my services were working, and I had no errors or warnings.

I decided to go for broke, and remove sysvinit with a bit of trepidation, but knowing that I could put it back as it was.

# emerge --ask --depclean sys-apps/sysvinit

With a clean slate, I rebooted again and was pleasantly surprised. Everything seems to be well on my system.. Well, almost!

sysvinit disappeared along with shutdown reboot halt poweroff etc commands. So I had to create them.

# vi /usr/local/sbin/runit-shutdown
case "$(basename $0)" in
  reboot) /sbin/runit-init 6 ;;
    /sbin/runit-init 0 ;;
# cd /sbin
# ln -s /usr/local/runit-shutdown shutdown
# ln -s /usr/local/runit-shutdown poweroff
# ln -s /usr/local/runit-shutdown halt
# ln -s /usr/local/runit-shutdown reboot

And all was well again. Powerbutton was working, as were my other i3 keybindings.

As the runit article on gentoo wiki says:
It can be used in conjunction with OpenRC as an alternative to sysvinit or even replacing OpenRC as service manager.
Runit can also replace OpenRC as the service manager.
which means runit can do everything on it's own. I have seen it being very dependable & stable in voidlinux.

Now why didn't the linux lords consider lean, clean & simple runit, when deciding about systemd?

I am usually very critical of systemd. But some kudos I do have for systemd removing much accumulated garbage and cruft like *bus *kit etc.

For now, I will keep openrc as service manager, and runit as system init. Too much hacking at the gentoo core might take me too far away from gentoo stable.

$ pidof runit

And all is well :)

tmux mouse scroll

I keep running into this issue, as tmux changed it's mouse behaviour. To make it work again, add the following code snippet into your ~/.tmux.conf

set -g mouse on
bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"
bind -n WheelDownPane select-pane -t= \; send-keys -M

and reload the changed tmux configuration
$ tmux source ~/.tmux.conf

git Gentoo repos on GitHub

git me! The gentoo repos are on github, and I've just discovered them.. mysteriously hidden in the World Wide Web ;)

There is a post on the gentoo forums from 2015, re git/github saying:
Although some developers wrongly still recommend plain rsync-update method, you should never do that, since it is fundamentally insecure (emerge-webrsync is signed by a machine key, but still better). 

You should instead start to sync via git (best do that from github, unless you want to break our infra server).

Essentially, rsync update method is outdated and insecure. The recommendation is to sync update via git, and more specifically github, rather than the gentoo infra servers.

GitHub gentoo (without metadata cache, for developers) repo:

This seems to be a mirror of the gentoo git infra server:

I found a github mirror, which I now use. For anonymous portage sync updates, I am hoping this secondary mirror may be more stable and less noisy.

GitHub gentoo-mirror (with metadata cache, for users) repo:

Before we change our sync method to git, we need to prepare/clean the portage location. Delete existing files, or move them elsewhere, in case you might have second thoughts ;) If you are not happy with git, you can move them back, and continue with rsync updates.

# mv /usr/portage /tmp

If you don't have enough freespace in /tmp, or don't want to use it, move it elsewhere and remember the location.

My /tmp is on tmpfs, and I have enough free space there for now. If you have a similar setup, note that tmpfs will not survive a reboot.

Now we can change our sync method to git.

# vi /etc/portage/repos.conf/gentoo.conf
main-repo = gentoo

location = /usr/portage
sync-type = git
sync-uri = git://
auto-sync = yes

Make sure there are no other files in that folder. I had trouble when I renamed my gentoo.conf file to another name in that same folder as backup. I changed auto-sync = no to be safer. Sync wouldn't give me any errors, or updates!

I previously used the gentoo infra server, before changing over to github, and then to the mirror. Apparently, the gentoo infra servers are not ready to take the weight of the whole world. Apparently, GitHub is safer and more reliable. I was pleasantly surprised that my git was in sync after the changeover.

We have prepared, cleaned and emptied our portage for a git sync. Now we can sync.
# emerge --sync

And move the distfiles back where they belonged.
# mv /tmp/portage/distfiles /usr/portage/

Now you can sync again and again.. to your heart's content :) No more worrying about overloaded rsync servers warning, or ending up on the ban list for syncing too much.

It is now a pleasure to sync, and see exactly what has changed where. Such a difference from watching that cruft fly past like a matrix on your screen. You might miss the filed Change Logs, if you used them. They are no longer needed. Git has much better, automated and less error prone methods.

Note the efficiency of git sync, and github :) This is what Linus alluded to, when he wanted to have an efficient kernel repository, accessible to the whole world.

If you are happy with git sync, you can delete that portage backup.
# rm -rf /tmp/portage

Another more important aspect is about making open source truly open! Anyone, even without github logins, can view the sources and changes. With a free github account, anyone could make suggestions via a simple pull request. You don't even need to be a developer.

The Monolithic Cabals

A few decades ago, there was a great big flame war called the Monolithic vs Microkernel debate. It is said that the debate was won by Linus. And that is why Linux became so popular.

Personally, I am a fan of Microkernels. But I am more a fan of Open Source. I believe that is the sole reason Linux became so popular. Linux didn't become so popular because people loved a monolithic architecture. Folks embraced it because it was open source.

More recently, there have been similar flames wars, but on a much larger scale, likes of which had never been seen before, spreading out from the low-level Kernel layers to the higher layers above. Apparently, some years ago, Gnome won the battle for the top layer Desktop, or rather the Desktop Environment. What was left was the middle layers between the Kernel and the GUI. And that battle apparently ended with many distributions bowing down to systemd. This was more a victory for the Gnome camp, who had lent them more than a covert hand in that battle. RedHat won the battle this time.

These monolithic cabals want to do everything. They don't seem to understand The Unix Philosophy. Taking over everything just makes them Too Big To Fail. We should never put all our eggs in one basket.

Is the war seemingly over now? The powerful feudal lords have divided the spoils between who owns which layer of the empire. Each of them, in their wisdom, have decided that they shall be the sole decision makers over what everyone else is or not allowed to do.

The one saving grace that stops them being completely becoming evil is the fact that each of them are completely dependant on Open Source. Any change they attempt is open to the rest of the world. Even that fact didn't stop The Mad Hatters from attempting to take over the lower layer kernel, with their dubious code pushes.

If I didn't know any better, I might suspect this as a culmination or coming together of a series of covert Microsoft Strategies. If you have not read The Halloween Documents, it is worth having a quick look. The FUD has come full circle, and many camps within Linux got embroiled in major flame wars over the systemd middleware between desktop and kernel.

This also reminds me of a paper called The Cathedral and The Bazaar. Slaves never had a choice. Freemen could make their own choices, unencumbered by anyone telling them what to do or not. There must be a reason that the exalted cathedrals of yore are empty now, while the bazaars have flourished.

It all depends on which side of the fence you are. If you are among the ruling class, obviously you will want to remain in the cathedral, lording over others. But if you are among the ones enjoying the luxuries inside, you would rather be free to decide your lifestyle and how best to flourish yourself, than be a slave in the cathedral.

In the end, it all depends on what is best for the world. Is it better that a few rule over everyone? Or would the world be a better place, if everyone had equality of choice and rights? No one should be too poor or too rich!

There is a reason that Open Source has flourished with contributions from volunteers who gave back their skills and time, in order to make things better for everyone. In stark contrast, the extremely wealthy proprietary software companies are all sitting on great big piles of accumulated cash twiddling their thumbs, deciding what to do.

I think my thoughts are running amok now..

I just wanted to pen down some thoughts before I lost them. I will flush this a bit more later.. Keep an eye!

A Digital Beep

When you don't have a Speaker/Bell, or you can't make quite make it work, and you want a beep!

It seems some devs have been a bit over zealous in trying to get rid of the system beep. Apparently, some users have been loudly complaining about their systems playing loud beeps. So they have thrown the baby out with the bath water. And now users who need the system beep do not seem to have it anymore.

The traditional method, to trigger the bell sound on a system beep event, was using pcspkr or snd-pcsp kernel modules. It seems quite a lot of users have lost this functionality during system updates. There seem to be multiple workarounds of workarounds floating around to resolve this issue. They seem to work for some, but not for many.

If you can, it is best to try get either pcspkr or snd-pcsp to work, as the system beep is an integrated event. You can hear the beep anywhere you want, including the console and terminals. The beep volume can be controlled from your audio mixer. You can increase, decrease, or mute the beep volume. That is how it used to be, and that is how it should have been.

Unfortunately, we seem to have quite a lot of trigger happy devs lately. In their eternal quest to keep adding yet more features and bumping up versions, they lose sight of core functionality and stability. Personally, I would rather have stable (even if old) reliable systems, than use bleeding edge new systems filled with tons of new features and even more bugs. In this process, they seem to be cannibalising what they have been handed over from previous generations to maintain.

But I guess, we are where we are.. and we try to make the best of what we have.

A digital beep could be a useful alternative. In this case, an audio file sounding like a bell masquerades as the pc-speaker bell at each system beep. In a nutshell, an audio player plays an audio file, at every system beep event.

The caveat is that depending on the method used, a digital beep is restricted to certain environments only. The method used below will only work within X, not on the console or any tty or anywhere outside X.

Read on for what is required. You can customise, or replace most of the bits with something else.

Kernel config:

Since we will not use pcspkr or snd-pcsp, we might as well remove them from the kernel, or atleast mask them. No need to carry excess baggage. No point in having things we can't/won't use.

# vi /etc/modprobe.d/blacklist.conf
blacklist pcspkr
black snd-pcsp

Check your kernel config for INPUT_BEEP. If not, add them and recompile your kernel. You will need to reboot for the new kernel to take effect.
$ grep BEEP /boot/config-`uname -r`

This is enabled in the default kernel configs of gentoo, debian, ubuntu, and arch linux.

Packages required:
1. sound-theme-freedesktop
2. vorbis-tools
3. xkbevd

sound-theme-freedesktop: A standard minimal sound theme.
This package installs a set of sound files in /usr/share/sounds/freedesktop directory. One of those audio files called bell.oga simulates a digital beep.

This package contains the ogg123 audio decoder/player, which can play .oga sound files from a sound-theme.

$ man ogg123
ogg123 reads Ogg Vorbis audio files and decodes them to the devices specified on the command line. By default, ogg123 writes to the standard sound device, but output can be sent to any number of devices. Files can be read from the file system, or URLs can be streamed via HTTP.

xkbevd: XKB event daemon
We run this as a background service to check for bell events, and trigger ogg123 to play bell.oga.

$ man xkbevd
The xkbevd event daemon listens for specified XKB events and executes requested commands if they occur. The configuration file consists of a list of event specification/action pairs and/or variable definitions.

The default configuration file is ~/.xkb/, which needs to be created.

$ vi ~/.xkb/
soundCmd="ogg123 -q"

Bell() "freedesktop/stereo/bell.oga"

This is pretty much the standard configuration.

We could open this up, and use any other audio file and any other media player. One thing to consider would be the impact of using large audio files and/or large audio players. We don't really want our system to freeze at every single bell event, while bloatwares load.

Identify your environment, to auto-start the XKB event daemon, according to your DE (Desktop Environment) or WM (Window Manager).

In my case, I login at the console and startx. I added the following line to my startup file.

$ vi ~/.xinitrc
xkbevd -bg
exec i3

There are a few more lines in that file. But those are the last two lines.

Ok, we have pretty much finished up. Now, we need to check whether these settings take effect.

If you had to recompile your kernel, you need to reboot. If you didn't, you need to logout and login, to verify the daemon auto-start.

May the beep be with you!

most popular posts