Log directory growing to untenable sizes
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:
-
DANDI_LOG_LEVELdoesn't seem to work from the CLI. It's honored when you use dandi as a library (it's read here indandi/__init__.py), butmain()indandi/cli/command.pycalls 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 -
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-levelyou 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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dandi/dandi-cli
-
pynwb metadata: get neurodata typesForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
`metadata.nwb.get_metadata()` validates the whole BIDS dataset for every NWB file, then discards the resultForse già presa @CodyCBakerPhD l’ha presa 8 giorni fa. ApertaBIDS performance
dandi/dandi-cli#1962 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
BIDS bug
Difficoltà 3/5 Mezza giornata Idoneità per principianti 45/100
dandi/dandi-cli#1961 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
dandi/dandi-cli#1920 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 64/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dandi/dandi-cli
Issue simili
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
yunaremaia/proto-drift#22 ·
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
yunaremaia/memwatch#96 ·
-
bug good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 91/100
yunaremaia/ci-gate-watch#34 ·
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
yunaremaia/agent-capability-attestation#64 ·
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
yunaremaia/agent-call-graph#43 ·
I maintainer di solito rispondono entro 1 giorno