I think this is specific to nginx and have seen the same, (I just ignored it as it did not seem to impact other VS) - I must go back and tidy-up those .conf files.
I suspect it is a hangover from the diffs with Apache.
I’ve found that the remaining files not happen on all VM’s
I can not reproduce why those “earlier” created SubServers are not fully removed, but if I create a new Subserver now via bash-script:
That might explain that it sometimes seems to work and sometimes not.
I’ll remove some of them and will wait & see if they are fully removed afterwards.
How long does the caching may take effect? Any Idea?
BTW: Is there any change to remove multiple sub-servers of a Server at once?
This “might” be a backup of the “shadow” file typically located in “/etc” folder, though you haven’t provided a full path so this is just an assumption. It’s possible a backup is being created while the system is editing the “shadow” file. The shadow file is a system “password” file which stores data in a hashed format.
webmin/logviewer/units.cache
This looks like a cached file used for something related to Webmin.
passwd-
Like the “shadow” file, this is likely a backup of the “passwd” file used to store user data by the system.
.git/index
This looks like a file create by “git”, though again you haven’t provided a full path so it could be located anywhere for any purpose.
nginx/sites-available/z8nq3v.xlivery.shop.conf
This appears to be the Virtual Host configuration created by Nginx for a site. It’s possible that the site is simply being disabled and not deleted. Perhaps a bug, but perhaps intentional.
This appears to be the Virtual Host configuration created by Nginx for a site. It’s possible that the site is simply being disabled and not deleted. Perhaps a bug, but perhaps intentional.
It’s just the “.conf”-Files in /etc/nginx/sites-available & sites-enabled.
The other stuff are like you noticed just cache- and versioning files (which are ok to keep this stuff as it’s “history”.