mstbaum
mstbaum

Reputation: 434

Selenium Test Runs on Command Line but Not Through Task Scheduler

I have a python Selenium test that opens firefox with Firebug and Netexport, logs in to a webpage and waits for the last page in the redirect chain to load. This test runs perfectly fine when I run on Windows command line, but when I try to run it from Task Scheduler, 9/10 times it can't find the Firefox Profile. Every now and then the test works as expected.

I'm not very familiar with the quirks of Task Scheduler, so this behavior doesn't make sense to me.

The task is not hidden and I have it set right now to only run when logged on. It is configured to run on Windows Server 2012, which is what the VM is running.

Any knowledge on this issue would be greatly appreciated. Below is what I believe to be the relevant code, but let me know if it's insufficient.

profile = webdriver.FirefoxProfile('path/to/default/profile')
# set up extensions/preferences
...
driver = webdriver.Firefox(firefox_profile=profile)
driver.get(<URL>)
# send_keys and other interactions
...

I have also tried not specifying a profile location and letting selenium create a temporary profile. Same results.

Error Messages:

When Firefox opens I get

Your Firefox profile cannot be loaded. It may be missing or inaccessible.

The exception from selenium is along the lines of

WebDriverException: Message: Can't load the profile. Profile dir: %s

Followed by stuff about checking the log file (which doesn't exist)

Upvotes: 1

Views: 1873

Answers (1)

mstbaum
mstbaum

Reputation: 434

After some poking around in the source code/some more debugging, I have found the root cause and the solution.

  • Specifying the Firefox profile directory only tells selenium where to copy an existing profile from. It will still create a temporary profile.
  • The temporary profile gets created in the run directory of the task. In my case I was running the script in command line from the script's directory, but Task Scheduler starting in Server 2008 runs scripts from C:\Windows\System32 by default
  • I specified the run directory in the "Start in" option in the Action of the task

I still find it odd that although the user running the task was an administrator, it seems that the profile could not be read from System32 (as suspected by @SiKing). Changing the landing location fixed the issue.

Upvotes: 0

Related Questions