benoit74

It has been decided that zim-request must contain only new requests, so this indeed has to transferred to mwoffliner repo

@JayaSaiVinay Unfortunately, we do not have the bandwidth to assist all new comers in setting up their environment. Did you followed all instructions in README.md?

First analysis above is wrong. Error is not raised by sisyphus but by mwoffliner2 or mwoffliner1 requests. sisyphus request happens few secs later and is ok. mwoffliner2: ``` 2023-11-17T07:42:38.346035918Z stderr...

There is probably no preventing tasks because mwoffliner1 and mwoffliner2 are running tasks from both systems (farm.openzim.org and farm.youzim.it) and they are full of task from the other instance (here...

On this occurrence, it looks like `michaelblob` worker suddenly stopped to communicate with the Zimfarm around 2023-12-04T20:43:29, most probably while it was building the `maxi` ZIM. Last messages of `michaelblob`...

@Popolechien did you experienced the issue on another task or could you confirm that other tasks have succeeded to create the maxi ZIM? (looks like many have from my PoV,...

Without more info, let's close it for now

I don't known whether this is a zimfarm or a scrapper or a wikimedia server issue. Only two days ago, we have this task: https://farm.openzim.org/pipeline/c566920b-5a01-4aab-a2c5-2ea0a3339733, on the same worker mwoffliner3,...

NOTA: maybe this is one more proof that we need to spend some time to centralize workers logs in Grafana as well (at least for the ones which are "under...

I can now confirm this is "kinda" a Zimfarm issue. The `node` process of this task is not consuming anymore CPU, only 887M RAM, and it is impossible to `strace`...