This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi folks, I was trying to work out how to get Linux Redhat 7.3 to start Apache when it boots. I was looking at the MySQL commands in the mysql file in /etc/rc/init.d but it seems really complex - the comments said it was linked to other files in rc0.d and rc3.d etc etc. Is there a simple way of getting Linux to execute "apachectl start" when I boot? Thanks Adam
I have seen things you people would not believe, attack ships on fire off the shoulder of Orion, c-beams sparkling in the dark near the Tennhauser Gate. All these moments will be lost in time, like tears in the rain.
Call it S50apache and put it in /etc/rc3.d. Make sure the execute bit is set too. There's a problem with this approach, however, which is that it only handles startup, not shutdown. A "run script" really should do both, and it really should be linked in with the init.d directory as well. It looks complex, but it's done the way it is for a reason. [ June 02, 2002: Message edited by: Michael Ernest ]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
I'm quite astonished thaat Apache is not started automatically already. All the RedHat installations I've ever done (from 3.something up to 7.2, but not, I'll admit, 7.3) have installed and started Apache out of the box. Just in case you have missed it, it's usually listed as "httpd". do a "ps -aef grep httpd" and see if yo already have one running. Check for existing entries with "httpd" in the name in init.d and rc3.d. If it isn't started by default, I can only assume you answered some installation choice which told it not to.
I might have deliberately not installed it at install time. So I should also put a shutdown script in there somewhere?
Joined: Jan 07, 1999
yes, but it's an easy trick. Just put direct links to apachectl as both S50httpd and K50httpd (choose the numbers according to the order you want the processes started up and shut down). The init system will send the appropriate "stop" and "start" arguments to it at the appropriate times. But next time, it's wise to install a web server when setting up almost any machine
The init system will send the appropriate "stop" and "start" arguments to it at the appropriate times.
One other thing: change the line in the script to /usr/apache/bin/apachectl $1 so that the script will read the parameter 'stop' or 'start' fed in by the system, and not just call the start argument whenever it's invoked. The next step in such a script is to protect it against manual use by ensuring the argument is legal, i.e.:
Now you've made sure the parameter passwd in is legal, regardless of who invokes it. And that's probably most of the script you looked at originally: defensive programming.
I'm going to have to disagree about installing redhat with the default Apache included. First I *hate* the default layout. Next it NEVER gives me all of the mods I need installed. And finally (and prehaps the most important) there is almost always a newer verison available on the apache website. Use the latest and greatest unless you have an overriding reason not to. It'll have the most up to date security packages. Also its not that hard to set up the startup scripts. KDE even has a nice gui tool to do it. (I don't run KDE so I don't know the name sorry - but I have seen my co workers use it). do a man on chkconfig and you see how to turn services on and off during runlevels (you will have to put the script together first).
If you installed Apache from the RPM, there should be a file named /etc/init.d/httpd, which is the Apache server control script. It can be used manually (/sbin/service httpd <start/stop/restart> ) but it is also the reference script for the runlevels. You can tie Apache to one or more runlevels via the "control-panel" GUI application or on the command-line via /sbin/chkconfig. I prefer the command line, since you can set multiple runlevels at once; using the control-panel program you have to manually set the start and stop for each runlevel. Which is somewhat more error-prone and a lot more tedious. It's also worth noting that if you install Tomcat via RPM, an /etc/init.d script is installed to bring up Tomcat. It will be named /etc/init.d/tomcatX <= X=3 for tomcat3, X=4 for tomcat4 (Catalina). A control script may contain special comments to be used by chkconfig and the control-panel. Most notable is the start/stop priority level, but there are others as well, which are documented if you look hard enough. [ June 05, 2002: Message edited by: Tim Holloway ] [ June 05, 2002: Message edited by: Tim Holloway ]
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Oct 09, 2001
Why does RedHat put different files of an app in different parts of the system? The only reason I can think of is to put all the files that are edited alot on a seperate drive to allow quicker defragging - but I'm not sure if defragging is an issue on linux file systems.
Do you mean the deal where they create multiple disk partitions when you install (yuck!). Or are you referring to how an RPM places files in various parts of the filesystem instead of all in a place like /usr/local/app_xxxx? For the first one, I think they were trying to be "helpful" (they're not, They make the root partition - which holds /tmp WAY too small!). In the second one, they actually are, since it puts the executables into system path, library, config, etc. directories instead of requiring a long list of directories in the the path, chasing all over the drive to locate (and back up!!!) config files, etc. Obviously, as anyone who's supported Windows apps knows, having an app splatter files all over the disk - and in THEIR case, the Windows Registry can quickly lead to chaos. Fortunately, when you install an app via RPM, there's a way to track such things: rpm -ql myapp to list "all" files installed via RPM for that app. rpm -V myapp to verify that the files are there and haven't been tampered with. It only prints something if the verification fails, BTW. I quoted "all" because the RPM install process can run scripts so any files created by a script and not registered in the RPM database won't be listed, but it's more than you'll get as a user from InstallShield.