Unused /etc/init - SUN

This is a discussion on Unused /etc/init - SUN ; Hi to all, I just ran into a strange problem (to me;-) We are running a bigger sparc system#1 (cluster) for productive work. Our admins set up a new single system#2 (unclustered). Both systems got Solaris 8 installed and are ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Unused /etc/init

  1. Unused /etc/init

    Hi to all,

    I just ran into a strange problem (to me;-)
    We are running a bigger sparc system#1 (cluster) for productive work.
    Our admins set up a new single system#2 (unclustered). Both systems
    got Solaris 8 installed and are used as server, no graphical desktop,
    logins are by ssh from windows clients.

    I expected both systems to work identically but soon found out,
    something is going wrong on system#2 when
    echo "ABC" | tr '[A-Z]' '[a-z]'
    returned with
    BCD

    Tracking down the environment I narrowed the problem to the LC_
    variables.

    On system#2 all variables of /etc/init are set after login:
    LC_COLLATE=en_US.ISO8859-15
    LC_CTYPE=en_US.ISO8859-1
    LC_MESSAGES=C
    LC_MONETARY=en_US.ISO8859-15
    LC_NUMERIC=en_US.ISO8859-15
    LC_TIME=en_US.ISO8859-15

    On system#1 only
    LC_CTYPE=en_US.ISO8859-1
    is set.

    The contents of /etc/init is identically on both systems. It seems
    system#1 is not using this file cause the LC_CTYPE variable is
    explicitly set in /etc/login. There is no script unsetting the LC_
    environment.

    Is there any switch preventing the system from using /etc/init on
    process start? I didn't find any hint except for graphical desktops
    but we're not using any of these.

    Suggestions are welcome.

    Axel


  2. Re: Unused /etc/init

    Axel Sander writes:

    >On system#2 all variables of /etc/init are set after login:
    >LC_COLLATE=en_US.ISO8859-15
    >LC_CTYPE=en_US.ISO8859-1
    >LC_MESSAGES=C
    >LC_MONETARY=en_US.ISO8859-15
    >LC_NUMERIC=en_US.ISO8859-15
    >LC_TIME=en_US.ISO8859-15


    I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
    is a symlink to "/sbin/init", which is a binary, not a shell script.


  3. Re: Unused /etc/init


    "Neil W Rickert" wrote in message
    news:MsJ%i.21207$Pv2.21028@newssvr23.news.prodigy. net...
    > Axel Sander writes:
    >
    > I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
    > is a symlink to "/sbin/init", which is a binary, not a shell script.


    /etc/init.d perhaps?



  4. Re: Unused /etc/init

    On Sat, 17 Nov 2007 21:57:00 GMT, Neil W Rickert
    wrote:

    >I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
    >is a symlink to "/sbin/init", which is a binary, not a shell script.


    Hmmm, I have to check this at work. I only recalled something with
    "init" in it at home;-)
    It's a file just containing the environment variables I mentioned
    above.

    Axel


  5. Re: Unused /etc/init

    On Nov 18, 8:22 am, Axel Sander wrote:
    > On Sat, 17 Nov 2007 21:57:00 GMT, Neil W Rickert
    >
    > wrote:
    > >I'm a bit mystified there. On my solaris 8 systems, "/etc/init"
    > >is a symlink to "/sbin/init", which is a binary, not a shell script.


    Same here. You aren't confused : >

    > Hmmm, I have to check this at work. I only recalled something with
    > "init" in it at home;-)

    Theres more than one init.
    > It's a file just containing the environment variables I mentioned
    > above.


    Just a file. Is this how you collect your pay cheques? I hope not.
    Anyway, it's /etc/default/init
    The problem is more like you need to patch "tr" - on something as
    ancient as Solaris 8, there were locale issues associated with tr..
    The workaround was to use LANG=C as I recall as a last resort


  6. Re: Unused /etc/init

    On Sun, 18 Nov 2007 09:40:46 -0800 (PST), gerryt
    wrote:

    >Just a file. Is this how you collect your pay cheques? I hope not.
    >Anyway, it's /etc/default/init
    >The problem is more like you need to patch "tr" - on something as
    >ancient as Solaris 8, there were locale issues associated with tr..
    >The workaround was to use LANG=C as I recall as a last resort


    I meant "not a binary executable" (english is not my native language
    so I should've better said "text file";-)
    Sorry for the delay - I was out of the office this week.
    Of course you're right about the missing "default" in the path.

    There is no problem unsetting the LC_ environment or fiddle around
    with the PATH to use /usr/xpg4/bin executables. I was just curious why
    system#1 obviously bypasses the values in /etc/default/init while on
    system#2 all variables in this file are used and set. Both are Solaris
    8 systems and should behave the same way...

    Axel



  7. Re: Unused /etc/init

    Axel Sander wrote:
    > On Sun, 18 Nov 2007 09:40:46 -0800 (PST), gerryt
    > wrote:
    >
    >
    >>Just a file. Is this how you collect your pay cheques? I hope not.
    >>Anyway, it's /etc/default/init
    >>The problem is more like you need to patch "tr" - on something as


    > There is no problem unsetting the LC_ environment or fiddle around
    > with the PATH to use /usr/xpg4/bin executables. I was just curious why
    > system#1 obviously bypasses the values in /etc/default/init while on
    > system#2 all variables in this file are used and set. Both are Solaris
    > 8 systems and should behave the same way...


    ONLY if the systems are substantially identical! Even a slight
    difference in hardware or software configuration could make a very
    noticeable difference.



  8. Re: Unused /etc/init

    Axel Sander writes:
    >
    >There is no problem unsetting the LC_ environment or fiddle around
    >with the PATH to use /usr/xpg4/bin executables. I was just curious why
    >system#1 obviously bypasses the values in /etc/default/init while on
    >system#2 all variables in this file are used and set. Both are Solaris
    >8 systems and should behave the same way...
    >


    System 1 probably does not bypass the values in /etc/default/init, which
    are obtained early in the bootstrap sequence. It probably overrides them
    later in the bootstrap sequence. Perhaps they're overridden by your shell
    when you log in. This may sound like a meaningless argument, but when you
    are troubleshooting (and that's what you're doing when you try to find out
    why something doesn't behave as you expect), the difference between "bypass"
    and "override" is important.

    Why would two machines behave differently? For all the reasons you can
    think of why any two machines might do so. For example, the first one
    was installed at a different time by a different person, who answered the
    install-time configuration questions differently. Or the first one has
    a different set of utility programs installed.

    Or even something as simple as the first machine has everything installed
    the same, but your default PATH doesn't choose the GNU tr before the Solaris
    tr as it does on the second machine.

    When it comes to machine configuration, the only real way to answer the
    question "why is it different" is to find out *how* it's different. In
    other words, find all the files that are different between the two machines.
    One or more of those will explain why the tr program you invoke with the
    command:

    echo "ABC" | tr '[A-Z]' '[a-z]'

    produces different results on the second machine.


    -Greg
    --
    Do NOT reply via e-mail.
    Reply in the newsgroup.

+ Reply to Thread