Closed melyux closed 6 months ago
melyux
commented
11 months ago Interesting point is that simply restarting the container doesn't work. If you restart the container, you're hit with the exact same problem. I have to stop the container, do docker compose rm -f archivebox, and then bring it back up. Not sure what this indicates...
msalmasi
commented
11 months ago Hi @melyux . I ran into the same issue. Are you running on the dev branch of ArchiveBox?
I was able to "fix" this by:
1) Restarting dbus manually:
sudo docker exec -u root -it archivebox service dbus start
2) Removing a "SingletonLock" lock file that had been generated in my Chrome profile folder. The fact this lock file exists is why even restarting the container didn't work for me.
I'm not sure if the 2 issues are related or if I was just experiencing two simultaneous issues. It does appear that either way there is some instability in the dbus service on the ArchiveBox dev branch if we are both experiencing the same issue. This might be caused by the profile lock or causing the profile lock file to not be deleted as it should be. Not sure what exactly is causing this.
melyux
commented
11 months ago @msalmasi Yes, also on the dev branch. Great find. Seems like the singleton file thing for sure, but you say restarting dbus also temporarily fixes it even if that singleton file is present?
melyux
commented
11 months ago @msalmasi I have been experimenting with the latest version of singlefile (manually calling "npm install -g single-file-cli" inside the container and setting SINGLEFILE_BINARY=/usr/bin/single-file for the Docker variable). I haven't heavily tested it like I was doing with the old version, but haven't gotten any failures since then. Can you give it a try and see if it works?
msalmasi
commented
11 months ago @melyux This seems to have fixed or at least improved the problem. I have not experienced the issue since updating to the latest version of singlefile, but I have not extensively tested yet.
Update: I must have jinxed it. Just failed on the last page I tried to grab: (https://www.nytimes.com/2022/07/19/dining/oklahoma-onion-burger-recipe.html)
melyux
commented
11 months ago Mine also failed now after hanging on a screenshot. @msalmasi Do you know the exact path to the SingletonLock file?
msalmasi
commented
11 months ago @melyux The path for me is /config/.config/chromium/SingletonLock
melyux
commented
11 months ago I couldn't find a config folder in the Docker container, /config didn't exist. No SingletonLock to be found either, but was still failing until container was removed and re-upped. I wonder what's going on
msalmasi
commented
11 months ago It should just be in your Chrome user data folder. If you haven't specifically mounted this into your docker container then it might be in your /data folder.
pirate
commented
6 months ago I'm going to close this as stale for now, as there are many changes and improvements made to Chrome in Docker ArchiveBox since the release OP is referring to (e.g. we now use a different Chrome install method managed by Playwright instead of by Apt).
If anyone is still experiencing issues running Chrome on >=0.7.1 please open a new issue with a screenshot of the error and the full output of docker compose run archivebox version. Thanks!
Describe the bug
After running for a while and/or snapshotting a certain amount of URLs, the Chromium call that does screenshots and DOM starts failing. When I exec into the container and run the
chromiumcommand again manually, it always works. But when doing "Pull" from the web UI, it always fails. It only starts working again if I stop the container,docker rmit, and then start it again.It's impossible from the log to see the exact Chromium error when this happens, because every single Chromium call is always prefixed by these error lines (and the ArchiveBox log only shows the first 5 lines):
Despite these lines, the Screenshot and DOM still work manually. But they're preventing me from seeing what's going on when Chromium does fail to produce the Screenshot and DOM during the original run.
Steps to reproduce
Screenshots or log output
When re-running "Pull" on the failed snapshots, it always fails again and produces this output:
ArchiveBox version