Hi, people !
I have an issue executing a Command Job.
After installing, I tried to run de id command and I got this sysout:
+ id
/home/controlm/ctm/runtime/CMD.00004q0z_00m[2]: id: not found.
but when I ran it with its complete path, I got the follow sysout:
+ /usr/bin/id
uid=1001(cissys) gid=1000(cisusr)
I tried to run the same command on another server where CTM agent is installed and it worked fine. I compared both profiles and there's no difference.
Do you know what is the problem and how can I solve this? If it helps, the OSCOMPSTAT=127
Regards,
Eche
Problems with OS user profile
- philmalmaison
- Nouveau
- Posts: 1148
- Joined: 08 Jun 2007 12:00
- Location: Ile de France
- th_alejandro
- Nouveau
- Posts: 188
- Joined: 26 Nov 2008 12:00
- Location: Bogotá
Hola
Compañeros, Control-M realmente no se loguea con el usuario y no ejecuta el profile del usuario. Al ejecutar un comando del sistema operativo con el job tipo 'command', debes incluir el path del comando, si no no funciona.
Re: Hola
th_alejandro said:th_alejandro wrote:Compañeros, Control-M realmente no se loguea con el usuario y no ejecuta el profile del usuario. Al ejecutar un comando del sistema operativo con el job tipo 'command', debes incluir el path del comando, si no no funciona.
Control-M doesn't really login with the user and doesn't run the user profile. When you run an OS command with the job type 'command', you must include the path of the command. If you don't, it doesn't work.
th_alejandro, I don't agree with what you're saying. I executed the same command on another server with the same user, without the complete path and it worked:
+ id
uid=110(cissys) gid=108(cisusr) groups=1(other)
It seems to be something in the user's profile, but I can't find any difference. I'm still looking for a difference.
If someone can tell me a possible solution to this problem, I'll be thankful.
- philmalmaison
- Nouveau
- Posts: 1148
- Joined: 08 Jun 2007 12:00
- Location: Ile de France
Hi,
You maybe wrong too, trying on another server not ensure that the path is ok.
it just because you probably not have the same path on this new host.
What is to check is the env command on your source server that is not working fine, and just verify that the path for your command is well read by your user at startup for the job.
Regards,
Philmalmaison
You maybe wrong too, trying on another server not ensure that the path is ok.
it just because you probably not have the same path on this new host.
What is to check is the env command on your source server that is not working fine, and just verify that the path for your command is well read by your user at startup for the job.
Regards,
Philmalmaison
Thanks for repliying, philmalmaison. I don't understand pretty much what you said. I think the path is OK, and the same on all servers, because when I ran the command by console, it worked, with and without the path.philmalmaison wrote:You maybe wrong too, trying on another server not ensure that the path is ok.
it just because you probably not have the same path on this new host.
What is to check is the env command on your source server that is not working fine, and just verify that the path for your command is well read by your user at startup for the job.
The problem appears when I want to run commands like 'id', 'which ###', 'env', commands that should live in /usr/bin (and they actually do, beacuse I ran them by console and they worked) but when I tried to run them as a Command Job on Control-M they just don't.
BMC Support told me to run 'su - <username> -c "<cmd>" ' and it worked, but it doesn't solve the problem for me. In my opinion, seems to be somenthing about OS user's profile but I can't work this way.
I'm still looking for a solution and if you can figure it out, I'll be very thankfull.
Regards,
eche
Finally, I found a solution.
The BMC Support guy found the following in the systout:
+ su - cissys -c id
stty: : Not a typewriter
He told me that something in the user login scripts profile that does the stty and ask me to check the login script and remove any statement that is setting the stty.
Indeed, I found stty erase ^?. First of all, I commented it and the job was OK.
Then I checked the profile and I found this other line:
stty erase "^H" kill "^U" intr "^C" eof "^D"
And changed stty erase ^? to stty erase "^?"
Fortunately, the problem disappeared. I'm still wondering why this didn't happen in the other servers, but at least the issue was solved.
Regards,
eche
The BMC Support guy found the following in the systout:
+ su - cissys -c id
stty: : Not a typewriter
He told me that something in the user login scripts profile that does the stty and ask me to check the login script and remove any statement that is setting the stty.
Indeed, I found stty erase ^?. First of all, I commented it and the job was OK.
Then I checked the profile and I found this other line:
stty erase "^H" kill "^U" intr "^C" eof "^D"
And changed stty erase ^? to stty erase "^?"
Fortunately, the problem disappeared. I'm still wondering why this didn't happen in the other servers, but at least the issue was solved.
Regards,
eche
- shahidsaif
- Nouveau
- Posts: 3
- Joined: 06 Dec 2012 12:00
- Contact: