Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
ENV must be set upon invocation of ash if the shell is not a login shell. Since there was no output of of the line PROFILE, we can assume your shell is not a login shell. See my post #14 about how to determine this. So, setting ENV won't have any affect in non-login shell situations.
How would ENV be set upon invocation of ash? Like this:
But you can't do this because you are logging in and don't have control of the program that starts ash. (it may be possible for you to configure that program to set the ENV environment variable before invoking ash - I don't know what program busybox uses to do this; typically this is a program such as getty or gdm calling login).
The ash shell is setting its process name as "sh". We see:
838 root 2252 S /bin/sh -sc /etc/profile
850 root 2256 S /bin/sh
864 root 2252 S /bin/sh
The first one says to take commands from /etc/profile, so it appears that file should be read. The other two are just shells. None of the three appear to be login shells (or they don't follow the - as the first character protocol).
Place the line
at the top if your /etc/profile and logout/in and report the output.
Sorry this is so challenging. What would be trivial to diagnose and solve at the keyboard becomes very difficult via forum communication. There is a lot of explanation required to help you understand the pieces of this puzzle so you can get accomplished what seems to be a simple task.
The shell is not started by your rcS script. It is started by another program. Run
to see the process tree so that you can see the relationship between the processes and their children.
You have not been seeing output from your echo commands because there is no TTY associated with the shell processes that have been run. This is why they are not login shells. And later shells have been simple interactive shells only, hence all the efforts have been fruitless.
To determine the correct location for setting DISPLAY, you need to know the startup process that ultimately leads to your login and shell. The init process uses an inittab (/etc/inittab, but it doesn't have to exist in busybox) to determine which programs to launch upon startup. It will launch programs like getty and your ultimately the rcS script. Since your rcS script is a subproces of init, it cannot set environment variables for other direct children of init. The environment variable must be set in a parent. The rcS script mounts disks, sets up networking, and starts the X server. But it does not startup your getty/login session - which is being done by by init (since we don't see it in your rcS file).
What is the contents of your /etc/inittab ?
There are many variations on how environment variables are configured for user shells, and how terminal programs are started in GUI and non-GUI environments. I don't know your busybox environment, and so I don't know which variation is in use, and so can't easily give step-by-steps to solve this problem.
Ah well, I like the challenging part, but sometimes it would just be nice if a part just works
But at this way my Linux knowledge is growing, and that's nice to. And I really want to thank you for your help so far, and I know it's hard to explain things on a forum, since you don't have any clue what the knowledge of the one you are explaining to is, and small errors (ash instead of bash) are making it harder and harder, but I really appreciate your help!
I guess the first line starts my rcS script, and the ::respawn /bin/bash -sc /etc/profile starts bash, but I thought I was using ash?? I looked up /bin/bash with a ls -all, and found out that /bin/ash is a link to busybox, but nothing to find out about /bin/bash. The ash and bash are confusing me a little, perhaps something in there is also one of the problems why things aren't working properly?
You do have an inittab, and it shows that your tty's are started via getty (serial port) and one shell (/bin/bash) which is likely the console. But your /bin/bash is really an ash shell (as we've seen from the output).
Now your login showed:
192.168.0.253 login: root
Am I correct that this a remote login (via telnet), or is this a console login?
I use linux on an embedded system, and the embedded system doensn't have a keyboard, so I have to login remotely. If needed however I can using minicom connect my board directly, but as far as I know that wouldn't change a lot right?
This explains more of the data. I went and read the source code to verify what is going on.
Since you are telneting, telnetd is responsible for launching /bin/login, which ultimately logs you in to a shell. Login has an option (-p) to allow maintaining the environment, but telnetd does not supply this option, so you cannot set an environment varible before telnetd is started to affect telnetd's children. So, you must set your environment variable after the shell is launched, either using shell mechanisms or manually.
The source code shows that login does invoke the shell as a login shell. The ps output we're seeing is the command executed, and not the modified command name with a dash to indicate a login shell. I verified that /etc/profile is indeed read by the shell when it is a login shell, so you should be able to prove this.
Add the line
echo $$ > /tmp/mytest.$$
to the top of your /etc/profile, and then logout/in, and then run :
Yup, I was expecting to see a file in /tmp. This means the source code that I read does not match what you are experiencing. And given the crippled version of some commands, it makes diagnosis difficult (can't see how /bin/sh was called for example in ARGV.
I verified telnetd calls login without arguments, and login invokes a login shell (it places a dash in front of the shell name, which we can't see because of the crippled ps). Regardless, we can only go by what the results tell us - /etc/profile is not being read. And if this is the case, you'll have to set the DISPLAY environment variable when starting your X commands.
You might want to consider asking your question on the busybox mailing lists - they may know something I wasn't able to see in the quick source code read.
well, is it a possibility that in my inittab file (see one of earlier posts) is not correct in starting bash. I vaguely remember I edited it partly last week, but I forgot to make a backup before I changed, what I usually do..
Shouldn't it start sh instead of bash?
And I start the Xserver in the rcS script. Perhaps theres a file that runs the Xserver where I can put a link to my exports?
I want to thank you for your time, I learned some new things and I feel I am closer to a solution then before you helped me.
If you launch bash yourself, what shell do you actually get?
Type set to see the list of variables. Bash will set BASH_VERSION. The sh and ash shells will not; look in shell variables and environment variables for any version/shell information.
I did not see source code for bash in the busybox environment. There is ash, hush, bbsh, and msh. But your environment may have other tools.
The default login shell is "-/bin/sh" (the dash indicating a login shell should be created), and the default shell ($SHELL) is "/bin/sh". Since there is no source code for the "sh" shell, one of the above shells must be a link to one of the other shells. Shells called by another name may operate in compatibility/impersonation mode, impersonating the shell name their are called by (i.e. ash may act exactly like sh if called by the name sh).
A login user's shell is controlled by the shell parameter in /etc/passwd. Check out root's login shell.
You are missing the point about sibling processes not being able to affect their sibling's (or parent's) environment. Your X server is started in the rcS script. Any environment variable you set in that script can *only* affect those processes started by that script. Any "file that runs the Xserver" can only affect children of that file (script/program). Since telnetd is NOT started by that script, telnetd wold not magically inherit any environment variables set there. Furthermore, as I mentioned, the login program (spawned by telnetd) WIPES OUT the environment and specifically sets it to only required, safe values, unless the -p option is specified on the command line. To change this behavior, you would have to recompile telnetd. So, via telnetd, you get:
\ login (with wiped environment)
The initialization code from rcS looks like:
initial rcS processes
\ login (with wiped environment)
\ shell <--- you are here
\ xserver clients
You should be able to see that the Xserver and any clients do not affect the shell that ultimately get's created via telnetd.
Since login launches a shell (/bin/sh), you could replace /bin/sh with an executable wrapper script such as: