Page MenuHomePhabricator

The spacemedia tool keeps crashing and filling kubernetes nodes
Closed, ResolvedPublic


The spacemedia tool seems to regularly (weekly?) hits some URL that it cannot reach and starts crashing. This fills the disk with docker logs on the host that it is running on.

So first, I wanted to let you know that it is crashing regularly (since those logs are likely never reaching you), and second, can you send error logs to the tools NFS homedir on /data/project/spacemedia? I'm taking the action item to tighten up log rotation to prevent this from crashing cluster nodes.


Event Timeline

Bstorm triaged this task as High priority.Nov 4 2019, 3:20 PM
Bstorm created this task.
org.jsoup.HttpStatusException: HTTP error fetching URL
        at org.jsoup.helper.HttpConnection$Response.execute( ~[jsoup-1.12.1.jar!/:na]
        at org.jsoup.helper.HttpConnection$Response.execute( ~[jsoup-1.12.1.jar!/:na]
        at org.jsoup.helper.HttpConnection.execute( ~[jsoup-1.12.1.jar!/:na]
        at org.jsoup.helper.HttpConnection.get( ~[jsoup-1.12.1.jar!/:na]
        at org.wikimedia.commons.donvip.spacemedia.service.agencies.EsaService.updateMedia( ~[classes!/:0.0.1-SNAPSHOT]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_232]
        at sun.reflect.NativeMethodAccessorImpl.invoke( ~[na:1.8.0_232]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke( ~[na:1.8.0_232]
        at java.lang.reflect.Method.invoke( ~[na:1.8.0_232]
        at [spring-context-5.1.9.RELEASE.jar!/:5.1.9.RELEASE]
        at [spring-context-5.1.9.RELEASE.jar!/:5.1.9.RELEASE]
        at java.util.concurrent.Executors$ [na:1.8.0_232]
        at java.util.concurrent.FutureTask.runAndReset( [na:1.8.0_232]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301( [na:1.8.0_232]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ [na:1.8.0_232]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [na:1.8.0_232]
        at java.util.concurrent.ThreadPoolExecutor$ [na:1.8.0_232]
        at [na:1.8.0_232]

That's a sample of the crashes. That just loops indefinitely in the logs until the disk fills once it is going badly. It seems that functional logs are also going to STDOUT, which is best practice in docker, but, in this environment, you won't be able to see the logs unless they go to disk.

in this environment, you won't be able to see the logs unless they go to disk.

It is possible to use kubectl logs <pod_name> to see the stdout data from a pod, but this data is not persisted across pod restarts.

I think our best bet is to set the max-size and max-file options for the json-file logging driver (our version is so old that you can't find this on the official website)

@Phamhi: That's docker, not kubernetes. Users cannot do that directly.

Change 548304 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/puppet@production] toolforge-k8s: rotate docker logs

Change 548304 merged by Bstorm:
[operations/puppet@production] toolforge-k8s: rotate docker logs

@Bstorm thanks a lot for your bug report! Indeed I have no automatic error report system (yet) allowing me to detect the issue without connecting to the server and checking log files directly, which I didn't do last month.
ESA changed its website recently (I wasn't aware) and it triggers an unexpected bug, causing an infinite loop. I fixed this.
The /data/project/spacemedia/logs folder contained 140Mb of compressed logs. I was not aware Spring Boot 2.1 default logging configuration was to keep indefinitely previous logs. I upgraded to version 2.2, it should now keep only 7 days of logs.
The application was also logging both on standard output and log files. I changed this behaviour to log only to log files when deployed on toolforge. Can you please confirm it works?

What remains for me is to update the ESA parsing code with the new website HTML layout (still no API in sight).

It's still crashing but because memory settings have been lowered, see

Fixed by requesting more memory in the startup script.