Where stored 500 Server errors in logs inside azurite?

[Slach]

I executed
docker.io/clickhousepro/azurite:latest docker compose service

services:
  azure:
    image: mcr.microsoft.com/azure-storage/azurite:latest
    hostname: devstoreaccount1.blob.azure
    healthcheck:
      test: nc 127.0.0.1 10000 -z
      interval: 1s
      retries: 30
    command: [ "azurite", "--debug", "/data/debug.log" , "-l", "/data", "--blobHost", "0.0.0.0" ]
    volumes:
      - azure:/data

in my e2e scenarios I got following error

 2024.08.27 14:55:48.560507 [ 1021 ] {ceb8fa3f-acf5-4c6d-9350-9a645a8cf67b} <Debug>
WriteBufferFromAzureBlobStorage: 
Write at attempt 2 for blob `ufuxgidvjcxyvcgxbrjtymmlizzlxuvu` failed: 500 Internal Server Error

I tried docker compose exec azure cat /data/debug.log
but I don't see any error message related to the selected time range and related to ufuxgidvjcxyvcgxbrjtymmlizzlxuvu

in the stderr/stdout of azure container i see

2024.08.27 14:55:48.560507Z azure-1  | 172.18.0.10 - - [27/Aug/2024:14:55:48 +0000] 
"PUT /devstoreaccount1/azure-disk/ufuxgidvjcxyvcgxbrjtymmlizzlxuvu?blockid=uiilnxjafsvefxyzmatgccnosxbawmllkmkfgsdbvjqhiznfeegbforpccciwsrd&comp=block HTTP/1.1" 
500 - 2024

How to debug this kind of error?

[Slach]

@blueww any suggestion?

why error details doesn't store in debug.log?

in stdout/strerr of container i see

[27/Aug/2024:18:07:15 +0000] 
"PUT /devstoreaccount1/azure-disk/awznqgydxphyvfxxmsmdseycxrmegxjf?blockid=xtraofwopvfkhuqshalqqftszdotexfddnnnhzummzydpkploaysgxxmviibdelh&comp=block HTTP/1.1" 500 -

but ls -la /data/debug.log return
-rw-r--r-- 1 root root 58433536 Aug 27 18:05 /data/debug.log

[blueww]

@Slach

Following is my docker-compose.yml file.
The most difference are:

1. the "command" are different
2. my file mapping the port "10000:10000" , then Azurite can be access from other storage client on same machine outside docker image
3. I map the local folder "C:\temp\azurite" to "/data" in docker, and save debug log in "/data/debug.log", so the debug log can be accessed on local machine in path "C:\temp\azurite\debug.log".
4. I removed "healthcheck" and "hostname" section in the file, you can add back per your requirement.

services:
  azuretablestorage:
    image: mcr.microsoft.com/azure-storage/azurite:latest
    restart: always
    command: "azurite --debug /data/debug.log -l /data --blobHost 0.0.0.0"
    volumes:
      - C:\temp\azurite\:/data
    ports:
      - "10000:10000"
      ```

[Slach]

@blueww

This is absolutely the same docker-compose with main, with the same behavior

you just replaced the same command in a different format
and replaced docker named volume into explicitly local directory binding

container was not restarted, so removing healthcheck is doesn't required

root question
why debug.log is not flushed more than 2 minutes!

Even if I execute sync -f inside container ;(

last stdout/stderr logs in azurite container is

 172.18.0.10 - - [28/Aug/2024:08:10:23 +0000] 
"PUT /devstoreaccount1/azure-disk/tpcowcnljflumystuanbqbbteuzxvpts?
blockid=ucfmwirwgqozcznqeshrdzutzazgktufjokngnbuvadxgapmyrletnbrnjhdleem&comp=block HTTP/1.1" 500 -

but even after
docker compose exec azure sync -f

docker compose exec azure ls -la /data/debug.log
shows following

-rw-r--r--    1 root     root      58372096 Aug 28 08:05 /data/debug.log

Why logs is not flushed more than 2 minutes?
Latest lines in log doesn't show any errors

docker compose exec azure tail -n 1 /data/debug.log

2024-08-28T08:05:23.642Z b16f1d0d-e21d-48fb-ac15-834a461050e4 info: EndMiddleware: End response. TotalTimeInMS=2 StatusCode=200 StatusMessage=OK Headers={"server":"Azurite-Blob/3.32.0","last-modified":"Wed, 28 Aug 2024 08:01:24 GMT","x-ms-creation-time":"Wed, 28 Aug 2024 08:01:24 GMT","content-length":"8","content-type":"application/octet-stream","etag":"\"0x20F7732749BD060\"","content-md5":"acF1O9X4FQHZUTLQivBEZA==","content-encoding":"","cache-control":"","

it doesn't look like complete flushed string ," at the end

[blueww]

@Slach

In my testing, the debug log file on my local machine can be flushed very fast after I send a request to Azurite, in 1-2 seconds.

So the limitation looks be on your test environment, or on docker.
We are not docker expert, so might not be the best person to see why the file in mapped volume is not flushed. Could you contact docker team to see if any idea?
Or does this repro on other machines on your side?

[Slach]

you are right
root reason was named volume which have tmpfs with 60mb ram,

ok. I found solution "--debug", "/dev/stderr"

thank you for your patience