I have a job on a Control-M server with owner 'abc'.
Sysout Handling in Post Processing tab is set to Copy, and a path is defined to /home/abc/job.out
Once the job ends OK, the sysout can be viewed just fine in Control-M and is saved in the controlm directory, but the sysout handling produces an error which is visible in the Control-M log. The copy or move handling options don't work. Deletion works fine.
The only way I was able to get the sysout to copy was by changing the job's owner temporarily to 'root'. 'ctmagent' or 'controlm' didn't work either.
Thinking it might be some kind of permission issue, I even tried specifying /tmp as the destination (that's rwxrwxrwx by default) and it still wasn't successful with original owner 'abc'.
If I log onto UNIX with abc, I am able to cp controlm/sysout/job.out /home/abc/job.out just fine.
I've been racking my brain over this for over 10 hours... can anyone help me?
Sysout handling problems in postprocessing (UNIX)... help!
Hi chookgate, thanks for your input!
I considered the path being too long, but I tried multiple paths and filenames, as well as /tmp, and nothing worked.
The file doesn't exist already at the destination, no.
The ownership of the sysout in the controlm directory is set to whatever owner is defined in the job definition. abc:abc in the case of abc, and root:admin in the case of root.
I tried specifying just a path, that didn't work either.
The error message in the CM log doesn't give any clues. I can't reproduce it verbatim right now as I'm away from the office, but it's something along the lines of "JOB LOG COPY FAILED; CANNOT COPY LOG TO <PATH>", and then a subsequent one "CANNOT CHANGE JOB LOG PERMISSONS TO <octalvalue> and <octalvalue>" (the latter error presumably occurs because the file is not there).
I will post it here word for word when I get back to the office.
If you or anyone else has any other ideas, feel free to shoot them my way.
I considered the path being too long, but I tried multiple paths and filenames, as well as /tmp, and nothing worked.
The file doesn't exist already at the destination, no.
The ownership of the sysout in the controlm directory is set to whatever owner is defined in the job definition. abc:abc in the case of abc, and root:admin in the case of root.
I tried specifying just a path, that didn't work either.
The error message in the CM log doesn't give any clues. I can't reproduce it verbatim right now as I'm away from the office, but it's something along the lines of "JOB LOG COPY FAILED; CANNOT COPY LOG TO <PATH>", and then a subsequent one "CANNOT CHANGE JOB LOG PERMISSONS TO <octalvalue> and <octalvalue>" (the latter error presumably occurs because the file is not there).
I will post it here word for word when I get back to the office.
If you or anyone else has any other ideas, feel free to shoot them my way.
This is the first time I see it too!
But if post-processing is being done by the agent with the root uid as you suggest, then it does seem to make sense, as the file might inherit root's (or, as I previously thought, the agent's) uid and gid during the copy process.
The uid/gid values in the error log correspond with abc's uid/gid. But if the agent performs post-processing as root, then I really don't understand why it's producing the error. And the fact that changing the job owner to 'root' produces no error just throws me off even further. I can't figure it out!
The job is running on the same host as the agent, yes.
But if post-processing is being done by the agent with the root uid as you suggest, then it does seem to make sense, as the file might inherit root's (or, as I previously thought, the agent's) uid and gid during the copy process.
The uid/gid values in the error log correspond with abc's uid/gid. But if the agent performs post-processing as root, then I really don't understand why it's producing the error. And the fact that changing the job owner to 'root' produces no error just throws me off even further. I can't figure it out!
The job is running on the same host as the agent, yes.