avahi: enable adding services without writing to flash

[RussellSenior]

Maintainer: @thess Environment: all arch's, for master branch (and others)

Description:

I have an application that wants to advertise a service with avahi. However, avahi-daemon wants to advertise services found in /etc/avahi/services (servicedir=$(pkgsysconfdir)/services in Makefile.am). Since, normally this path lives on flash, it introduces flash wear with writes. I have had a local hack for several years, which modifies Makefile.am to substitute: "servicedir=/tmp/avahi/services" instead, and also copy the files http.service and ssh.service from the persistent /etc/avahi/services/ directory to the tmpfs directory.

Ideally, I think service files should be installed by their respective packages, and the avahi package shouldn't carry the http and ssh services files.

This works, and I can keep on maintaining my hack without too much trouble, but it seems like this is a feature that could benefit other services, and I wonder if this feed is open to taking my hack or something that accomplishes the same thing. Here's the patch:

From 8dc7b7d47a279e25c4ac4c4f8dedf6fc2c33d9c6 Mon Sep 17 00:00:00 2001
From: Russell Senior <russell@personaltelco.net>
Date: Tue, 2 May 2017 19:34:21 -0700
Subject: [PATCH] avahi: move servicedir to tmpfs

Signed-off-by: Russell Senior <russell@personaltelco.net>
---
 libs/avahi/files/avahi-daemon.init                   |  3 +++
 libs/avahi/patches/020-hack-services-directory.patch | 10 ++++++++++
 2 files changed, 13 insertions(+)
 create mode 100644 libs/avahi/patches/020-hack-services-directory.patch

diff --git a/libs/avahi/files/avahi-daemon.init b/libs/avahi/files/avahi-daemon.init
index f580a31d8..191ec8b71 100644
--- a/libs/avahi/files/avahi-daemon.init
+++ b/libs/avahi/files/avahi-daemon.init
@@ -4,8 +4,11 @@ START=61

 USE_PROCD=1
 PROG=avahi-daemon
+SERVICES_DIR=/tmp/avahi/services

 start_service() {
+       mkdir -p $SERVICES_DIR
+       cp /etc/avahi/services/*.service $SERVICES_DIR/
        procd_open_instance
        procd_set_param command "$PROG"
        procd_append_param command -s
diff --git a/libs/avahi/patches/020-hack-services-directory.patch b/libs/avahi/patches/020-hack-services-directory.patch
new file mode 100644
index 000000000..e39c7d858
--- /dev/null
+++ b/libs/avahi/patches/020-hack-services-directory.patch
@@ -0,0 +1,10 @@
+--- a/avahi-daemon/Makefile.am
++++ b/avahi-daemon/Makefile.am
+@@ -24,7 +24,7 @@ if HAVE_LIBDAEMON
+ if HAVE_XML
+
+ pkgsysconfdir=$(sysconfdir)/avahi
+-servicedir=$(pkgsysconfdir)/services
++servicedir=/tmp/avahi/services
+ introspectiondir=$(datadir)/dbus-1/interfaces
+ dbussystemservicesdir=$(datadir)/dbus-1/system-services
-- 
2.26.0

[karlp]

Could your apps just be switched to advertising via umdns instead? It's what I've done with my services at least.

Generally, I'd rather see if it could be an extra directory, instead of requiring it to take up space in the ramdisk. (flash isn't free, but neither is ram) Are you really rewriting these service files frequently enough that this matters?

[mhei]

I think this use-case should be discussed with upstream, OpenWrt should then add support for upstream's solution. However, I think should elaborate our your application, e.g. why do you use files instead of the avahi client library etc.

[RussellSenior]

@karlp the service files are tiny, 300 bytes or so. In my case, the service file is indicating a port number that changes on every service restart, so yes they change frequently. I'll take a look at umdns.

@mhei my guess is that upstream doesn't consider flash wear is a problem within their scope. We use files because they are easy to understand, small and the first thing we tried.

[mhei]

@RussellSenior : I fully understand your use-case. In my company, we did the very same. Creating a dedicated C program to just run in the background vs. a tiny shell script can assembly the service file with a few lines of code... We then tried to create the service file in /tmp and installed a symlink in /etc pointing to this file. However, it was necessary to compile Avahi with a special compile time option because is otherwise runs chrooted or so and thus the symlink could not be referenced... BTW: I would expect that upstream at least listens to its user's use-cases. Just try it, if you have no success, then we can still talk about a special OpenWrt solution...

[RussellSenior]

Trent Lloyd replied to my query thusly:

Generally you would just the Avahi API to advertise your service instead of dynamically updating the “static” service files (which is what they are generally designed for - unchanging manual services). Is there something that prevents you from doing that? Or a reason you haven’t before now? You could also as a “hack” just launch an instance of the avahi-publish-service CLI tool.

Seems my attempt didn't get much traction.