Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Log directory growing to untenable sizes

Aperta
#1,889 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@CodyCBakerPhD ci sta già lavorando.

Dal 8/7/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

I ran into a couple of logging things that seem off, wanted to check whether they're intentional before opening a PR...

On Engaging (as a part of DANDI Compute, which does a lot of automated DANDI download/upload operations) I noticed the ~/.local/state/dandi-cli/log/ directory fills up home disk space (nearly 100 GB!!)

My first instinct is to just relax the log level to error-only events instead of filling it with every last detail of run operations

But digging into it, I noticed two things:

  1. DANDI_LOG_LEVEL doesn't seem to work from the CLI. It's honored when you use dandi as a library (it's read here in dandi/__init__.py), but main() in dandi/cli/command.py calls lgr.setLevel(logging.NOTSET) (and the same on the root logger) right after, which looks like it wipes out whatever the user sets. So the env var behaves differently depending on whether you're using the CLI or the Python API

  2. Every CLI run drops a new DEBUG log file that never gets cleaned up. main() writes a fresh timestamped file to the log dir on each invocation, and the file handler is pinned to DEBUG no matter what --log-level you pass. There's no 'cache limit' nor pruning, and no way to turn it off, so it just keeps growing and growing

So is the "always log DEBUG to file regardless of --log-level" thing strictly intentional?

I would also recommend we set limits on how much this directory can grow

Any thoughts on what a sane default retention would be, like keep the last N files, or N days?

Lingua principale
Python
Stelle
29
Fork
37
Merge medio
1g 10h
PR unite (30g)
17

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dandi/dandi-cli

Tutte le issue di dandi/dandi-cli

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.