I am having trouble when logging into the system as userA. It does not seem that the $HOME/.profile is executing. I have checked to make sure the .profile exists in userA's home directory, belongs to userA, and has the file permissions 740. I know the .profile is not being executed because there are some environement variables (including PS1 to set the prompt) that are being exported in the .profile but are not showing up when I echo them at the command line. The funny thing is that when I do "su - userA" from another user, the .profile does get executed, and all the environment variables show up as expected. Anybody have any ideas?
Was there a point when your .profile was working? Has anything changed since that time? Do any other users have this same problem or is it isolated to this one user? Is this an application or normal user?
Here are a few steps to try.
1) Copy the template .profile from /etc/skel/.profile, if you have one, into place and edit as you have your .profile configured.
2) Maybe you can mv another user's .profile into place and chmod/chown it to your user and see what happens.
3) As a last resort, alas, this may be a drastic step, but I would save any user data and remove and recreate this userID. I have seen cases of gremlins infecting a system where a user's ID is so screwed up that only blowing it away and recreating them would fix the problem.
The .profile for this user never did seem to work upon logging into the system. userA is the only user on the system with this problem.
-------------------------------------------------------------------------------
1) Copy the template .profile from /etc/skel/.profile, if you have one, into place and edit as you have your .profile configured.
-------------------------------------------------------------------------------
I don't have an /etc/skel directory, but I have done the above with the /etc/profile without success.
---------------------------------------------------------------------------------
2) Maybe you can mv another user's .profile into place and chmod/chown it to your user and see what happens.
--------------------------------------------------------------------------------
I already tried this suggestion before putting up the post, but had no success.
---------------------------------------------------------------------------------
3) As a last resort, alas, this may be a drastic step, but I would save any user data and remove and recreate this userID. I have seen cases of gremlins infecting a system where a user's ID is so screwed up that only blowing it away and recreating them would fix the problem.
---------------------------------------------------------------------------------
It may come to this if I can't figure out what the problem is.
Put a statement like "echo in .profile" as the very first line and see if that gets printed at login time. To run .profile, the shell must read it. Reading it will update the atime in the inode. You can see this with "ls -lu". Does the access time change? If so, it was read.
I did try to use an echo when I was trying to debug the problem before the original post was put up, but it did not show up when logging directly into the system by userA. The "ls -alu" shows that the profile was not executed.
I have noticed something since my first post, though. If I log into the system with a command line login, the .profile is executed. When logging in at the X prompt, and then opening a terminal window, I see that the .profile has not been run. Does using X change how/when the .profile is executed?
Not sure if AIX has this but on Solaris there is a .dtprofile which has only one real use - to set a DTSOURCEPROFILE variable to false or true - if false (the default), the .profile is not sourced. If true, then the profile is sourced. The .dtprofile is in each users home directory (normally copied when first starting CDE the first time).
