未知错误:由于未知错误的页面崩溃而删除会话
我正在使用使用Python和Selenium的机构。我每个cron启动脚本,并不时崩溃。因此,它确实不规则,有时会很好地贯穿。我也已经在github repo上发布了,但没有在那里得到答案,所以我现在在这里询问有人知道为什么。
这是一台数字海洋Ubuntu服务器,我在无头模式下使用它。驱动程序版本在日志上可见。这是错误消息:
ERROR [2018-12-10 09:53:54] [user] Error occurred while deleting cookies from web browser!
b'Message: invalid session id\n (Driver info: chromedriver=2.44.609551 (5d576e9a44fe4c5b6a07e568f1ebc753f1214634),platform=Linux 4.15.0-42-generic x86_64)\n'
Traceback (most recent call last):
File "/root/InstaPy/instapy/util.py", line 1410, in smart_run
yield
File "./my_config.py", line 43, in <module>
session.follow_user_followers(['xxxx','xxxx','xxxx','xxxx'], amount=100, randomize=True, interact=True)
File "/root/InstaPy/instapy/instapy.py", line 2907, in follow_user_followers
self.logfolder)
File "/root/InstaPy/instapy/unfollow_util.py", line 883, in get_given_user_followers
channel, jumps, logger, logfolder)
File "/root/InstaPy/instapy/unfollow_util.py", line 722, in get_users_through_dialog
person_list = dialog_username_extractor(buttons)
File "/root/InstaPy/instapy/unfollow_util.py", line 747, in dialog_username_extractor
person_list.append(person.find_element_by_xpath("../../../*")
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webelement.py", line 351, in find_element_by_xpath
return self.find_element(by=By.XPATH, value=xpath)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webelement.py", line 659, in find_element
{"using": by, "value": value})['value']
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webelement.py", line 633, in _execute
return self._parent.execute(command, params)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute
self.error_handler.check_response(response)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: unknown error: session deleted because of page crash
from unknown error: cannot determine loading status
from tab crashed
(Session info: headless chrome=70.0.3538.110)
(Driver info: chromedriver=2.44.609551 (5d576e9a44fe4c5b6a07e568f1ebc753f1214634),platform=Linux 4.15.0-42-generic x86_64)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/root/InstaPy/instapy/instapy.py", line 3845, in end
self.browser.delete_all_cookies()
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 878, in delete_all_cookies
self.execute(Command.DELETE_ALL_COOKIES)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute
self.error_handler.check_response(response)
File "/usr/local/lib/python3.6/dist-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: chrome not reachable
(Session info: headless chrome=71.0.3578.80)
(Driver info: chromedriver=2.44.609551 (5d576e9a44fe4c5b6a07e568f1ebc753f1214634),platform=Linux 4.15.0-42-generic x86_64)
任何了解原因是什么以及如何解决?
感谢您的输入。来自 http://treestones.ch/ 帮助了我。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
尽管您将错误视为:
主要例外是:
您的代码试验会给我们一些线索。
解决方案
有多种解决方案。但是,按照 unknownerror:session已删除,因为tab崩溃了,session已删除此问题可以可以通过以下任何一个解决方案来解决:
添加以下
chrome_options
:Chrome似乎由于太小
/dev>/dev/dev/shm
而在某些页面上的Docker容器中崩溃。因此,您可能必须修复小型/dev/shm
size。一个示例:
如果您使用
-v/dev/shm:/dev/shm
共享主机 </dev/shm,
使它起作用的另一种方法是添加
chrome_options
作为- disable-dev-shm-usage
。这将迫使Chrome改用
/TMP
目录。尽管将使用磁盘而不是内存。,这可能会减慢执行速度。
从标签中,
从Tab崩溃 是WIP(正在进行中的工作)与 Chromium Team 现在相当长一段时间,与 linux有关尝试始终将/dev/shm用于不执行的内存。以下是参考文献:
参考,
您可以在以下方面找到一些相关的讨论:
Though you see the error as:
The main exception is:
Your code trials would have given us some clues what going wrong.
Solution
There are diverse solution to this issue. However as per UnknownError: session deleted because of page crash from tab crashed this issue can be solved by either of the following solutions:
Add the following
chrome_options
:Chrome seem to crash in Docker containers on certain pages due to too small
/dev/shm
. So you may have to fix the small/dev/shm
size.An example:
It also works if you use
-v /dev/shm:/dev/shm
option to share host/dev/shm
Another way to make it work would be to add the
chrome_options
as--disable-dev-shm-usage
. This will force Chrome to use the/tmp
directory instead. This may slow down the execution though since disk will be used instead of memory.from tab crashed
from tab crashed was WIP(Work In Progress) with the Chromium Team for quite some time now which relates to Linux attempting to always use /dev/shm for non-executable memory. Here are the references :
Reference
You can find a couple of relevant discussions in:
如果有人在Docker容器中面对这个问题:
在创建容器并且错误消失时,请使用标志
-SHM-SIZE = 2G
。此标志使容器用于使用主机的共享内存。
示例
来源: https://github.com/seleniumhq/docker-selenium
In case someone is facing this problem with docker containers:
use the flag
--shm-size=2g
when creating the container and the error is gone.This flag make the container to use the host's shared memory.
Example
Source: https://github.com/SeleniumHQ/docker-selenium
我在Ubuntu服务器上遇到以下错误:
事实证明,该错误的原因是服务器上的磁盘空间不足,解决方案是扩展了我的磁盘空间。您可以检查这个问题有关更多信息。
I was getting the following error on my Ubuntu server:
It turned out the the cause of the error was insufficient disk space on the server and the solution was to extend my disk space. You can check this question for more information.
上面的答案解决了我的问题,但是由于我需要从docker-compose.ml运行
它
。
The answers above solved my issue, but since i needed to run it from a docker-compose.yml i used this configuration which calls my regular unchanged DockerFile
docker-compose.yml
DockerFile (selenium on Ubuntu -WSL-)
我们在2024年1月30日发行版本上也遇到了同样的问题: 121.0.6167.139
这是一个镀铬错误。
降级到以前的版本:
120.0.6099.224 ,然后重新开始工作。
将其报告给Google。有关更多信息,在这里检查。
Google拒绝了它。该错误仍然出现在更高版本中...
We had the same issue with the 30th January 2024 release version: 121.0.6167.139
It's a chrome bug.
Downgraded to the previous version:
120.0.6099.224 and started working again.
Reported it to Google. For more info check here.
Google rejected it. The bug still appears in higher versions...
我们需要分开指定SHM内存,-shm-size = 2G
如果是Docker,
使用以下配置 - 对我的
服务效果很好:
铬合金:
图片:硒/节点 - 鲜石:4.0.0-rc-1-prerease-20210823
SHM_SIZE:2GB
We need to specify the shm memory separatly, --shm-size=2g
In case of docker,
use the following config - this working fine for me
services:
chrome:
image: selenium/node-chrome:4.0.0-rc-1-prerelease-20210823
shm_size: 2gb
在我试图打开一个新的网页时,这发生在我身上,以相同的驱动程序在
chromium
中。它在我的本地计算机中正常工作,在那里我使用chrome
。没有工作:
以下是解决方案,我正在使用的是对我有用的。 IE重新定位
驱动程序
This happened to me while trying to open a new web page with the same driver in
Chromium
. It worked fine in my local machine where I useChrome
.Did not worked:
Below is the solution, I am using which is working for me. i.e re-initializing
the driver
我不确定这是否是唯一可能的原因和解决方案,但是在对我时不时遇到的此错误的彻底调查之后,我发现了以下证据:
sudo docker logs&lt; container-id&gt;
)我发现许多错误读数:[recary]:bind(bind())失败:无法分配请求的地址(99 )
。从我阅读的内容来看,此错误通常意味着没有可用端口。sudo docker exec -it bash
,然后ps aux
),我发现了300多个实例 chrome -driver 进程(您可以使用ps aux | grep驱动程序| wc -l </code>对它们进行
计数创建一个
chromedriver
的实例,并在调用driver.quit()
(我在C#中工作,而不是Python)时终止。因此,我得出的结论是,某些测试未调用drive.quit()
。在我的情况
下,我发现,即使我们打电话给
驱动程序。在该行之前,更多代码可能会引发和例外。当这些前几行之一抛出例外时,未达到调用
driver.quit()
的行,因此,随着时间的流逝,我们正在“泄漏” Chrome-Driver Processes在硒网格节点上。这些孤儿过程导致了可用端口的资源泄漏(也可能还导致内存),这也导致浏览器的页面崩溃。给出以上结论的解决方案
,解决方案非常直接。我们必须在
driver.quit()
中包装try/fin/fine the
中的代码,然后将调用打到driver.quit()
在最终
条款中,如下:I'm not sure whether this is the only possible cause and solution, but after thorough investigation of this error which I encountered every now and then, I found the following evidences:
sudo docker logs <container-id>
) I found many errors reading:[SEVERE]: bind() failed: Cannot assign requested address (99)
. From what I read, this error usually means that there are no available ports.sudo docker exec -it bash
and thenps aux
), I found more than 300 instances of chrome-driver processes (you can count them usingps aux|grep driver|wc -l
)When running locally, I know that the chrome-driver process is normally invoked when you create an instance of
ChromeDriver
and is terminated when you calldriver.Quit()
(I work in C#, not Python). Therefore I concluded that some tests don't calldrive.Quit()
.The conclusion
In my case, I found that even though we had a call to
driver.Quit()
in the[TearDown]
method (we use NUnit), we had some more code before that line, that could throw and exception. When one of these preceding lines threw an exception, the line that callsdriver.Quit()
is not reached, and therefore over time we were "leaking" chrome-driver processes on the Selenium Grid nodes. These orphan processes caused a resource leak of available ports (and probably also memory), which also caused the browser's page to crash.The solution
Given the above conclusion, the solution was pretty straight forward. We had to wrap the code that precedes
driver.Quit()
in atry/finally
, and put the call todriver.Quit()
in thefinally
clause, like this:发生此错误是因为没有足够的等待时间来加载网页
(错误消息说会话被删除是因为网页崩溃了。还有另一个问题,它无法弄清楚该页面是否正在加载。我发现,主要问题的等待时间不足以使网页加载。 )
This error occurred because there was not enough waiting time for web pages to load
(The error message says the session got deleted because a webpage crashed. There's another problem where it can't figure out if the page is loading or not. After looking into it, I found out that the main issue was not waiting long enough for web pages to load. I figured this out by checking the errors, doing some tests, and reading about how sessions and crashes work in headless Chrome, version 95.0.4638.69.)
在我的情况下,
sandbox
和shm
设置没有帮助,因此我最终会定期关闭当前选项卡并切换到新的选项卡,例如:In my case
sandbox
andshm
settings did not help, so what I ended up is periodically closing current tab and switching to new one, like so:我遇到了同样的问题,我检查了脚本中的哪个日志,而我添加了一些等待,即固定的。
I was having the same problem, I checked the log at which point in my script the bug happened and I added some wait, ie,
time.sleep(2)
just before the bug, and my problem was fixed.