Tom Brown wrote:

...

When I log in to the gui desktop as the user and then open a terminal screen the instructions in the .bashrc do get executed and the application runs as it should.

something in the run level - 3 vs's 5 ? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Hi Tom,

I am in run level 5 in both cases - I just use <Ctl><Alt>Fx to geet to non-gui screen.

Thanks for the reply

ChrisG

Dave K wrote:

On 3/23/07, Chris Geldenhuis cgeldenhuis@jhb.ullmanns.co.za wrote:

...

Any ideas of where to look ?

My first thouth is that the recreated directories have the wrong ownership or permissions. Perhaps even the restored files have had their ownership/permission trashed.

The permissions and owner/group for all the directories in /home and the bashrc files are set to the same as on the originating system.

Thanks

ChrisG

Alfred von Campe wrote:

On Mar 23, 2007, at 7:55, Chris Geldenhuis wrote:

...

[snip] However when I then log in to the recovered system as a user via ssh, or directly on a tty (non-gui), the login process does not execute the instructions in the user's .bashrc file and I get a shell prompt with none of the required environmental variables set - also the last line in the .bashrc is an exec of a script that bring up the application - this does not happen.

When I log in to the gui desktop as the user and then open a terminal screen the instructions in the .bashrc do get executed and the application runs as it should.

Any ideas of where to look ?

For starters, add some echo statements to the beginning of the .bashrc file to ensure that it is being executed. Maybe an error is occurring when it is a login shell. I usually debug startup problems like this by putting an exit call half way through the .bashrc file and add some echo statements.

Alfred

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Thanks for the ideas - I will try them on Monday when I get back to site.

ChrisG

Matt Hyclak wrote:

On Fri, Mar 23, 2007 at 01:55:00PM +0200, Chris Geldenhuis enlightened us:

...

I am trying to set up a quick disaster recovery methodology for a client. It is supposed to work as follows:-

All Data files , everything in /etc (except for a few hardware specific files such as fstab), all users .bashrc and .netrc files, all cron tables etc. is written to a DVD as a zipped tar file. A recovery script that unpacks this file, creates any directories required by the application that are not backed up etc. is also written to the DVD.

The DVD is then mounted on a freshly installed system (Centos4.4 at present) and the restore script is run. This restors all the saved files on the DVD to their original positions and creates empty directories where required for the application to run.

The recovery system is then rebooted and the differences in hardware are taken care of by "kudzu" removing hw that was present on the "old" system and installing hardware present on the "new" system - typically network cards, usb controllers, scsi controllers, IDE controllers and graphics cards.

All of the above works perfectly.

However when I then log in to the recovered system as a user via ssh, or directly on a tty (non-gui), the login process does not execute the instructions in the user's .bashrc file and I get a shell prompt with none of the required environmental variables set - also the last line in the .bashrc is an exec of a script that bring up the application - this does not happen.

When I log in to the gui desktop as the user and then open a terminal screen the instructions in the .bashrc do get executed and the application runs as it should.

Any ideas of where to look ?

The bash man page, especially the section titled INVOCATION

Matt

Hi,

Thanks to all the guys that replied. Experimenting with the flags given in the "INVOCATION" section of the bash man page has led me to a work-around. I still don't understand why the original set up did not work and why this does but I have to move on to the next project.

The work around is to edit the /etc/passwd file with sed in the recovery script and change all the /bin/bash fields at the end of the user's lines to /bin/bash -i. The exception is root - if root is changed the "su" command does not work.

It works equally well if just a space is appended to the users lines in /etc/passwd.

Logging in as a user on the gui screen and then starting a Terminal screen no longer works. This is a minor inconvenience as users are not supposed to work on the systems console.

Thanks again

ChrisG