"Darling erasure" and data for long-running services

Help
1

When learning NixOS, I found references to the concept of “darling erasure” and the value of resetting the root file system between reboots to keep the system clean and having control over the configuration. I think this makes a lot of sense but I have not seen so many references to this with respect to data that is maintained by services. For example, data below /var/lib and /var/cache is often where a service stores the data it maintains. It is certainly possible to redirect this data on a service-by-service case, but I wonder if it makes more sense to exclude these directories from “darling erasure” entirely.

To give an example, the navidrome and jellyfin media services both maintain their databases there, and both seem to take advantage of systemd’s conventions in this regard. From Dynamic Users with systemd :
" With systemd 235 this limitation is removed: there are now three new settings: StateDirectory= , LogsDirectory= and CacheDirectory= . In many ways they operate like RuntimeDirectory= , but create sub-directories below /var/lib , /var/log and /var/cache , respectively. There’s one major difference beyond that however: directories created that way are persistent , they will survive the run-time cycle of a service, and thus may be used to store data that is supposed to stay around between invocations of the service."

I am considering creating separate subvolumes in my btrfs setup to exclude them from root, because of this. Do you think this makes sense, or do I miss the point of darling erasure with that approach?

2

Very broadly:

  • having the services be more structured and more explicit about declaring their storage and behaviour will be helpful if we want to make additional declarative use of that info
  • splitting cache and logs from other state is a great start
  • whether a given directory needs to be retained or not will still end up being a service-specific decision, primarily based on whether you can declaratively create that state or it needs to be collected and kept over time.

I don’t think you’re missing the point at all, but it’s a reality that some of the services are, either just through inconvenient implementation and assumptions, or fundamental nature.

3

Part of the point of darling erasure is that you don’t trust the programs and services you run to know which state you care about. You specify it yourself.

It’s reasonably common that a program (or rather its creator) thinks that some state is important to be kept long-term, and you just don’t agree. That’s extra state, complexity, and room for unexpected behaviors, that you don’t need.

2 Likes
4

Very valid, but still something that needs to be a service-specific decision