Does this action impose some sort of timed abort? I'm suffering from an aborting rsync command, which returns with empty stdout and stderr variables, and a zero return value, through an exception. Executing the command manually finishes successfully, running it from Automagic causes an exception after some time, with no clue for the reason. Running the Automagic action again will usually succeed - possibly because remaining rsync activity is now shorter, as part of it has already been done during the first attempt. Reading the corresponding logs also doesn't provide a clue about the reason of termination.
I could, as workaround, probably run the rsync command in the background, but shy away from the additional complexity of a separate flow with some sort of semafore trigger which picks up again after rsync has completed.
Execute command as root
Moderator: Martin
Re: Execute command as root
There's indeed a fix timeout of 5 minutes in action Execute Root Command. Does the abort occur after five minutes?
I'll add a configuration for the timeout since an arbitrary timeout of 5 minutes makes not much sense.
As a workaround you could run a few rsyncs sequentially on a few subfolders if the directory structure allows to partition it in this way.
I'll add a configuration for the timeout since an arbitrary timeout of 5 minutes makes not much sense.
As a workaround you could run a few rsyncs sequentially on a few subfolders if the directory structure allows to partition it in this way.
Re: Execute command as root
"About five minutes" feels right, I've only recently added measurement support to the flow. My current workaround is looping back to command invocation in case of an exception, but a configurable timeout would be much preferred. Thank you.
Re: Execute command as root
Nice coincidence here, I just ran into this problem too, also with rsync. The error says to "check the log for information" but the log has no information. I suspected a timeout because the flow fails after exactly five minutes.
Note that, from what I can tell, the command is not killed; just the flow fails. In the rsync case, that's probably good, but that may be really bad for other cases.
Note that, from what I can tell, the command is not killed; just the flow fails. In the rsync case, that's probably good, but that may be really bad for other cases.