Linux questions

[yawningdog]

Got redhat7 installed and running. How come some of my X windows will not resize the way windows windows do? Also, can anybody recommend a good ISP that supports Linux?

------------------
You cannot break God's law. You can only break yourself upon it.

[Rick]

The window resize may be limited by the screen resolution your using.
Or the program..

Sorry I can’t help you on the ISP.
With dial up having ISP support isn’t really needed ..
Just use your Linux dial-up and log the script requests .
Enter the correct info manually .
Then create a script to enter the info at log in.

Aside from the log in ISP support for Linux is not needed.

------------------
To ERR is HUMAN
To REALLY screw things UP, YOU NEED a COMPUTER !

[Rick]

Also here is a good link to some very usable info for setting up a modem in Linux.
http://www.extremetech.com/article/0,3396,s%253D1027%2526a%253D8217,00.asp



------------------
To ERR is HUMAN
To REALLY screw things UP, YOU NEED a COMPUTER !

[yawningdog]

Yeah okay, I wont be online soon anyway since I don't have a hardware modem.

My sound doesn't work. How can I tell if my onboard sound needs to be installed, or if I just need to configure a setting somewhere?

How do I leave the Gnome desktop and go back to the regular old prompt?

------------------
You cannot break God's law. You can only break yourself upon it.

[Rick]

By Hardware Modem you do under stand they mean any modem that is Not a Winmodem?

To get your sound card working you may need to run Xconfig.
It should auto detect your sound card and set it up for you.
If you have Onboard sound and an add in card make sure the Onboard is disabled in the bios.

I found the easiest way to get back to the prompt is to log off from Gnome .
Then log on again and select the desktop you want to use from the log on options menu

------------------
To ERR is HUMAN
To REALLY screw things UP, YOU NEED a COMPUTER !

[yawningdog]

I've been made aware what modem I need and I do not have one. (Mine is definitely a winmodem)

Couldn't get Xconfig to run for whatever reason, but when I tried to open sound mixer in my KDE desktop, it suggested I run /usr/sbin/sndconfig. I did this but I kept getting a warning that I shouldn't run it in a GUI. I tried what you said, but the only login options are Gnome, KDE, and failsafe. Well, failsafe is a misnomer, let me tell you. I used this interface, (it looks a little like the real prompt) ignored the warnings, and the system locked up, and now I can't even boot because everything locks up while loading sound. (Although the sndconfig did appear to be configuring my sound while it was at work.)

So now I'm just going to reload redhat, unless someone smart talks me out of it. But the question remains, how do I get all the way out of the GUI.

Here's another question. Why couldn't I just run sndconfig by double clicking the icon in the file manager?

By the way Rick, I really appreciate the help. http://www.PCGuide.com/ubb/smile.gif

------------------
You cannot break God's law. You can only break yourself upon it.

[TVC15]

If you just want to get to a command prompt then you can use the terminal emulation window within Gnome. There is an icon on the task bar which will open one up for you.

If you want Linux to go straight into command prompt mode when you boot up then you need to alter the default run level from 5 to 3. To do this open the /etc/inittab file in gnotepad (or what ever editor you prefer). Next locate the following line:

id:5:initdefault

Now change the 5 to a 3, save your changes, reboot and that should take you straight to the command prompt.

Any problems then blame the people who wrote Linux for Dummies (3rd edition)!

------------------
Up every evening 'bout half eight or nine,

I give my complete attention to a very good friend of mine.

[yawningdog]

Okay, I set my default run level for 3 and now all I have to do is reboot. Seems odd though, that a system with a reputation for flexibility doesn't demonstrate the option to "de-boot" to level 3 from 5.

Okay, let's talk internet some more. I do need an ISP for connection don't I? I'm trying to connect to my netzero account with a seperate external 28.8 modem (dont ask) and I can hear connection sounds, but the protocol never completes and Linux just continues to redial. I'v set everything up according to the instructions in Linux for dummies, 3rd edition. Any suggestions?

------------------
Give a man a fish, and you feed him for a day. Teach him to use the net, and he wont bother you for weeks.

[pjungwirth]

yawningdog--

I can't help you with the modem, but you don't need to reboot the whole machine to change run levels. The command to use is telinit. To enter runlevel 3, just type telinit 3. You can leave initdefault to whatever setting you want linux to boot to, and then just use telinit to get somewhere else when necessary.

Personally, I leave initdefault at 3 and just type startx to get into Gnome when I want, bypassing runlevel 5 altogether. I get a bunch of errors when I log off from Gnome, but they don't seem to hurt anything.

I've noticed that if I initdefault to 3, login, telinit 5, login, and telinit 3, I'm taken back to my original login session, not the login prompt. But if I initdefault to 5, login, telinit 3, login, and telinit 5, I'm taken back to the login prompt, not my original session. It must have something to do with the rc scripts, but I haven't checked yet. Just kind of interesting. Don't telinit 3 if you want to get back to your X session, because it's gone!

I hope this helps, and good luck on the modem.

Paul
~{:-)

[pjungwirth]

Okay, now I'm confused! GH, maybe you can help on this one.

If I'm running Gnome, whether from booting into it via initdefault=5 or from typing startx after an initdefault=3 boot or from booting into runlevel 3 and telinitting to 5, I can see two processes named gdm. If, from any of these states, I telinit to 3, those processes get killed.

In my (standard RH7.1) inittab file, I see this entry:

x:5:respawn:/etc/X11/prefdm -nodaemon

This is a script that launches your preferred display manager, which in my case is gdm.

What surprises me is that in the rcn.d directories, I don't see anything to kill X. So why does gdm get killed when I telinit to 3?

The inittab man page says this:

When the system runlevel is changed, any running processes that are not specified for the new runlevel are killed, first with SIGTERM, then will SIGKILL.

The init man page says something similar:

When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. It then waits 5 seconds before forcibly terminating those processes via the SIGKILL signal.

This raises a bunch of questions for me. First off, what does it mean to be "defined in the new runlevel"? Does the process have to have an entry in inittab or it gets killed? If so, why do the rc directories have kill scripts? Won't everything but the gettys be killed before you even get there?

I also tried this experiment. In runlevel 3, I ran vi in the background. When I switched to runlevel 5, I could still see it with ps -e | grep vi. If I'm reading the man page correctly, shouldn't vi have been killed?

If I run vi in the background in runlevel 5 and telinit to 3, then vi gets killed. At first I thought this was just a side effect of its parent X-window getting killed, but shouldn't running something in the background prevent that? Don't background processes ignore SIGHUP signals?

In fact, if, in Gnome, I run vi in the background and I close the window, vi gets killed. Even if I run vi with nohup and close the window, vi gets killed. Strange! So vi getting killed from a 5-to-3 change probably is the result of its window getting killed. But that still doesn't explain why vi *isn't* killed in a 3-to-5 change. But it clearly means I'm misunderstanding the init and inittab man pages. So what *do* they mean?

I thought I understood how init started and stopped processes on runlevel changes, but now I see I don't understand it at all. How does init decide what to kill on a runlevel change? And if it kills everything, why does rc kill things, too?

Thanks for your help!

Paul
~{:-)

[Ghost_Hacker]

The easiest way to switch sessions ( red hat 7 and I'll assume this works for all versions) is to hit "crtl" and "alt" and then any of the "f" keys. "crtl"+"alt"+"F9" will take you back to your GUI session. "F7" and "F8" are "log" sessions.

I don't have my linux box with me today, so a more detailed answer will have to wait till Monday. Unless some Linux guru (which I'm not http://www.PCGuide.com/ubb/smile.gif ) would care to answer for us.


Anyway hope this helps http://www.PCGuide.com/ubb/smile.gif

------------------
Comment heard from a Klingon programmer.

"Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!"

[kaos]

"In my best Martin Luther King voice"
I have a dream....One day a question will be asked that GH doesn't know...
You're the man GH! I can't believe what you and sea mjc etc. know. amazing!

[Ghost_Hacker]

Here's something which may help explain things.


"Each runlevel has a directory of symbolic links pointing to corresponding scripts in the init.d directory. These directories are usually:
/etc/rc.d/rc0.d
/etc/rc.d/rc1.d
/etc/rc.d/rc2.d
/etc/rc.d/rc3.d
/etc/rc.d/rc4.d
/etc/rc.d/rc5.d
/etc/rc.d/rc6.d

The names of the symbolic links found in these directories are significant. They specify which services should be started, or stopped, and when.

Links beginning with a capital "S" are to be started, whenever the system is entering the given runlevel.

Links beginning with a capital "K" are to be stopped whenever leaving that runlevel.

As the scripts are executed in the order listed, each symbolic link has a number at the beginning of it's name.

Here is a sample of some of the links in /etc/rc.d/rc2.d:

K20nfs -> ../init.d/nfs
K50inet -> ../init.d/inet
S60lpd -> ../init.d/lpd
S80sendmail -> ../init.d/sendmail


When the system changes runlevels, init will compare the kill list (links beginning with "K") in the current runlevel directory, against the start list (links beginning with "S") found in the destination directory. It will then determine which daemons should be started or stopped accordingly.

Example:

When the system boots to runlevel 3 it will execute all "S" entries in the order listed:

/etc/rc.d/rc3.d/S60lpd start
/etc/rc.d/rc3.d/S80sendmail start
(and so on...)
If the system is to change to runlevel 1 it will execute:

/etc/rc.d/rc3.d/K20nfs stop
/etc/rc.d/rc3.d/K50inet stop
(assuming nfs and inet do not have start entries in /etc/rc.d/rc1.d) in other words if the process exist on the "kill" list but doesn't exist on the "start" list then it is killed. Otherwise it is respawned or restarted.

It will then process any start entries in /etc/rc.d/rc1.d which are not currently running. In this case their is only one:

/etc/rc.d/rc1.d/S00single"


Also......


If I'm running Gnome, whether from booting into it via initdefault=5 or from typing startx after an initdefault=3 boot or from booting into runlevel 3 and telinitting to 5, I can see two processes named gdm

possible answer.....

"Init assumes that processes and descendants of processes remain in the same process group which was originally created for them. If the processes change their group, init can't kill them and you may end up with two processes reading from one terminal line."

Hope this helps http://www.PCGuide.com/ubb/smile.gif


------------------
Comment heard from a Klingon programmer.

"Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!"




[This message has been edited by Ghost_Hacker (edited 08-13-2001).]

[Ghost_Hacker]

Kaos..... Don't know about the rest of the gang, but I spend way to much time in front of computer screens http://www.PCGuide.com/ubb/tongue.gif

------------------
Comment heard from a Klingon programmer.

"Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!"

[pjungwirth]

GH,

What you describe is how I *used* to understand runlevel changes, which is why gdm getting killed has me so confused. But before I tackle that, let me offer one small demur to what you said. My sys admin book agrees with you that kill scripts get run on *leaving* a runlevel, but that's not what RH 7.1 does in /etc/rc.d/rc. Here's the code:

# Is there an rc directory for this new runlevel?
if [ -d /etc/rc$runlevel.d ]; then
# First, run the KILL scripts.
for i in /etc/rc$runlevel.d/K*; do
# Check if the script is there.
[ ! -f $i ] && continue

# Don't run [KS]??foo.{rpmsave,rpmorig} scripts
[ "${i%.rpmsave}" != "${i}" ] && continue
[ "${i%.rpmorig}" != "${i}" ] && continue
[ "${i%.rpmnew}" != "${i}" ] && continue

# Check if the subsystem is already up.
subsys=${i#/etc/rc$runlevel.d/K??}
[ ! -f /var/lock/subsys/$subsys ] && \
[ ! -f /var/lock/subsys/${subsys}.init ] && continue

# Bring the subsystem down.
if egrep -q "(killproc |action )" $i ; then
$i stop
else
action $"Stopping $subsys: " $i stop
fi
done

# Now run the START scripts.
for i in /etc/rc$runlevel.d/S*; do
# Check if the script is there.
[ ! -f $i ] && continue

# Don't run [KS]??foo.{rpmsave,rpmorig} scripts
[ "${i%.rpmsave}" != "${i}" ] && continue
[ "${i%.rpmorig}" != "${i}" ] && continue
[ "${i%.rpmnew}" != "${i}" ] && continue

# Check if the subsystem is already up.
subsys=${i#/etc/rc$runlevel.d/S??}
[ -f /var/lock/subsys/$subsys ] | | \
[ -f /var/lock/subsys/${subsys}.init ] && continue

# If we're in confirmation mode, get user confirmation
[ -n "$CONFIRM" ] &&
{
confirm $subsys
case $? in
0)
:
;;
2)
CONFIRM=
;;
*)
continue
;;
esac
}

# Bring the subsystem up.
if egrep -q "(daemon |action )" $i ; then
$i start
else
if [ "$subsys" = "halt" -o "$subsys" = "reboot" -o "$subsys" = "single" -o "$subsys" = "local" ]; then
if [ "$subsys" = "halt" -o "$subsys" = "reboot" ]; then
unset LANG
unset LC_ALL
unset TEXTDOMAIN
unset TEXTDOMAINDIR
exec $i start
fi
$i start
else
action $"Starting $subsys: " $i start
fi
fi
done
fi

As you can see, $runlevel never changes between killing and starting the scipts. If you look in this script before what I've quoted, you'll see that just before these loops, $runlevel gets set to rc's first argument. $previous is only used to test for an initial boot-up. Weird, huh?

But that isn't my question. I can't figure out how gdm gets killed, because I can't find anything in rc3 or rc5's kill scripts that would kill a desktop manager. Also, since gdm gets run straight out of inittab with the line x:5:respawn:/etc/X11/prefdm -nodaemon, it isn't a child of anything the kill scripts kill. Right?

That's why I started doubting what I thought I knew. I was wondering if init does more to kill processes than just run the kill scripts. Those quotations from the init and inittab man pages seem to suggest it does, although I've never read anything like that elsewhere.

So my big question is, how is gdm getting killed? If it's by a kill script, which one is doing it? I can't find any likely suspects. Or if it's by init directly, what exactly are the rules for what gets killed?

Paul
~{:-)

P.S. Sorry if this email is terse. The first version disappeared when I hit <esc> instead of my feather. Arg!

P.P.S. But I'm even sorrier about that source code! I can't seem to get it to indent....

[This message has been edited by pjungwirth (edited 08-13-2001).]

[This message has been edited by pjungwirth (edited 08-13-2001).]

[Ghost_Hacker]

If anyone can find any flaws or wishes to add more details please do so
I don't think I forgot anything, but you never know http://www.PCGuide.com/ubb/smile.gif


I also tried this experiment. In runlevel 3, I ran vi in the background. When I switched to runlevel 5, I could still see it with ps -e | grep vi. If I'm reading the man page correctly, shouldn't vi have been killed?

If I run vi in the background in runlevel 5 and telinit to 3, then vi gets killed. At first I thought this was just a side effect of its parent X-window getting killed, but shouldn't running something in the background prevent that? Don't background processes ignore SIGHUP signals?

In the first case outlined above, when Bash dies VI is detached from it's process group by Bash. When this happens init can't kill it, init has problems killing a process that has changed it group. It assumes that they are still in the original group that spawned them.

Here’s a tidbit from man page for telinit (http://man.he.net/man8/telinit) to explain that:

Note that init assumes that all these
processes (and their descendants) remain in the same pro-
cess group which init originally created for them. If any
process changes its process group affiliation it will not
receive these signals. Such processes need to be termi-
nated separately.


In the second case Init sends the warning SIGTERM to all processes that are undefinded in the new run level. After a few seconds it sends a SIGKILL to all undefinded processes killing them. In this case xterm and not Bash is the parent process and VI doesn't get detached from the group that spawned it.

I was wondering if init does more to kill processes than just run the kill scripts. Those quotations from the init and inittab man pages seem to suggest it does, although I've never read anything like that elsewhere.

So my big question is, how is gdm getting killed? If it's by a kill script, which one is doing it? I can't find any likely suspects. Or if it's by init directly, what exactly are the rules for what gets killed?

Your right it does do more than just run scripts to kill processes. Init also sends out SIGTERM and SIGKILL to terminate processes not killed by kill scripts and not defined in the new run level. Kill scripts are only used when processes must be killed in an orderly fashion.


Hope this helps http://www.PCGuide.com/ubb/smile.gif


------------------
Comment heard from a Klingon programmer.

"Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!"



[This message has been edited by Ghost_Hacker (edited 08-16-2001).]

[pjungwirth]

Thanks for the reply! I really appreciate your helping me figure this out. So the key is that as bash is dying, it puts vi in a different process group, whereas xterm doesn't do that. So when init goes looking for processes to kill, it can "find" vi-from-xterm but not vi-from-bash. Thanks!

Now I hope you don't mind me asking two more questions. :-)

First, what makes a process "defined" in a runlevel? Does init just assign a runlevel attribute to everything it spawns from inittab and then, on a change, trace through the tree of resultant processes killing things?

Second, when does init do this? Before or after it processes the inittab file? . . . Ah! . . . I'm guessing after, so kill scripts have a chance to run, right? Yes, and *that's* why init runs rc as *wait*! Okay, before I was thinking that init would kill everything before the kill scripts could run, but that's not necessarily the case. Okay, it's starting to make sense. . . .

So is my guess at question #1 correct? Then everything would make sense. Even losing gdm on a 5->3 switch but not your shell on a 3->5 switch would make sense, because gdm comes from this line:

x:5:respawn:/etc/X11/prefdm -nodaemon

while your shell comes from this line:

1:2345:repawn:/sbin/mingetty tty1

which is defined for *both* runlevels. Ah ha! (Actually, that would also explain why vi hangs around on a 3->5 switch; bash isn't getting killed in the first place.)

Ah, thank you so much for your help!


But what do you think of that crazy Red Hat rc script? It's not nearly as sophisticated as you or my sys admin book say it should be. When I get to work tomorrow, I'm going to see how the Solaris 8 rc does things.

Thanks again,

Paul
~{:-)

[Ghost_Hacker]

Actually, that would also explain why vi hangs around on a 3->5 switch; bash isn't getting killed in the first place.


Hey,your right!! When I tried the same experment with VI that you did. Once I'm in the GUI and, using CTRL+ALT+F1,switch to tty1. There's VI running just fine.


But what do you think of that crazy Red Hat rc script? It's not nearly as sophisticated as you or my sys admin book say it should be.


Yep..doesn't seem to be, but reading too many scripts gives me a headache. http://www.PCGuide.com/ubb/biggrin.gif




------------------
Comment heard from a Klingon programmer.

"Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!"