Background process to archive link times out

[ssoriche]

I recently discovered that using the docker image, supervisord has changed and the included supervisord.conf includes user=root which fails to de-escalate privileges and stops processing any further commands. I have a little more work to figure things out completely there, the jobs stdout isn't being sent to stdout for some reason, when/if I get it figured out I'll open a new ticket or a PR. However it is running and now every background process is failing on timing out (and I get rate limited by GitHub).

I've tried issuing the single-file commands stand alone, and it appears the issue is being caused by the --browser-arg="--load-extension=uBlock0.chromium". If I remove the parameter, the archive succeeds. My thinking was that something with the extension is blocking the browser from processing.

I found this issue gildas-lormeau/single-file-cli#83 that says the frame issue is fixed in 2.0.33, so I tried installing that, and it fails with:

/tmp/node_modules/single-file-cli/single-file --browser-arg="--headless=new" --browser-arg="--user-data-dir=/etc/linkding/chromium-profile" --browser-arg="--load-extension=uBlock0.chromium" https://google.com /etc/linkding/data/assets/test.html.gz
fetch failed [2024-09-28T01:06:34.771Z] URL: https://google.com

I've reached the end of my debugging abilities with chromium and single-file.

[sissbruecker]

uBlock uses an extension model that has been deprecated for some time in Chrome and was scheduled to be removed soon. Maybe that time has come, in that the latest Chromium version installed in the Docker image doesn't support the extension anymore? Would be good to have some logs from the browser itself, though single-file might swallow those.

Also interesting that you are the first one to report this. Are you using the alpine based Docker images? Those might use a newer Chromium version than the Debian based ones.

Apart from that I'm not sure what you are referring to regarding supervisor, I don't think there has been any change to that since introducing the HTML snapshot feature.

[sissbruecker]

Looks like only the latest-plus-alpine is affected. That one now uses Chromium 128, which seems to include some changes that might cause the extension not to load properly. I guess as a quick fix I'll remove uBlock, and then later see if I can integrate uBlock lite as a replacement.

[ssoriche]

supervisord in the alpine image is at version 4.2.5, in 3.3.4 they changed the warning for Can't drop user privileges to an error, as such supervisord no longer starts with the setting user=root in the configuration file as per Supervisor/supervisor#1218 when the container process runs as the www-data user.

I am using the alpine image and I too found it interesting that I'm the only one reporting this problem. I could try the debian image and see if that makes a difference, but it sounds like you've already found the issue.

[sissbruecker]

Mhh, supervisor seemed to work fine when I tested the alpine image. The container should actually run as root, it's only the uwsgi and supervisor background task that run as www-data. Did you configure your Docker container to run as www-data instead?

[ssoriche]

Yeah, I am running as www-data, a friend gave me their deployment manifest and it had a comment about using the www-data user with a link to #660 so that's the way I left it.

[sissbruecker]

OK, sounds like that will not work for now. I'm not sure why I configured supervisor to run as root. Maybe that part can be removed.

[ssoriche]

Thank you for taking care of this so quickly. I'm waiting on a new image push to test it out.