philippe44 / AirConnect

Use AirPlay to stream to UPnP/Sonos & Chromecast devices
Other
3.53k stars 218 forks source link

[Docker] Files not saved correctly when using a docker volume in bind mode #535

Open GioF71 opened 3 months ago

GioF71 commented 3 months ago

Hello, I am using your application with Docker. I have just discovered that, if my configuration file is read/created/written inside a directory mounted to the container, the expected changes are never actually reflected to the configuration file.

When using a docker volume instead of a bind directory, everything works properly: a newly discovered device can be found in the config file, while this is not the case when using a bind directory. The problem is that with this limitation, it is quite complicated/convoluted to make changes to the config files, because I should run a container which would mount the relevant volume in order to be able to edit the file. Or I need to access the host path for the docker volume, and this requires elevated permissions (sudo), while the container internally runs as a normal user.

Is there any chance that the file modifications are not flushed immediately? I am just asking. I tried to wait for a while but the expected changes never happen when using the bind directory.

Currently, I am solving the issue using a docker volume, then I edit the file with sudo from where the volumes are actually stored on the host system. Example:

sudo vi /var/lib/docker/volumes/airconnect-config/_data/airconnect-upnp-config.xml

but it's convoluted and prevents me to be able to add the configuration file to a git repository without manual operations and/or scripts.

I understand that maybe running in docker is not something you support, but any comment and/or suggestion is welcome.

philippe44 commented 3 months ago

I might have read to quickly but I'm confused. Do you want the modifications to NOT be flushed immediately? I would have thought the opposite.

GioF71 commented 3 months ago

Infact, of course I'd like the modifications to be flushed immediately. It's the only thing that comes to my mind that might possibly fix this kind of issue. I have reproduced it quite systematically, although I can only suppose it might be due to this aspect. Thank you for your attention.

philippe44 commented 3 months ago

Ok, that is probably an easy fix, I'll just flush fwrite() then

philippe44 commented 3 months ago

Argh no, every time I update the config file, it's an fopen a fwrite and a fclose, so it is already flushed

GioF71 commented 3 months ago

Hello, thank you for looking into this. Much appreciated. I have to say I kind of suspected that this was not the real issue, because when the docker volume is involved, I immediately see the discovered devices written on the file. That seemed to already indicate that the file is always flushed.

Still it was worth trying at least to try and understand with you what is the real issue. I even thought that it could be vscode somehow locking the files, but it happens even from the bare command line.

Anyway I thought about a workaround: a pair of scripts that pull and push the file from/to the volume should do the trick. Only a bit more convoluted.

Again, thank you!

GioF71 commented 3 months ago

One question... considering that the most common operation I do on the configuration file is just disabling some "virtual device" I don't want to create, would it be possible to support an "ignore-list"? It might be OK either from a file or from a command line switch. That would eliminate the need to edit the file in a lot of circumstances. Thank you!

GioF71 commented 3 months ago

Hello, further testing show that the issue is independent of the volume type (bind directory or docker volume). Only if the container does not mount the "/config" directory, the contents of the file are kept updated with the discovered devices. I have verified that by looking at the contents of the file from inside the container and copying the file from the container to the local file system. In all the other cases, it looks like the file does not update anymore after a while. So I can only copy the files to/from the container (while it is stopped when copying to it, so I don't interfere with its work). The workaround can still be put in place, although a little differently from what I was thinking.