site  contact  subhomenews

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

Quirky Xerus x86_64 version 8.4 released

February 09, 2018 — BarryK

It has been awhile since the last release of Quirky. That was version 8.3, in July 2017:

Now, a brand spanking new version. Announcement and release notes here;

A brief announcement:

Quirky Linux 8.4 x86_64 is codenamed "Xerus" and is built using the woofQ Quirky Linux build system, with the help of Ubuntu 16.04.3 binary packages. Thus, Xerus has compatibility with all of the Ubuntu repositories.
Quirky is a fork of Puppy Linux, and is mainly differentiated by being a "full installation" only, with special snapshot and recovery features, and Service Pack upgrades, though recently there is limited support for live-CD session-saving and "frugal" installation.
Version 8.4 has many architectural improvements and package upgrades, including new packages Sakura, Refind, EasyApps, PupControl, VTE and EasyShare. EasyShare is a simple "one top shop" for network file sharing and printing, using Samba and SSHFS. Upgraded applications include Pclock (0.8.2) and seaMonkey (2.49.1). The Linux kernel is now version 4.14.17

Quirky is shipped as an ISO file or a Flash-drive image file. Instructions to install are here:

Primary download site:

This is a third option, install scripts:

...for experts only.

To join in with discussion on Xerus 8.4, go to the Puppy Forum:

Have fun!

Tags: quirky

Toto Link wifi/ethernet router/repeater

December 11, 2017 — BarryK

In the Puppy Forum thread where we are testing Quirky Pyro64 0.6, it was reported that Samba is not working. I wasn't much help, as I had to admit that I have never used Samba. A bit embarrassing really, considering what I "do".

Yesterday, decided that the time has finally arrived when I would setup Samba. First though, I need a little local network. I access the Internet via my mobile phone, no land line. So, wifi tethering turned on in my Android phone, no problem connecting to the Internet for any of my PCs.

I did wonder whether the phone itself could be used as a local wifi network. That is, each of the PCs connected to the phone being able to share files between each other. I have read conflicting reports about whether that is possible.

Anyway, I have an old router, have put it back in service. This is a Toto Link N100R+ V2, picture here:


This is old technology, 150mb/s wifi, 100mb/s ethernet, but OK for now. My model is no longer sold, the latest is N100RE:

On my desk there are two PCs, my midi-tower and Mele mini-PC. The latter dual-boots Linux and Windows 10, so I plugged it into "LAN1" on the N100R and powered up, then went to the "" in my browser. Default login is "admin", "admin".

I clicked "Operation Mode" then the "Wireless ISP" radiobutton. Then clicked "Wireless" from left side, then "Basic Settings" and the "ScanAP" button. It detected my phone SSID and chose "WPA2-PSK" and "CCMP", and entered the password. That's it, had Internet access!

On the Win10 mini-PC, was now connected to the Internet via ethernet. In the "Setup", looked around a bit, but basically just enabled "Turn on network discovery" and "Turn on file and printer sharing".

For the midi-tower, plugged an ethernet cable into "LAN2" on the N100R, and fired up Quirky Xerus64. Fiddled around a bit, but essentially just ran 01micko's Samba Simple Management.

Over on the Win10 machine, in the file manager, there is "Network" on the left side. Clicked that, then right-clicked on the right-side and chose "Refresh". Yay, got "PUPPYPC11067", which is my midi-tower. Clicking on that, it asked for username and password, which is "root" and "woofwoof".

Next step is to get it going on Quirky Pyro64...

Tags: tech, quirky