[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20011010: LDM not starting at boot

Patrick O'Reilly wrote:
> 
> >
> 
> I took out the .login file (moved it to .NOlogin) and rebooted, and voila,
> the boot process ran with no hitch.  I logged on and sure enough, the LDM
> was running.  So it seems maybe you figured it out.  I didn't make it as far
> as editing the script as your first suggestion seemed to work.  So it seems,
> problem solved.
> 
> I am working on radar data and a failover with Jeff now, so we may be all
> set soon.  Thanks again!
> 
> Patrick
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Patrick O'Reilly                               Support Scientist
> The STORM Project            address@hidden
> 208 Latham Hall                             ph: 319-273-3789
> University of Northern Iowa
> Cedar Falls, IA 50614
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Patrick,

Great!  Thanks for letting me know.  I'm glad we were able to narrow
this down.  However, I would not consider it a complete solution.  You
should be able to have a .login file in place, so you can set up your
environment when you do a login.  (This is different than setting up a
shell environment via .cshrc when you invoke the shell.)

I'm thinking that in general it's an error for the boot script to invoke
a login shell.  However, many people mistakenly set up their environment
via .login, including variables needed by the ldm.  So,  I'll have to
think about whether to change the script or not.

Yours is the only system where I have seen this cause a problem.  I
still think it would be worth a test to remove the '-' option to 'su' in
the boot script.  Another alternative (although less satisfactory from
my own engineering perspective) is to figure out what in .login is
causing the problem.  I really wonder about the line 'stty -istrip' in
your now .NOlogin.  That's probably the only line that is actually being
invoked at boot time.  The man pages says the -istrip option will "clear
high (8th) bit of input characters".   It may be that simply removing
that line is enough.

However, if you are happy with how things are set up, then that's good. 
I'm glad things are working better for you.

Anne
-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************