You should always setup logrotate. Yes the good old Linux logrotate...
this post was submitted on 23 Feb 2025
37 points (87.8% liked)
Selfhosted
42815 readers
1356 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
I don't disagree that logrotate is a sensible answer here, but making that the responsibility of the user is silly.
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.
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.
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.
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.
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.
Imho it’s because docker does away with (abstracts?) many years of sane system administration principles (like managing logfile rotations) that you are used to when you deploy bare metal on a Debian box. It’s a brave new world.
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.
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.
Everything I hear about Nextcloud scares me away from messing with it.
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.
If you only use it for files, the only thing it's good for imho. it's awesome! :)
101 of log files
is to configure it yourself
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.
Feels like blaming others for not paying attention.
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.
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 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.
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!!
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