Feature request, Multiple env files for a single service

[hongkongkiwi]

Hi there,

I'm building a system which has env files for each service stored in /etc/default/<service>

I would like to allow users to override variables using a read-write directory, so for example something like /mnt/flash/etc/default/<service>

So, I would like to be able to read multiple env files. For example:
env:-/etc/default/foo,/mnt/flash/etc/default/foo

This way, we require that /etc/default/foo exists and this provides our hardcoded variables. However, after reading that, /mnt/flash/etc/default/foo is read and if the variable has the same name.... e.g. FOO_OPTIONS then it would just overwrite as the variable files would be read in order of left to right.

This means the user can optionally create a /mnt/flash/etc/default/foo file and overwrite some (or all) of the variables. I was thinking we could have the same format, so this would also be valid if we wanted it to error if flash env doesn't exist:
env:-/etc/default/foo,-/mnt/flash/etc/default/foo

Would it be possible to add this feature? The only way right now I think to do this is to use a script to call my service which is less than ideal.

[troglobit]

Anything's possible, but I have no need for this myself, and it would require quite a lot of work to change current data structures and inotify watchers to handle.

I'm saving this but putting it on milestone future. Maybe someone else wants it too and can do the leg work.

[hongkongkiwi]

Thanks for considering.

In the meantime, I'll source env1 in finit.conf then call a script which first sources a subsequent env file, then exec the app. I think it can be a reasonable workaround.

[hongkongkiwi]

As another simple idea, could we have a default-env:"/etc/default/my.env" extra and then no need to change the way env:"/mnt/flash/my.env" works.

[troglobit]

The problem is that the env files are considered part of the configuration of that service, so when either the env file or the .conf file changes, Finit registers this and knows which services to restart/SIGHUP when it receives initctl reload. So either way it's a lot of work and I'd rather have a uniform concept that worked for more use-cases.

[hongkongkiwi]

I think this can actually work already when #248 is implemented.

if an additional env file is required (such as in my case) it can be sourced in the pre script.

[troglobit]

True, thanks for following-up on this!