Question

"Log to File" fails in a loop.

I
Badge +4

I am logging a Bots action with the “Log to File” command and am getting errors saying that “The process cannot access the file because it is being used by another process.”

I created a test Bot that contains a loop command and a single log to file on a network share.

This fails with an exception every single time within a few seconds.

Has anyone else encountered this and have a solution?

12 replies

S
Userlevel 2
Badge +7

Hi IanS108317,

This usually occurs when there are more than one resource trying to access the file. i.e a file is being used by another person/bot at the same time

 

to further confirm this issue. can you let me know on the below mentioned points?

  1. is the file, already in opened state/any actions being performed manually when the “Log to File” command has been called?
  2. Also, from the question, I see Log To file is happening in a loop. So, is this error coming right from the first record of the loop? or is it coming after executing few records of the loop?
  3. and may I know the file path which you are passing to “Log To file”? Thinking if the file path file already exists in the destination and being used by other resource at same time?

 

Hope this helps in triaging the issue.

Sai Teja Gayala

Raul Jaimes
Userlevel 5
Badge +9

@IanS108317 

If possible, kindly provide a screenshot of the bot actions. Try to add a minimum delay before LogtoFile action.

Regards

I
Badge +4
  1. Nothing else is accessing this file, I am only running one instance of this Bot and the file is  uniquely named.
  2. In my test it is in a loop, but in the Bot that is failing it is simply logging events to a file and events that happen quickly enough trigger this error.
  3. The path is not being used by anything else.  In my test script I used a unique file not used anywhere else.

If I add a delay of 500ms the error occurs within a few seconds.  If I add a delay of 1000ms the error occurs in 10-15 seconds.  If I add a 2000ms delay the error does not seem to occur.

So a 2 second delay will fix the problem, except not knowing what the bug in AA is this can’t be relied on.  It’s possible in some circumstances it may still fail even with 2 seconds.

AA should not be failing to write to a file repeatedly.

This is a screenshot as requested, it’s just a loop with a Log command.  The full path is not shown as it is a business environment and I can not share the actual network share names.

 

Raul Jaimes
Userlevel 5
Badge +9

@IanS108317 

If possible, perform a test mapping to a network drive like Z:\

Regards

rbkadiyam
Rank
Userlevel 5
Badge +14

@IanS108317 looks like you do not have write access for the file, please make sure the bot id have read & write permission to the file.

Ramesh B Kadiyam
J
Badge

Hi,

since approx. two weeks ago I started experiencing the same issue. Bots that used to work for months without issue suddenly began failing on this exact action (Log to File) when used in loop.

As the bots worked for so long, I know fur sure that the RPA accounts have all the needed accesses and rights. The log files are also saved in the file system/shared drive.

Adding a delay before each Log to File action is not a great solution as the bot runtime may multiple several times.

Can anyone advise how to solve this issue?

Thanks

Jan

I
Badge +4

@IanS108317 looks like you do not have write access for the file, please make sure the bot id have read & write permission to the file.

I clearly have permission to write to the file because it writes several times before the error occurs.

Theodore Xypteras
Rank
Badge +3

The exact same issue started happening in our installation a few days ago. It happens in old tasks and new. They all log to network shares. This is the first time it’s happened since we started using AA in 2018.

I have a cunning plan!
S
Badge +2

has Automation Anywhere pinned down a solution here, or is the current recommendation to roll back to a previous Log to File Package? We have this same issue where logging to a Network Drive Fails but logging locally on the VDI has no issues.   current package in use is 3.5.0-20220416-XXXXXX

G
Badge

Any updates on this problem?

K
Badge

Did anybody find a solution, please? The same issue started happening for us a month ago.

DeLo
Badge +4

As mentioned in this thread, this is happening frequently and seems to be affecting many of our bots. These bots wrote their logs for so long, flawlessly. Now we’re experiencing this. All bots write to their own unique logs in a shared network location. No chance of anything else accessing them and locking them. Please advise.

Reply


Terms & ConditionsCookie settings