Running another python process (or few?) might take up more mem than I'd like.
But perhaps better aggregation of system stats:

https://psutil.readthedocs.io/en/latest/#system-related-functions

I am running the following with i3 and lemonbar

Operating System: Debian GNU/Linux 8 (jessie)
Kernel: Linux 3.16.0-4-amd64
Architecture: x86-64 

I have followed the installation instructions and when I run statbar I get the following output

statbar
creating or accessing shared memory: No such file or directory
Spawning data daemon
creating or accessing shared memory: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
module # 4, hang up on poll
module # 1, hang up on poll
module # 10, hang up on poll
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
module # 6, hang up on poll
module # 8, hang up on poll
unlinking shared mem: No such file or directory
module # 3, hang up on poll
module # 2, hang up on poll
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
module # 9, hang up on poll
module # 7, hang up on poll
unlinking shared mem: No such file or directory
module # 5, hang up on poll
unlinking shared mem: No such file or directory
module # 0, hang up on poll
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
creating or accessing shared memory: No such file or directory
failed to connect to daemon

When I try to run statd I get the following

statd
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
unlinking shared mem: No such file or directory
module # 0, hang up on poll
module # 1, hang up on poll
module # 2, hang up on poll
module # 3, hang up on poll
module # 4, hang up on poll
unlinking shared mem: No such file or directory
module # 5, hang up on poll
module # 6, hang up on poll
module # 7, hang up on poll
module # 8, hang up on poll
module # 9, hang up on poll
module # 10, hang up on poll
(hangs)

Have you come across this issue before and/or have a work around?
EDITI I installed the package using checkinstall if that makes any difference.

clicking, triggering a popup, and letting it die is creating defunct processes/zombies. Need to read exit status and let them get cleared

Pros

• no more statbar checking for and launching statd
• fix bug where shmem file exists, but statd is dead and statbar hangs doing nothing
• possibly no more daemon (statd) at all
• some modules can run via systemd.timer and not sleep-loop
• better fault handling and logging, more easily restarted when things crash
• zombies, etc should be fixed
• double-client layer bug could be fixed

Cons

• statd had some environment logic which will have to be moved to all the .service files
• program becomes systemd-only? adds a heavy dependency there
• how to communicate with client now, without shmem?

Currently fixed at Y=32 due to conkup. Should be relative to click, since the status bar may not always be at the very top.

If it's actually hugging the bottom, that becomes even more annoying.

datetime is probably good enough. Only wakes up during minute change.

network can probably be pinged by events. E.g. onconnect, ondisconnect events of network manager can send SIGUSR2 or something to network to inform of network change events. Can still poll every 20m or so for uncaught events.

transfer may not be able to slim down much more

bluetooth maybe pushed events like network

mem may be reasonable

cpu - calling top -bn 2 is surprisingly slow and takes a lot to process the rest. This one is running most often, and usually has a CPU impact. Probably best target to focus on. May be worth writing in C, either as self-contained binary in modules, or even a function inside the client that spawns off a thread.

gpu - already reduced to single call to nvidia. Probably not much more to be done, except hide some of the info (RPM?) by default and show on click. Reduce the scope of the common query

packages - Probably fine, maybe adjusting some of the text processing to do better. Currently not -Sying pacman itself, and is relying on an external cron job to do that. Loses it's usefulness when not updating. Should bring the update call inside (but privileged command! oh joy).

uptime - Would like to see this have a timer roll off, or proportional to the uptime. Every couple minutes right after boot, then every dozen minutes, every hour.

weather - can probably sync this with NOAA update schedule

linux - runs once. Works for me.

When killing stat(d|bar) via kill, some processes that are blocked on a read are not cleaned up. This is usually the bspwm subscribe and the mocp music listener

Sometimes, on crashes, /dev/shm/statbar is left behind, and not appropriately detected as "dead" on next run. Client will hang waiting for data

Right-clicking the icon might 'pause' updates for a module until unpaused?

middle-clicking might update immediately? This is particularly useful for the packages module where immediately after an update, I want to see the numbers hit 0, or stop being red. Or network module to check VPN status. Although some of this is solved already with left-clicking and taking the popup as a more authoritative current state than what's in the bar. Perhaps left click should also force-update the bar, so they agree (bar and popup).

With error message:

Invalid geometry for the clickable area

Happened initially at 11 desks ( 8 | 3 ). Reducing to 10 ( 7 | 3 ) fixes. 11 again at ( 7 | 4 ) rebreaks.

Should probably write man pages for statbar and statd. Even though current calling conventions are limited, future could be different.

Add in a usage string

-h and --help are good to support. Print out the usage string.

-v and --version also good to add.

occasionally seeing a flicker of the bar text.

Possibly to do with two modules signaling too quickly together and updating twice too rapidly.