0

There is my daemon that sends and receives data via TCP and UDP. Logical connection is often a group of such streams.

I'm going to make a web page to report the types of these connections and how much data has been transfered. Can't do that by just calling netstat, because it's hard to figure out which connection is which, especially with UDP that can change ports. So, the daemon should accumulate the statistics.

I don't want to put the web server inside the daemon. Don't want to write statistics constantly into a file.

The good idea is used in /proc kernel filesystem, where the reads on files from that filesystem invoke functions in the application. It works on-demand. Would be nice to have something like that.

Are there any examples of some existing UNIX/Linux daemons that have such requirements? What do they do?

Velkan
  • 7,067
  • 6
  • 43
  • 87

2 Answers2

0

I believe /proc files are usually only defined to read and set Kernel parameters, not those of daemons.

Docker uses a unix socket (usually on /var/run/docker.sock), which accepts HTTP requests and implements a REST API. This is handy for your report application, but obviously an overhead for your daemon.

You could also create a named pipe for your daemon, e.g. in /var/run/myd.info to which you periodically, or on demand, send your information as text.

There is already an implementation of a named pipe writer that does not break on SIGPIPE (the signal when the other end has stopped reading the pipe, i.e. when you send an EOF).

Community
  • 1
  • 1
Nils Werner
  • 34,832
  • 7
  • 76
  • 98
0

You can create your own /proc file and 'write' data to it. It's a common way, I can remember SCST which allows you to read and even control daemon resources using their own /proc/ branch.

Take a look here: http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-11-adding-proc-files-your-modules-part-1

But you will need to create a kernel module with your daemon to use this feature.

Maybe sqlite database and some simple API on your daemon is an option here?

Tim Connor
  • 97
  • 2