Stop the selenium server

[msgoussi]

Since Firefox version 48, Mozilla requires all add-ons to be signed. Until recently, Firefox support in Selenium was exclusively provided by an add-on. As this add-on is not currently signed, this solution does not work with the latest Firefox releases. As an alternative, Mozilla are working on a WebDriver specification compliant implementation named GeckoDriver. Please note that the specification is not complete, and that Selenium itself does not comply with the specification at this time. This means that features previously available through Selenium will not be available using GeckoDriver.

Currently we would advise against using the latest firefox/geckodriver with selenium untill the w3c webdriver specification is complete. If you wish to use firefox we would advise using an older version via a Docker image. See the RSelenium Docker vignette for more detail:

http://rpubs.com/johndharrison/RSelenium-Docker

If your issue is not with geckodriver/firefox please fill out the template

Operating System

Windows

Selenium Server version (selenium-server-standalone-3.0.1.jar etc.)

Browser version (firefox 50.1.0, chrome 54.0.2840.100 (64-bit) etc.)

firefox 72.0.2 (64-bit)

Other driver version (chromedriver 2.27, geckodriver v0.11.1, iedriver x64_3.0.0, PhantomJS 2.1.1 etc.)

Expected behaviour

server should be killed

Actual behaviour

Selenium server signals port = 4567 is already in use.

Steps to reproduce the behaviour

Not run:

start a chrome browser

rD <- rsDriver(browser = "firefox", check = FALSE) remDr <- rD[["client"]] remDr$navigate("http://www.google.com/ncr") remDr$navigate("http://www.bbc.com") remDr$close()

stop the selenium server

rD[["server"]]$stop()

if user forgets to stop server it will be garbage collected.

rD <- rsDriver() rm(rD) gc(rD)

[jackgovier]

I believe I'm having the same issue with Chrome - neither remDr$close() or driver$server$stop() appear to be killing the process and freeing the port. Not sure what has changed to make this happen.

[msgoussi]

Since I can not kill the process, I started to use netstat::free_port(), or close and start new R session.

[adrearly]

I believe I'm having the same issue with Chrome - neither remDr$close() or driver$server$stop() appear to be killing the process and freeing the port. Not sure what has changed to make this happen.

I'm also experiencing this issue. For a few hours last week, I was able to use close without calling stop and it let me reuse a port, but it hasn't worked since then.

rD <- rsDriver(port = 4444L) remDr <- rD[["client"]] remDr$close() rm(rD) gc()

[bsleik]

It is leaving an orphaned Java process behind. Add the following command after stopping the server:

system("taskkill /im java.exe /f > nul 2>&1", intern = FALSE, ignore.stdout=TRUE, ignore.stderr=TRUE)

This works 100% of the time for me.

This is appropriate for windows, if doing on linux use the appropriate kill command if it happens there too.

[NilssonHedge]

I can confirm the issue and that the Freeport solution solves the issue. I've recently upgraded R and packages and the issue surfaced after an upgrade to the newest RStudio. But no claim that they are connected.

[adrearly]

Unfortunately, this doesn't work for me. Adding this command after stopping the server still results in the following error message the next time I try to connect to the server:

Error in wdman::selenium(port = port, verbose = verbose, version = version, : Selenium server signals port = 4443 is already in use.

I've been using a workaround that just searches for an open port before launching the remote server:

rD <- rsDriver(browser=c("chrome"), chromever="80.0.3987.106", port = netstat::free_port())

On Sat, May 9, 2020 at 3:29 AM glavkon notifications@github.com wrote:

I can confirm the issue and that the Freeport solution solves the issue. I've recently upgraded R and packages and the issue surfaced after an upgrade to the newest RStudio. But no claim that they are connected.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/RSelenium/issues/228#issuecomment-626136643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL5PHGM62XTKOYYK7QVVZFLRQUO7DANCNFSM4KQMHEZA .

[msgoussi]

port = netstat::free_port()) works fine.

[bsleik]

That approach keeps opening new selenium sessions leaving the old ones still active. Eventually, you will start running out of memory.

In windows, look in the detailed task manager and you will see a java run time left behind for each orphaned port. Killing each of these frees up the port.

Bob

On Mon, May 11, 2020 at 1:18 PM msgoussi notifications@github.com wrote:

port = netstat::free_port()) works fine.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/RSelenium/issues/228#issuecomment-626904199, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCS2F5JSYNMXPVFMQ4CBGTRRBFQ3ANCNFSM4KQMHEZA .

[helgasoft]

Agree with Bob (@bsleik) - under Windows, the correct cleanup is to kill the Java instance(s) inside RStudio. However, the proposed command did fail:

> system("taskkill /im java.exe /f > nul 2>&1", intern=FALSE, ignore.stdout=FALSE)
ERROR: Invalid argument/option - '>'.
Type "TASKKILL /?" for usage.

and the following worked:

> system("taskkill /im java.exe /f", intern=FALSE, ignore.stdout=FALSE)
SUCCESS: The process "java.exe" with PID 33592 has been terminated.

Then you could ping the port for confirmation:

> pingr::ping_port("localhost", 4444)
[1] NA NA NA    # if you get numbers here, the port is still in use

[adrearly]

Yes! That worked for me. Much appreciated!

On Fri, May 22, 2020 at 1:45 PM helgasoft notifications@github.com wrote:

Agree with Bob (@bsleik https://github.com/bsleik) - under Windows, the correct cleanup is to kill the Java instance(s) inside RStudio. However, the proposed command did fail:

system("taskkill /im java.exe /f > nul 2>&1", intern=FALSE, ignore.stdout=FALSE)ERROR: Invalid argument/option - '>'.Type "TASKKILL /?" for usage.

and the following worked:

system("taskkill /im java.exe /f", intern=FALSE, ignore.stdout=FALSE)SUCCESS: The process "java.exe" with PID 33592 has been terminated.

Then you could ping the port for confirmation:

pingr::ping_port("localhost", 4444) [1] NA NA NA # if you get numbers here, the port is still in use

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/RSelenium/issues/228#issuecomment-632885370, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL5PHGKLFAOZUJYMIW7WM2LRS3I35ANCNFSM4KQMHEZA .

[testsr-student]

Rselenium seems to be based on wdman, and this is probably a wdman bug.

[zos474]

Thanks for this - been having the same issue & driving me crazy. In my case, RStudio wouldnt let me update the R file because it said it was being used by another process & traced that to all the Java processes sitting there. I had been searching for an open port via ping, but the netstat::freeport() is much better, and the revised java killing syntax from @helgasoft worked just fine.

[Emelieh21]

Same here, thanks @helgasoft

[aronsantacruz95]

Agree with Bob (@bsleik) - under Windows, the correct cleanup is to kill the Java instance(s) inside RStudio. However, the proposed command did fail:

> system("taskkill /im java.exe /f > nul 2>&1", intern=FALSE, ignore.stdout=FALSE)
ERROR: Invalid argument/option - '>'.
Type "TASKKILL /?" for usage.

and the following worked:

> system("taskkill /im java.exe /f", intern=FALSE, ignore.stdout=FALSE)
SUCCESS: The process "java.exe" with PID 33592 has been terminated.

Then you could ping the port for confirmation:

> pingr::ping_port("localhost", 4444)
[1] NA NA NA    # if you get numbers here, the port is still in use

Thanks for this!

[sysilviakim]

This is slightly different, but the problem I had was the Rscript scheduled on Windows Taskscheduler would give (0x1) errors. Even the system("taskkill /im java.exe /f", intern=FALSE, ignore.stdout=FALSE) did not work for some reason.

The orphaned java process then prints the following error on your next Rscript run:

The process cannot access the file because it is being used by another process

Initially I thought it was my Dropbox sync misbehaving. Nope. Tried deleting the .R file in question. It will say

The action can't be completed because the file is open in java.exe

I left a similar answer to https://stackoverflow.com/questions/37820998/. I am just beginning to explore free_port so maybe that will solve the issue, but if the Java process is still "using" the .R file (I don't know how this works exactly?) using netstat may be insufficient.... I'll report back.

Going to Task Manager and manually killing java.exe worked. But you don't want to be doing that, of course.

[jackgovier]

@sysilviakim - I had the exact same issue. I think the taskkill may not be working due to admin rights in taskscheduler, but in the end I just switched to accessing a Docker instance running Firefox (which I begin and later end in the scheduled R script using system("docker start firefox")) through rSelenium and have had no issues with it.

[Danny-dK]

This may have been resolved in wdman at https://github.com/ropensci/wdman/issues/29#issuecomment-1000563322