primeval_god

Those labels are useful for scripting as well. Some of dockers cli commands include a filter option which can filter containers by label or the contents of a label. For containers started by compose you could use the contents of the labels to reconstruct the flags needed for a docker compose command (look at the --format option of docker inspect for how to easily pull values from specific labels). The fact that the docker compose command line doesnt natively do this for a lot of its commands (other than the commands that create a stack in the first place) has frustrated me for a while.

What I was referring to has nothing to do with the override file or my plugin at all, I was talking about labels added to containers by docker compose. Run docker inspect on a container that was started by compose and look at the labels section.

For doing userscripting of compose projects i suggest looking into what information can be found in the container labels that docker compose adds to each container. If i remember correctly the paths to the compose files used in the project are stored in a container label. I think the labels contain enough information to reconstruct the command used to start the stack, I have never understood why compose makes you reference all the files for every command when the information needed is attached to every container in the stack. Also consider that you can add your own custom labels to containers (for dockerman containers as well) which can aid in identifying containers that need to be referenced in scripts.

They were meant to be, thats why everything was originally stored projects directory. The problem was people kept wanting to use more complex compose stacks than the plugin was designed to handle. Things like git controlling their compose file, adding in additional files or a build directory, pulling a pre-existing stack from github, and hand editing files in the directory. The indirect option was added to allow things like that while keeping people from messing with the project folder and the files which the plugin creates and expects to manage itself.

What you may have missed is that the plugin has an option that allows the user to store the stack files in a directory other than the default projects directory. In that case the override and env files are not stored in the same directory as the main compose file.

You are correct the restart:always option is for compose while the compose plugin only acts based on the value in the "autostart" file. The autostart file is updated based on the state of the autostart toggle for the stack on the compose page. To determine if the compose plugin is responsible for starting this stack you should enable the "Debug Logging" option in the compose plugin settings. Then next time you reboot you can look in your system log for messages from the compose plugin. It should log a message for each stack it tries to start.

Also important is that the majority of plugins, even some that provide what most consider core functionality, are not developed or maintained by Lime Technology. They are independently maintained by community developers. While the most useful and popular plugins are generally maintained by longtime, trusted members of the community, the fact that they are not directly supported or maintained by Limetech is another reason why they are not (and should not) be installed by default.

There is no such feature within this plugin. You would have to script something yourself.

The proper compose syntax for cpu set is cpuset: 10,11,12,13

For any single redundant system (including mirrors) this is always the case. While you can continue to access your data (in both mirror and parity scenarios) it is no longer protected and the next device failure results in data loss. This is not the case. In fact technically speaking (the way unraid does it) a 2 device parity protected array (1Ddata 1Parity) ends up being essentially a mirror. If your data drive dies you are able to continue to access your data off the emulated device calculated from the parity drive.

I dont plan on implementing this sorry. Display and control of individual containers (or groups of them) is beyond the scope of this plugin. While I accepted the code for making a compose tab on the menu bar (because it was kindly provided to me by another developer) my opinion remains that the Compose plugin belongs under the Docker tab as an addition to Dockerman functionality not a standalone.

This is not an issue of the compose plugin. Icon handling is a function of the built in Dockerman subsystem. All the compose plugin does is pass the text you enter along to Dockerman via a container label.

Maybe, maybe not. The compose plugin is not super well coded if I do say so myself. A design expectation is that the compose folder on the boot drive contains only those files created by the compose plugin itself. So far as what bugs might occur from extra files in that directory tree, here be dragons.

Having those extra files in the folder is likely the reason that the ui is messed up. They do not belong there. As to how they got there, have you had any trouble with flash drive corruption? If i remember correctly file names like FSCK00000 are produced by a file system check. Remove that and everything that start with ._

I do and it shouldnt. @unraid_fk34 Wait what? The compose setting page should be available via the settings menu. There is nothing available via the Tools page.

Has the "Compose Project Directory" on the compose setting page been changed?

What is "the immich compose configuration"?

Whats more the reason for this change is that 3rd party container managers (which is what this refers to rather than 3rd party containers) dont integrate with unRAIDs container status tracking thus the update status was virtually always wrong.

Probably yes. What kind of network is br0.10 Based on the above it looks like you are trying to make Spoolman available with a dedicated IP address rather than via the host IP. If that is the intent then you can just remove the port mapping from the template and Spoolman should be accessible via port 8000 at its IP address. The port mapping function maps a container port to a port on the host system for which there can only ever be one mapping per external port. Giving a container its own IP address exposes the container directly to the network making all its ports accessible without need for mapping.

I dont think this is a good idea. Everything i have read suggests that using swap on ZFS is a bad idea (even if technically possible). The article you linked doesnt mention zfs at all. I have no idea if it would actually work around whatever issues there are with swap on zfs.

Yes this is a limitation of the BTRFS file system so far as i know. No way around it that i am aware of. I did this for a long time, one word of warning you want to use a very low swappiness values (maybe 0) to ensure swap is used only when absolutely necessary. The performance of USB flash drives tends to be terrible. I stopped using them for this purpose because i found that my system ground to a near halt when things started swapping out.

Yeah i see that now. I saw gravity sync mentioned in the reply I my mind just went "Must mention the alternative" lol .

I second the idea of using LXC. That is what i use myself for pihole with keepalived. I also recommend looking into Orbital Sync rather than gravity sync.

No it is not. It is how the OS was designed to be used. And unRAID is not the only one to ever do it, look at Vanilla OS 2. The concept of an immutable base system where all additions are containerized is a growing paradigm. Admittedly Docker is maybe not the best suited containerization system for such a paradigm, but when unRAID started moving this way in v6 it was the only game in town. Alternatively you might find LXC (via the LXC) plugin more to you liking. There you can create persistent OS containers (with whatever distro suits you) and configure them to your liking. Bind mount in whatever directories you want (or the whole array) and your good to go.

This thread is for discussing issues with the compose plugin (the ui interface) not specific compose stacks or the intricacies of compose itself. The fact of the matter is I am not a docker compose guru. The only thing i notice about your compose file right off the bat is that it doesnt defined any networks, nor connect any to the containers.