Rant! 100GB Log file in Nextcloud.
-
Persistent storage should never be used for logging in docker. Nextcloud is one of the worst offenders of breaking docker conventions I've found, this is just one of the many ways they prove they don't understand docker.
Logs should simply be logged to stdout, which will be read by docker or by a logging framework. There should never be "log files" for a container, as it should be immutable, with persistent volumes only being used for configuration or application state.
-
It's because with docker you don't need to do log files. Logging should be to stdout, and you let the host, orchestration framework, or whoever is running the container so logs however they want to. The container should not be writing log files in the first place, containers should be immutable except for core application logic.
-
You should always setup logrotate. Yes the good old Linux logrotate...
-
If you only use it for files, the only thing it's good for imho. it's awesome!
-
We should each not have to configure log rotation for every individual service. That would require identify what and how it logs data in the first place, then implementing a logrotate config. Services should include a reasonable default in logrotate.d as part of their install package.
-
Ideally yes, but I've had to do this regularly for many services developed both in-house and out of house.
Solve problems, and maybe share your work if you like, I think we all appreciate it.
-
Reminds me of when my Jellyfin container kept growing its log because of something watchtower related. Think it ended up at 100GB before I noticed. Not even debug, just failed updates I think. It's been a couple of months.
-
Or you can use Podman, which integrates nicely with Systemd and also utilizes all the regular system means to deal with log files and so on.
-
The AIO container is so terrible, like, that's not how you're supposed to use Docker.
It's unclear whether OP was using that or saner community containers, might just be the AIO one. -
I don't disagree that logrotate is a sensible answer here, but making that the responsibility of the user is silly.
-
I have lost now not hours, but days debugging their terrible AIO container. Live production code stored in persistent volumes. Scattered files around the main drive in seemingly arbitrary locations. Environment variables that are consistently ignored/overrided. It's probably my number one example of worst docker containers and what not to do when designing your container.
-
Yeah, their AIO setup is just bad, the more "traditional" and community supported docker compose files work well, I've been using them for years. They're not perfect, but work well. Nextcloud is not bad per se, but just avoid their AIO docker.
-
It's too late for me now coz I didnt do my research and ive already migrated over, but good god ever loving fuck was the AIO container the hardest of all my services to set up.
Firstly, it throws a fit if you don't set up the filesystem specifically for php and the postgres db as if it were bare metal. Idk how or why every other container I use can deal with UID 568 but Nextcloud demands www-data and netdata users.
When that's done, you realise it won't run background tasks because it expects cron to be set up. You have to set a cronjob that enters the container to run the cron, all to avoid the "recommended" approach of using a second nextcloud instance just to run background tasks.
And finally, and maybe this is just a fault of TrueNAS' setup wizard but, I still had to enter the container shell to set up a bunch of basic settings like phone region. come on.
Straight up worse than installing it bare metal
-
Just use the official Docker AIO and it is very, very little trouble. It's by far the easiest way to use Nextcloud and the related services like Collabora and Talk.
-
I’ve only ever used the AIO and it’s the only one of my problem containers out of about 30. Would you mind pointing me to some decent community compose files? Thanks!!
-
Are you crazy?
I understand that we are used to dumbed down stuff, but come on...Rotating logs is in the ABC of any sysadmin, even before backups.
First, secure your ssh logins, then secure your logs, then your fail2ban then your backups...
To me, that's in the basic stuff you must always ensure.
-
Agreed, but going container route those nice basic practices are dead.
And also, being mextcloud a php service, of can't by definition ship with a logrotate config too, because its never packaged by your repo.
-
Those should also all be secure by default. What is this, Windows?
-
Just basic checks I prefer to ensure, not leave to distribution good faith. If all is set, good to go. Otherwise, fix and move on.
Specially with self hosted stuff that is a bit more custom than the usual.
-
I stopped using Nextcloud a couple of years ago after it corrupted my encrypted storage. But I'm giving it a try again because of political emergency. But we sure need a long term replacement. Written in Rust or some other sane language.
