Proper fix for network tray applet

July 03, 2025 — BarryK

A workaround for network interface "up" not getting detected in the network tray applet was posted earlier today:

Workaround for broken network tray applet — July 03, 2025

I would prefer to fix the problem properly; had an afternoon nap, woke up, and thinking cleared what the cause of the problem, and solution, is most likely to be.

EasyOS has pup_event service manager; this executes the scripts in /etc/init.d in accordance with each meeting certain dependencies, such as Xorg running, or network up. These dependencies are in the variable PE_SERVICE_MANAGER in file /etc/eventmanager:

PE_SERVICE_MANAGER='network%cups-net-fixONESHOT:qsyncONESHOT:dnsmasq:ec-net:openvpn:rc.samba 
                    bluetoothhw:dbus%bluetooth:bluealsa x%pulseaudio:pupnetworkONESHOT'

For example "bluetoothhw:dbus%bluetooth:bluealsa" means that scripts 'bluetooth' and 'bluealsa', if they exist, will only run, with passed "start" parameter, when there is bluetooth hardware detected and dbus is running. Either of those depencies goes down, then the scripts will be executed, in reverse order, with "stop" passed parameter.

The pup_event service manager is described in /usr/local/pup_event/pup_event-service-management.htm, also online here.

It seems, maybe, that the daemon /usr/bin/NetworkManager, launched from /etc/init.d/network-manager (or rc.networkmanager in earlier EasyOSs), is bringing up the network interface too soon, before /usr/local/pup_event/pup_event_frontend_d daemon (launched from /root/.xinitrc) has started.

Either that, or something is wrong with 'pup_event_frontend_d' or the IPC mechanism binary 'pup_event_ipc'.

Scripts in /etc/init.d that do not have dependencies specified in PE_SERVICE_MANAGER will run immediately, in alphabetical order. The script that does this is /etc/rc.d/rc.services

'network-manager' is one of those, without dependencies. Being mindful of possible dependency-loops, why not make 'network-manager' a dependency of Xorg having started, like this:

x%network-manager:pulseaudio:pupnetworkONESHOT

Firstly though, thinking how does "x" dependency actually get detected? This is 2019-and-early-2020 stuff, I can't remember. To explore, find what writes to that 'x_' file:

# grep -rl '/tmp/pup_event_backend/x_' .
./etc/rc.d/rc.services_ipc

That 'x_' file is working, I just want to recall how. Note, pup_event also sends an IPC message via /tmp/pup_event_ipc/x_*, which is how the service-manager detects dependency occurrence. Here is some code from /etc/rc.d/rc.services_ipc:

  #200213 detect if dep already avail...
  [ -s /tmp/pup_event_backend/${aDEP}_ ] && MSG1="$(cat /tmp/pup_event_backend/${aDEP}_)"
  [ ! "$MSG1" ] && MSG1="$(/usr/local/pup_event/pup_event_ipc "${aDEP}:${$}")" #***WAIT FOR FILE CHG***
  #...ex: network:12345 MSG=eth0 or MSG='' (empty, meaning i/f gone down)
  [ ! "$MSG1" ] && continue 2
  if [ "$aDEP" == "x" ];then #180301
   DISPLAY=":$(grep -o '[01]' /tmp/pup_event_backend/x_)"
   export DISPLAY #ex: :0
  fi

...$aDEP is one of the dependencies, for example "x". File 'pup_event_ipc' is a binary executable and it waits to receive an IPC message from /tmp/pup_event_ipc/x_${$} Note, it is an efficient wait using inotify, not polling.

So, what sends that message and also writes to /tmp/pup_event_backend/x_? That is the daemon /usr/local/pup_event/pup_event_frontend_d, launched from /root/.xinitrc

Anyway getting to the real point of this explanation, will add 'network-manager' as a dependency of 'x':

PE_SERVICE_MANAGER='network%cups-net-fixONESHOT:qsyncONESHOT:dnsmasq:ec-net:openvpn:rc.samba \
        bluetoothhw:dbus%bluetooth:bluealsa x%network-manager:pulseaudio:pupnetworkONESHOT'

I rebooted, and hey, the network tray applet is working, and /tmp/pup_event_backend/network_ contains "wlan0". Great, well should do multiple reboots to be sure. Did it twice, working. I'll be optimistic and take out that workaround posted in the previous blog post.

Tags: easy