Open RussellSenior opened 4 years ago
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?
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.
@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.
@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...
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.
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: