compact: once it run out of disk space, it keeps running but is still broken

[calestyo]

Thanos, Prometheus and Golang version used:

# thanos --version
thanos, version 0.34.1 (branch: HEAD, revision: 4cf1559998bf6d8db3f9ca0fde2a00d217d4e23e)
  build user:       root@61db75277a55
  build date:       20240219-17:13:48
  go version:       go1.21.7
  platform:         linux/amd64
  tags:             netgo

Object Storage Provider: filesystem

What happened: I run several times now into the problem, that compact ran out of local disk space, e.g. with an error like:

Mar 04 05:48:59 foo thanos@compact[2138629]: ts=2024-03-04T04:48:59.919722752Z caller=compact.go:491 level=error msg="critical error detected; halting" err="compaction: group 0@2951439482451486615: compact blocks [/data/main/thanos/compact/cache/compact/0@2951439482451486615/01HNPSBZE5B3W20MPYBB1ANBC9 /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HNVY3CMAQGJ5FJVXFJ0HF8MX /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HP12S5NVRYB1HGRRZF3WGHYS /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HP67KTYPRMZ7REX5D5P7HBRH /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HPBCDE60PGQT0NVJMAZN4REY /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HPGH0QTWZG37HR1TVA3YWKHQ /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HPNNYRYMC8F7PVP67THGF7JA]: 2 errors: populate block: write chunks: preallocate: no space left on device; sync /data/main/thanos/compact/cache/compact/0@2951439482451486615/01HR3WCT1D1N7CH7Y763F13ZRQ.tmp-for-creation/chunks/000063: file already closed"

The problem is, once this happened, it seems to be in a broken state and even if disk space gets free, it doesn't try again. It doesn't exit with a failure either, so there's no real chance for a service manager like systemd to notice the problem (and e.g. send mail or so).

What you expected to happen:

There should be an option for each component (including compact), which causes it to exit immediately with some non-zero exit status in case of an error.

Cheers, Chris.

[douglascamata]

Which options did you use to start this Compactor?

[calestyo]

Options are:

/usr/bin/thanos compact --log.level=warn --wait --data-dir=/data/main/thanos/compact/cache --objstore.config-file=/etc/thanos/data-thanos.yml --consistency-delay=1h --hash-func=SHA256 --http-address=:10912 --web.external-prefix=/thanos/compact --web.route-prefix=/

But I just found --no-debug.halt-on-error which seems as if it may be causing the right behaviour.

I wonder why that isn't the default.
The description why not, is honestly not very convincing.

Yes, it would be bad to retry over and over if it just keeps failing, but there are much better ways to handle this.
a) Not retrying endlessly is anyway the service manager’s (i.e. systemd’s) responsibility, and there are plenty of proper ways in that to handle this and b) thanos could e.g. just set some flag on such error condition, that lets it fail immediately without retrying (which would still allow for the important part, namely failing - otherwise people in normal environments won't notice that anything's wrong).

[danksim]

I am seeing a similar behavior where it errors once (no space left on device), halts and never compacts again.

level=error ts=2024-03-19T16:41:39.30753731Z caller=compact.go:486 msg="critical error detected; halting" err="compaction: group 0@16225028991790494220: compact blocks [/data/compact/0@16225028991790494220/01F3EZ3ZAA58NSNX2EPRS03N5H /data/compact/0@16225028991790494220/01F3M3W8CDMFQP1ZTS72F07EGQ /data/compact/0@16225028991790494220/01F3S8RRSXCY18WNCS6NS6T1N4 /data/compact/0@16225028991790494220/01F3YDPP5RRD4FFERPTVTRY86T /data/compact/0@16225028991790494220/01F43J9M8VME00PDVN2FQ84SFH /data/compact/0@16225028991790494220/01F48Q59D5Z77DG93SGEYVZ8B1 /data/compact/0@16225028991790494220/01F4DW1XNESEQH4RBW5AZMN6P4]: 3 errors: populate block: write chunks: preallocate: no space left on device; sync /data/compact/0@16225028991790494220/01HSBRPYTTJ57GJBME0FR28SFV.tmp-for-creation/chunks/000088: file already closed; write /data/compact/0@16225028991790494220/01HSBRPYTTJ57GJBME0FR28SFV.tmp-for-creation/index: no space left on device"
level=info ts=2024-03-19T16:42:04.648266954Z caller=fetcher.go:470 component=block.BaseFetcher msg="successfully synchronized block metadata" duration=2.059553102s duration_ms=2059 cached=40630 returned=40630 partial=0
level=info ts=2024-03-19T16:42:32.306773124Z caller=fetcher.go:470 component=block.BaseFetcher msg="successfully synchronized block metadata" duration=43.087680327s duration_ms=43087 cached=40630 returned=40610 partial=0
level=info ts=2024-03-19T16:43:15.869657891Z caller=fetcher.go:470 component=block.BaseFetcher msg="successfully synchronized block metadata" duration=43.552571092s duration_ms=43552 cached=40630 returned=40610 partial=0
level=info ts=2024-03-19T16:43:15.88204689Z caller=clean.go:34 msg="started cleaning of aborted partial uploads"
level=info ts=2024-03-19T16:43:15.88207772Z caller=clean.go:61 msg="cleaning of aborted partial uploads done"
level=info ts=2024-03-19T16:43:15.882085075Z caller=blocks_cleaner.go:44 msg="started cleaning of blocks marked for deletion"
level=info ts=2024-03-19T16:43:15.882099343Z caller=blocks_cleaner.go:58 msg="cleaning of blocks marked for deletion done"

I am running the compact component with a 100gb persistent volume and after the error, it goes back to ~50% usage:

[douglascamata]

To be clear: you won't ever recover Compactor running out of disk space without giving it more disk. I agree with the suggested expected behavior from @calestyo though, the Compactor should exit when it detects it doesn't have enough disk space available.

To fix the Compactor:

• scale Compactor to zero
• expand the PVs if you can or give it bigger ones
• scle it back up.

Finally when the Compactor catches up you can follow a similar procedure to shrink the PV.

[calestyo]

you won't ever recover Compactor running out of disk space without giving it more disk.

The problem is however, even with more disk (respectively space freed) it never recovers and does anything useful again.

I think the default behaviour of daemons is to fail in such situation (so that the service manager, like systemd, can react)... a --keep-going mode might be nice for some people, but then only if it actually ever does something again (which seems not the case).

[douglascamata]

The problem is however, even with more disk (respectively space freed) it never recovers and does anything useful again.

You will need to give it more total disk space than it had before. The amount of extra space required is proportional to the time the Compactor had issues. I've seen setups where the Compactor had initially about 200 GB of disk and we had to give it 4x more.

As I said, I agree with you that the Compactor's default behavior is not ideal. We should improve it.

[calestyo]

You will need to give it more total disk space than it had before.

I don't see why that should need to be the case. The filesystem could have had some other big occupier of space and with that being gone it could be just enough for compact, even with the total size being the same.

The other issue you're referring to, that it needs more and more space, is what I've described in #7198, which is probably a duplicate of #3405.

IMO the proper behaviour would be as follows:

• Per default, if it runs out of space and cannot finish it's operation it should exit with a non-zero status
• If some extra option is given, it may continue to run and continuously retry (perhaps with some delay in between or/and only if the free space is bigger), but without any extra conditions like the filesystem having gained more total space. But that mode only makes sense if some other system would be in place that automatically increases he space or frees up space - and if there's anyway such a system, it wouldn't cost much IMO, to then just restart compact... so in a way the whole mode of continuing to run makes IMO not that much sense.