Closed winniethepoohbear closed 1 year ago
jdholtz
commented
1 year ago Thanks for reporting this. The docker container is working for me, so this may be a bit hard to debug from my side.
What OS are you running? Also, if you use the Docker image for v6.1 (I'm not very familiar with podman, but I'm guessing it works with docker images), do you get the same issue?
winniethepoohbear
commented
1 year ago This is on Fedora CoreOS as host. Right, podman is intended to work with Dockerfiles in a rootless enviornment. It has successfully worked with this project in the past.
jdholtz
commented
1 year ago I just used podman (built the image and pulled it) and did not run into any issues. If you try v5.1, does the container work fine (just in case something changed very recently with your environment)? Also, if you pull the image instead of building it -- podman pull docker://jdholtz/auto-southwest-check-in, do you get the same issue?
winniethepoohbear
commented
1 year ago Pulling your latest 6.1 image jdholtz/auto-southwest-check-in does work in the same environment. Building it myself and the same run command doesn't work. Here is the build command I'm using podman build --no-cache -f Dockerfile . -t auto-southwest-check-in
A prior image built from 5.1 did work at least getting to pulling up the reservation and scheduling check in.
jdholtz
commented
1 year ago That's strange that the latest image works, but not building it yourself -- the container works for me using the same build command. Is there a reason for not using the official image and instead building it yourself? It still is an issue, but I'm just interested in the use case.
winniethepoohbear
commented
1 year ago I think I started building it in the past when there was a fix but not a new official image available yet. I'd still like to understand why for the reproducibility aspect.
Is there additional debug I can look at considering the last log is this?:
2023-10-02 06:45:43 DEBUG Process-1[webdriver:124]: Starting webdriver for current session
jdholtz
commented
1 year ago Is there additional debug I can look at considering the last log is this?:
That is when the webdriver is initialized, so one thing you can do is actually manually see if the webdriver can start by execing into the container. Here are the steps to do that:
podman run -d --entrypoint sleep localhost/auto-southwest-check-in:latest infinity to make the container sleep infinitely instead of running the scriptpodman exec -it <container name> shpythonfrom seleniumbase import Driver
driver = Driver(headless=True, uc_cdp_events=True, undetectable=True)
driver.get("https://mobile.southwest.com/check-in")According to the logs, it should pause at the second line, so if it does, you can wait for it to timeout and see what the issue is. Let me know if all Python commands run without error though.
jdholtz
commented
1 year ago @winniethepoohbear also, could you attach a file of the podman build output? That may help me compare it with my output and detect a potential issue.
jdholtz
commented
1 year ago Hey @winniethepoohbear, do you have any updates regarding my comments above?
winniethepoohbear
commented
1 year ago Running python in the container image it hangs here and never returns:
driver = Driver(headless=True, uc_cdp_events=True, undetectable=True) . Even without parameters or webdriver from selenium directly shows the same hang.
Here is the build output:
jdholtz
commented
1 year ago Very strange. Maybe there’s a difference in the network configuration? I don’t really know any further approaches to this problem since I’m not able to reproduce it and the published Docker image works on Podman.
winniethepoohbear
commented
1 year ago I found some stackoverflow posts that said this might be the behavior when the chromedriver version isn't compatible.
Comparing the chromedriver versions shows the sget command from the build pulls the legacy version (112), while your published version seems to have the latest version (117).
Output from build:
STEP 6/8: RUN sbase get chromedriver
*** chromedriver to download = 112.0.5615.49 (Legacy Version)Your published container:
>>> driver.capabilities['browserVersion']
'117.0.5938.62'Specifying latest by changing the Dockerfile command to be sbase get chromedriver latest worked.
jdholtz
commented
1 year ago Looking through your build logs, this seems to be why its downloading the legacy version: (143/146) Installing chromium (112.0.5615.165-r0).
Here, it appears your apk database is out of date as I have 3.18:
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gzDo you have the latest Python 3.11 Alpine image? Maybe that image is really old (from a previous build) and it was just never upgraded which would explain downloading v112 of Chromedriver.
winniethepoohbear
commented
1 year ago Yes, you're right. The python base image was ~6 months old. Updating the base image also implicitly fixes the issue.
jdholtz
commented
1 year ago Good to hear. I wanted to have SeleniumBase download the driver matching the browser version, otherwise unexpected issues could occur (being detected by Southwest, the webdriver not starting, etc.). Therefore, I don’t want to add latest.
Now that it works and we know what the issue is (out of date Python Alpine image), can this issue be closed?
I recommend using the --pull flag when building the image as that will always pull any base images (which would mean this issue won’t occur again).
Version
6.1
Description
Container doesn't start check-in. No console output unless running --verbose.
To Reproduce
Expected Behavior
No response
Relevant logs and program output
Additional context
Building from 6.1 running with podman. The same environment has worked before changing to 6.x,