site  contact  subhomenews

New 'getlocalip' utility

February 25, 2018 — BarryK

I am working on pup_event, and in 'pup_event_frontend_d' I have been exploring various ways of determining when a network connection is up or down.

An offshoot of that, is I wanted a very quick and efficient way to determine the local IP-address, that is, the IP address assigned to the computer, that other computers on a network will use to access this computer.

It can be found by the 'ifconfig', 'ip' and 'hostname' utilities, though I hasten to add, not the Busybox 'hostname'. The full 'hostname' has this option:

    -I, --all-ip-addresses all addresses for the host

...that is, a capital letter I, as in "India". In my case;

# hostname -I

I thought that it would be nice to have a specialized utility to return the local IP-address. I thought about parsing /proc/net/fib_trie, however, after a bit more research, settled on this simple C program:

#include <arpa/inet.h>
#include <ifaddrs.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
int main(int argc, char *argv[])
struct ifaddrs *addrs, *tmp;
tmp = addrs;

while (tmp)
if (tmp->ifa_addr && tmp->ifa_addr->sa_family == AF_INET)
struct sockaddr_in *pAddr = (struct sockaddr_in *)tmp->ifa_addr;
printf("%s: %s\n", tmp->ifa_name, inet_ntoa(pAddr->sin_addr));
tmp = tmp->ifa_next;

Running it:
# getlocalip
...bonus, it also shows the interface, in this case "eth0".

I got that code from here:

The source is in 'pup-tools-20180225.tar.gz':

BaCon Forum member 'airr' has converted it to BaCon code:


'getlocalip' will be in the next release of Easy and Quirky, in /usr/sbin.

Tags: easy, quirky

Network upgrading for Frisbee 1.4.7

February 23, 2018 — BarryK

The latest and earlier releases of EasyOS and Quirky have Frisbee, version 1.1-20130415-modified, a network manager developed by Puppy Forum member 'Jemimah', with improvements by various people including forum member 'rerwin'.

rerwin (Richard Erwin) has continued to develop Frisbee, and has now reached version 1.4.7, see forum thread here:

rerwin has looked at EasyOS 0.7 and determined what needs to be updated to support Frisbee 1.4.7:

I have worked through rerwin's changes, and have applied all of it to woofQ, so the next releases of EasyOS and Quirky will have it.

The old Frisbee PET has been retired. I renamed it to, and have kept it in the 'noarch' repository.

Easy and Quirky will now be built with

rerwin posted changes to /usr/local/frisbee/disconnect and /etc/init.d/frisbee, however, as those files are from the old frisbee PET, they are now removed.

These are all the files modified by rerwin, that are upgraded in woofQ:

/usr/sbin/connectwizard, connectwizard_2nd, network_default_connect, networkdisconnect

I am expecting the next release to be EasyOS Pyro64 0.7.4, in a few days. It will have the above network upgrades, plus the pup-event service manager. The former adds a new enhanced choice for network connection, the latter should be an un-noticed under-the-hood thing.

Tags: easy, quirky

pup_event Service Manager

February 23, 2018 — BarryK

I posted recently about investigations into "service managers", in the context of starting and stopping services, such as CUPS, Samba and SSH daemons, as dependencies are met or not met.

Unsatisfied with what is available, I have developed my own system. Actually, this was in the back of my mind when I originally created pup_event, a background hotplugging and IPC messaging/synchronization system for Puppy circa 2013.

pup_event Service Manager starts and stops the services in /etc/init.d, determined by dependencies rather than just alphabetical order. It is a tiny implementation, in terms of very tiny resource usage and tiny file size. Extreme efficiency, event-driven. Also very simple to understand and use.

Documentation will be in upcoming EasyOS and Quirky releases, in /usr/local/pup_event, however, I have also uploaded the doc files:

...that second link describes the pup_event IPC that I implemented in Puppy Linux circa 2013, but recently it has been removed from the woof-CE builds of Puppy.

So, this Service Manager will only be in the next releases of EasyOS and Quirky. However, it will be possible to create a PET package for other pups and puplets.

Tags: easy, quirky

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