site  contact  history  index

Continuing improving pup_event

February 20, 2018 — BarryK

I reported on this a couple of days ago:

The woof-CE developers are also overhauling pup_event. I noticed that they have removed the IPC mechanism, and the one-second probing for optical media.

When X starts, /usr/local/pup_event/pup_event_frontend_d is started (from /root/.xinitrc) as a background process. In Puppy and Quirky/Easy, this "daemon" calls /usr/local/pup_event/frontend_timeout every second, that script, every fourth second, probes if an optical media inserted.

/usr/local/pup_event/pup_event_frontend_d reads hotplug events, known as "uevents", from the kernel, and this includes optical media insert/remove. However, the kernel hotplugging detection does not work for optical on some old PCs. Hence the backup probing in /usr/local/pup_event/frontend_timeout

However, the frequent optical drive probes impact performance, and the woof-CE developers decided to remove that from /usr/local/pup_event/frontend_timeout. Me too, it is now gone.

In fact, I now only have /usr/local/pup_event/frontend_timeout60, that runs every 60 seconds. It now works by the pup_event IPC mechanism. I have expanded usage of this IPC, which was my original intention.

/usr/local/pup_event/pup_event_frontend_d is a "server", that posts IPC messages about hotplug events, network up/down (and what interface), and 1, 4 and 60 second timeouts.

pup_event IPC is described in your puppy/Quirky/Easy, at /usr/local/pup_event/pup_event_ipc-README.htm


Some of my utilities are written in BaCon, but the last few years I have been plagued with problems, the utilities not working properly.

I have been working with Peter over the last few days, trying to narrow-down the problems. It mostly comes down to "string handling improvements" that were introduced in BaCon 3.0.3+.

Discussion here:

I have been rewriting pup_event_frontend_d and pup_event_ipc, works well now.

Tags: easy, quirky

Revisiting pup_event: first changes

February 16, 2018 — BarryK

I posted about pup_event earlier:

Where I identified possible old scripts that are no longer required. Indeed. have deleted these from /sbin:


Then, in /etc/udev/rules.d, I have deleted '60-dialup-modem.rules', and edited '50-udev-puppy-basic.rules' reducing it down to just this:

# sound
# note, /lib/udev/rules.d/50-udev-default.rules is from udev 167, has rules for
# ownership:group and permissions when device nodes are created.

# from kirk, fatdog64...
KERNEL=="audio0", SYMLINK+="audio"
KERNEL=="dsp0", SYMLINK+="dsp"
KERNEL=="mixer0", SYMLINK+="mixer"

# sound devices (oss) -- got this from gentoo rules --needed?
SUBSYSTEM=="snd", GROUP="audio"

i applied these changes, rebooted. The system came up exactly as before, same number of modules loaded (59).

Tags: easy, quirky

Revisiting pup_event

February 15, 2018 — BarryK

Due to dissatisfaction with available service managers, I am thinking of writing my own, as an extension of "pup_event".

In June 2013, I wrote pup_event_frontend_d.bac, BaCon code. /usr/local/pup_event has this utility, plus some more scripts. The main objective was to manage hotplugging, for example to detect when a USB drive is plugged in or removed.

I announced pup_event_frontend_d.bac here:

It was very creative, totally different from any other Linux distro. Not long after that, I retired from the Puppy development "front line".

Actually, the concept of pup_event started earlier, circa 2008, see this post:

...the post has links to some documentation, which has moved, now here:

Fast forward to today, I wondered what has happened to pup_event in woof-CE. There has been a lot done to it, mostly by "wdlkmpx". For example, he rewrote pup_event_frontend_d in C:

...that page is an earlier version. Since then, it got moved, and there have been more commits.

For myself, I like BaCon, and will probably stay with it.

I think that pup_event can be easily extended to be a service manager. My tentative thinking is to remove /usr/local/pup_event_frontend_d (which is launched from /root/.xinitrc when X starts), replace with pup_event_backend (that will be launched from /etc/rc.d/rc.sysinit).

This new pup_event_backend will do the same as pup_event_frontend_d, but a couple of extra things, including service management.

There are a couple of old scripts in /sbin:


These were developed back around 2008 - 2012, in collaboration with "rerwin" (Richard Erwin).

There are still in woof-CE, untouched since being imported from Woof2, four years ago:

I don't know if we need them anymore. Perhaps not. They were developed in the days of 'module-init-tools', before 'kmod', when the kernel did not have automatic /dev node creation and automatic firmware loading.

That early backend stuff is described in the above link, here it is again: 

Tags: easy, quirky

Experimenting with Busybox Runit

February 14, 2018 — BarryK

Refer to these posts yesterday:

I have been wondering more about why I find daemontools and derivatives to be unsatisfactory. I think that the developers are system adminstrators, and have a particular mindset. They are developing for systems that have fairly fixed software and interfaces, not for generic desktop systems.

Also, I have struggled with the documentation. Regarding Runit, one person commented:

"Runits documentation is so bad that I had to learn it by experimentation, even though I know its ancestor daemontools inside and out."

I was also hampered by the documentation of the Busybox implementation of Runit. "sv --help" showed the commandline options, which lead me to believe it was only a subset of the full 'sv' utility. Options such as "check" and "start" were missing. Until I looked at the Busybox 'sv.c' source, and saw that those options are supported.

Anyway, my simple requirement for some services to be dependent on a network up. It was not explained in the official docs, found some info after much hunting...

I created a service named "network", by creating a folder '/etc/sv/network'.
Inside, created two scripts, 'run' and 'check'. Contents of 'run':

#sleep forever...
sleep 9999d

Contents of 'check':

exec 2>&1
#exit with 0 if network is up (exclude 'lo')...
UP_IFS="$(grep -l '^0$' /sys/class/net/[^l]*/dormant | cut -f 5 -d '/')"
#...ex: /sys/class/net/eth0/dormant, cut 'eth0'
if [ "$UP_IFS" ];then
 exit 0
 exit 1

Now, if another service specifies "network" as a dependency, the 'network/check' script will be run, and if returns "0" then yep it is running.

So, I created '/etc/sv/test_net', with script 'run':

exec 2>&1
sv -w10 check network
if [ $? -eq 0 ];then
 echo 'up' >> /tmp/zz-net
 sleep 99999d
 echo 'down' >> /tmp/zz-net
 exit 1

...this is just a dummy script. A real service might be to start a daemon instead of that "sleep 99999d".

The key line in that script is "sv -w10 check network". This will run the 'network/check' script. If 'check' returns non-0, the above 'run' will exit with non-0. The Runit supervising utility 'runsvdir' will wait one second, then try again, that is, rerun 'test_net/run', and will keep at it until the network is up.

This is the official way to do it, and at this stage I was thinking "Oh my goodness gracious me, surely not!" (or words to that effect). But yep, that's it, a polling loop. Furthermore, if several services have the same "network" dependency, they will all independently be calling 'network/check'.

Then I recalled something that I had read in the 's6' docs, at

"Neither System V init, daemontools, runit or perp provides any hooks to wait for a service to go up or down. runit provides a waiting mechanism, but it's based on polling, and the ./check script has to be manually written for every service."

It is a pity that I am not happy with Runit, as the Busybox implementation is tiny. I reported yesterday that I recompiled Busybox statically, adding the Runit applets and three extra network applets. The size of the stripped binary grew from 933KB to only 965KB.

Tags: easy, quirky

Ninit: Minit on steroids

February 13, 2018 — BarryK

Ah, maybe I have found "the one"!

As I lamented in the previous blog post, I found the service managers derived from daemontools to be very restricted:

Minit is one of them:

Ninit was forked from Minit, by Nikola Vladov, and considerable thought has gone into extending the usefulness. Dependency options are now looking very good.

Minit and Ninit are both intended to be compiled statically with dietlibc, and I have done that. Host is Quirky Xerus64 8.4, which has dietlibc in the "devx" PET.

A quick note on how to compile Ninit. I edited the 'Makefile', set "DIET=/usr/bin/diet", and had to create a symlink:

# ln -s lib /usr/lib/diet/lib-x86_64
# make
# make install

Back in the mists of time (2012 actually), I created a PET for Minit:

It has etc/minit, which which is a quick hack to make Minit work in an unchanged Puppy. It sets up a replacement for /etc/inittab and runs the usual /etc/rc.d/rc.sysinit.

I copied etc/minit/* to /etc/ninit/. Then inserted "init=/sbin/ninit" into the kernel boot parameters, then rebooted. Hey, it's working, back at the usual desktop!

This sets up the infrastructure for service management. One thing that I am keen to do is implement services that are dependent on a network connection.

Now, about Ninit. It is a dead project, however has been preserved here:

If you download this, it is version 0.14.

More info is here: 

Tags: easy, quirky

Thinking about service managers

February 13, 2018 — BarryK

These are just "out loud" thoughts...

There are many service managers that derive from, or were inspired by, a package called 'daemontools'. Runit is one of them.

I have been sifting so many of the service managers, with maybe init replacement, but have always been left discontented.

Trying to pin down why this discontent...

The emphasis on automatic restarting of daemons. Why? If a daemon crashes for some reason, I don't want it to be automatically restarted.

The lack of support for one-shot services.

Incomplete dependency management. For example, I want a service to wait until there is a network up. Nothing else to be held up. I know that I can do it by examining /sys/class/net/dormant, but fitting this in as a dependency is at best a klutz, as far as I can see, in the service managers that I have looked at.

There are lots of init replacements with service management, such as minit, ninit, cinit, myinit. Or, service management with optional init replacement, such as runit and s6. Then there are some that are service managers only, such as serel.

I got excited that Runit applets are in Busybox, until I realised how limited it is. Not the Busybox implementation, the fundamental concept of daemontools. Unless my understanding has not fully grasped the capabilities, which is possible.

Here is another...


OpenRC is developed for Gentoo, and adopted by some other distros. It is a service manager, though apparently can become an init-replacement. What is particularly interesting is that thought has gone into using it with Busybox and Busybox's init:

Download source:


However, I was unable to compile it statically, so have taken it no further.

Will keep researching...

Tags: easy, quirky

Busybox 1.25.1 Runit applets

February 13, 2018 — BarryK

There is a problem with all the puplets, including Easy and Quirky. Well, unless a developer has tackled in it their puplet.

The problem is the order of execution of service scripts at startup, for example, those in /etc/init.d -- we execute those in a fixed order, however, that is barely adequate.

It may be that a certain service script should only run after there is a network connection, for example. Or sound is working, or X is running, and so on.

I have been looking at various solutions, and liked the look of Runit. Homepage:

Then, surprise, surprise, I found that the Runit utilities are in Busybox. They are:

chpst, setuidgid, envuidgid, envdir, softlimit, runsv, runsvdir, sv, svlogd

Using Landley's Aboriginal Linux, the older chrootable filesystem with uClibc (he has shifted to musl, unfortunately), I have compiled Busybox statically with those Runit applets enabled. I also enabled these network applets:

inetd, udpsvd, tcpsvd

Here is the PET:

...however, don't install it, as it will replace all the "full" utilities with symlinks to busybox. For example, 'sort' and 'date'. If you really want to use it, open it up with the 'pet2dir' utility, then copy the 'busybox' executable, then the above applet symlinks.

I have also compiled 's6' statically, and there are PETs, however, it is a solution that will add megabytes to the build. So, at this stage I am favouring Busybox Runit. To actually use it, is next on the agenda.

Here is an interesting read: 

Tags: easy, quirky

woofQ uploaded, 2018-02-11

February 11, 2018 — BarryK

This is the latest woofQ, as used to build Quirky Xerus 8.4.

Uploaded as a tarball here:

I also updated the woofQ Bones repository. Read about Bones here:

And woofQ and Bones here: 

Tags: easy, quirky