The Apache HTTP server is installed by default in all Linux distributions and it is configured to run as service. I usually prefer to install Apache from source instead of using the default one. After installing Apache I want to run that instance as service so that it can be restarted automatically whenever machine is rebooted. This can be achieved easily by modifying /etc/rc.d/init.d/httpd file, which is configured to run the Apache installed with OS.
Comment the following section, though it is not required but I prefer to keep all configuration at one place
if [ -f /etc/sysconfig/httpd ]; then
. /etc/sysconfig/httpd
fi
Modify the following lines-
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
to point towards your Apache installation
apachectl=/opt/apps/httpd-2.2.14/bin/apachectl
httpd=${HTTPD-/opt/apps/httpd-2.2.14/bin/httpd}
prog=httpd
pidfile=${PIDFILE-/opt/apps/httpd-2.2.14/logs/httpd.pid}
Now your custom Apache instance will be started by OS instead of the default one.
Saturday, December 26, 2009
Wednesday, December 16, 2009
Cron: Understanding crontab deeply?
A crontab file contains instructions to the cron daemon of the general
form: `run this command at this time on this date'. Each user has
their own crontab, and commands in any given crontab will be executed as
the user who owns the crontab. Uucp and News will usually have their own
crontabs, eliminating the need for explicitly running su as part of a
cron command.
Blank lines and leading spaces and tabs are ignored. Lines whose first
non-space character is a pound-sign (#) are comments, and are ignored.
Note that comments are not allowed on the same line as cron commands,
since they will be taken to be part of the command. Similarly, comments
are not allowed on the same line as environment variable settings.
An active line in a crontab will be either an environment setting or a
cron command. An environment setting is of the form,
name = value
where the spaces around the equal-sign (=) are optional, and any subse-
quent non-leading spaces in value will be part of the value assigned to
name. The value string may be placed in quotes (single or double, but
matching) to preserve leading or trailing blanks. The name string may
also be placed in quote (single or double, but matching) to preserve
leading, traling or inner blanks.
Several environment variables are set up automatically by the cron
daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
/etc/passwd line of the crontab's owner. HOME and SHELL may be overrid-
den by settings in the crontab; LOGNAME may not.
(Another note: the LOGNAME variable is sometimes called USER on BSD sys-
tems... on these systems, USER will be set also).
In addition to LOGNAME, HOME, and SHELL, cron will look at MAILTO if
it has any reason to send mail as a result of running commands in
`this' crontab. If MAILTO is defined (and non-empty), mail is sent to
the user so named. If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. Otherwise mail is sent to the owner of the crontab. This
option is useful if you decide on /bin/mail instead of /usr/lib/sendmail
as your mailer when you install cron -- /bin/mail doesn't do aliasing,
and UUCP usually doesn't read its mail.
The format of a cron command is very much the V7 standard, with a number
of upward-compatible extensions. Each line has five time and date
fields, followed by a user name (with optional `:' and
`/' suffixes) if this is the system crontab file, followed
by a command. Commands are executed by cron when the minute, hour,
and month of year fields match the current time, and when at least one of
the two day fields (day of month, or day of week) match the current time
(see `Note' below). cron examines cron entries once every minute.
The time and date fields are:
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for `first-last'.
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. For example, 8-11 for an
``hours'' entry specifies execution at hours 8, 9, 10 and 11.
Lists are allowed. A list is a set of numbers (or ranges) separated by
commas. Examples: `1,2,5,9', `0-4,8-12'.
Step values can be used in conjunction with ranges. Following a range
with `/' specifies skips of the number's value through the
range. For example, `0-23/2' can be used in the hours field to specify
command execution every other hour (the alternative in the V7 standard is
`0,2,4,6,8,10,12,14,16,18,20,22'). Steps are also permitted after an
asterisk, so if you want to say `every two hours', just use `*/2'.
Names can also be used for the `month' and `day of week' fields. Use
the first three letters of the particular day or month (case doesn't mat-
ter). Ranges or lists of names are not allowed.
The `sixth' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or % char-
acter, will be executed by /bin/sh or by the shell specified in the SHELL
variable of the cronfile. Percent-signs (%) in the command, unless
escaped with backslash (\), will be changed into newline characters, and
all data after the first % will be sent to the command as standard input.
The command can optionally be prefixed by `@AppleNotOnBattery ' to tell
cron not to run the command when functioning on battery power. For exam-
ple, the `sixth' field when using this option would appear something
like `@AppleNotOnBattery /usr/bin/touch /tmp/foo'
Note: The day of a command's execution can be specified by two fields --
day of month, and day of week. If both fields are restricted (ie, aren't
*), the command will be run when either field matches the current time.
For example, `30 4 1,15 * 5' would cause a command to be run at 4:30 am
on the 1st and 15th of each month, plus every Friday.
Instead of the first five fields, one of eight special strings may
appear:
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
@annually (sames as @yearly)
@monthly Run once a month, "0 0 1 * *".
@weekly Run once a week, "0 0 * * 0".
@daily Run once a day, "0 0 * * *".
@midnight (same as @daily)
@hourly Run once an hour, "0 * * * *".
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
#
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
#
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
#
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
Notes
When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and ATT seem to disagree about this.
Lists and ranges are allowed to co-exist in the same field. "1-3,7-9" would be rejected by ATT or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.
Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".
Names of months or days of the week can be specified by name. Environment variables can be set in the crontab. In BSD or ATT, the environment handed to child processes is basically the one from /etc/rc.
Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a person other than the crontab owner (SysV can't do this), or the feature can be turned off and no mail will be sent at all (SysV can't do this either).
All of the `@' commands that can appear in place of the first five fields are extensions.
If you're in one of the 70-odd countries that observe Daylight Savings Time, jobs scheduled during the rollback or advance will be affected. In general, it's not a good idea to schedule jobs during this period.
"Wisdom is the power to put our time and our knowledge to the proper use" - Thomas J. Watson
form: `run this command at this time on this date'. Each user has
their own crontab, and commands in any given crontab will be executed as
the user who owns the crontab. Uucp and News will usually have their own
crontabs, eliminating the need for explicitly running su as part of a
cron command.
Blank lines and leading spaces and tabs are ignored. Lines whose first
non-space character is a pound-sign (#) are comments, and are ignored.
Note that comments are not allowed on the same line as cron commands,
since they will be taken to be part of the command. Similarly, comments
are not allowed on the same line as environment variable settings.
An active line in a crontab will be either an environment setting or a
cron command. An environment setting is of the form,
name = value
where the spaces around the equal-sign (=) are optional, and any subse-
quent non-leading spaces in value will be part of the value assigned to
name. The value string may be placed in quotes (single or double, but
matching) to preserve leading or trailing blanks. The name string may
also be placed in quote (single or double, but matching) to preserve
leading, traling or inner blanks.
Several environment variables are set up automatically by the cron
daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
/etc/passwd line of the crontab's owner. HOME and SHELL may be overrid-
den by settings in the crontab; LOGNAME may not.
(Another note: the LOGNAME variable is sometimes called USER on BSD sys-
tems... on these systems, USER will be set also).
In addition to LOGNAME, HOME, and SHELL, cron will look at MAILTO if
it has any reason to send mail as a result of running commands in
`this' crontab. If MAILTO is defined (and non-empty), mail is sent to
the user so named. If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. Otherwise mail is sent to the owner of the crontab. This
option is useful if you decide on /bin/mail instead of /usr/lib/sendmail
as your mailer when you install cron -- /bin/mail doesn't do aliasing,
and UUCP usually doesn't read its mail.
The format of a cron command is very much the V7 standard, with a number
of upward-compatible extensions. Each line has five time and date
fields, followed by a user name (with optional `:' and
`/' suffixes) if this is the system crontab file, followed
by a command. Commands are executed by cron when the minute, hour,
and month of year fields match the current time, and when at least one of
the two day fields (day of month, or day of week) match the current time
(see `Note' below). cron examines cron entries once every minute.
The time and date fields are:
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for `first-last'.
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. For example, 8-11 for an
``hours'' entry specifies execution at hours 8, 9, 10 and 11.
Lists are allowed. A list is a set of numbers (or ranges) separated by
commas. Examples: `1,2,5,9', `0-4,8-12'.
Step values can be used in conjunction with ranges. Following a range
with `/' specifies skips of the number's value through the
range. For example, `0-23/2' can be used in the hours field to specify
command execution every other hour (the alternative in the V7 standard is
`0,2,4,6,8,10,12,14,16,18,20,22'). Steps are also permitted after an
asterisk, so if you want to say `every two hours', just use `*/2'.
Names can also be used for the `month' and `day of week' fields. Use
the first three letters of the particular day or month (case doesn't mat-
ter). Ranges or lists of names are not allowed.
The `sixth' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or % char-
acter, will be executed by /bin/sh or by the shell specified in the SHELL
variable of the cronfile. Percent-signs (%) in the command, unless
escaped with backslash (\), will be changed into newline characters, and
all data after the first % will be sent to the command as standard input.
The command can optionally be prefixed by `@AppleNotOnBattery ' to tell
cron not to run the command when functioning on battery power. For exam-
ple, the `sixth' field when using this option would appear something
like `@AppleNotOnBattery /usr/bin/touch /tmp/foo'
Note: The day of a command's execution can be specified by two fields --
day of month, and day of week. If both fields are restricted (ie, aren't
*), the command will be run when either field matches the current time.
For example, `30 4 1,15 * 5' would cause a command to be run at 4:30 am
on the 1st and 15th of each month, plus every Friday.
Instead of the first five fields, one of eight special strings may
appear:
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
@annually (sames as @yearly)
@monthly Run once a month, "0 0 1 * *".
@weekly Run once a week, "0 0 * * 0".
@daily Run once a day, "0 0 * * *".
@midnight (same as @daily)
@hourly Run once an hour, "0 * * * *".
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
#
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
#
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
#
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
Notes
When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and ATT seem to disagree about this.
Lists and ranges are allowed to co-exist in the same field. "1-3,7-9" would be rejected by ATT or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.
Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".
Names of months or days of the week can be specified by name. Environment variables can be set in the crontab. In BSD or ATT, the environment handed to child processes is basically the one from /etc/rc.
Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a person other than the crontab owner (SysV can't do this), or the feature can be turned off and no mail will be sent at all (SysV can't do this either).
All of the `@' commands that can appear in place of the first five fields are extensions.
If you're in one of the 70-odd countries that observe Daylight Savings Time, jobs scheduled during the rollback or advance will be affected. In general, it's not a good idea to schedule jobs during this period.
"Wisdom is the power to put our time and our knowledge to the proper use" - Thomas J. Watson
Monday, December 14, 2009
Tomcat: Troubleshoot the Tomcat?
Installing JDK (Java Development Kit)
In order to run Tomcat, you will need to install JDK and set the JAVA_HOME environment variable to identify the location of the JDK environment on your system. I have chosen to use JDK 5.0.
1. You can download JDK 5.0 at http://java.sun.com/j2se/1.5.0/download.jsp.
2. Click on Download JDK 5.0 Update 6 to go to the download page.
3. Click Accept to accept the license agreement.
4. Next choose the Linux self-extracting file. This is the download for the self-extracting binary file rather than the rpm.
5. Download to your preferred download directory. Change to that directory and make it executable by executing the following command:
chmod +x jdk-1_5_0_06-linux-i586.bin
6. Now execute the file:
./jdk-1_5_0_06-linux-i586.bin
7. You should now have a new directory called j2sdk1.5-sun. Now move this directory to the location where it should be run. I chose /usr/lib/.
mv j2sdk1.5-sun /usr/lib
8. Now create a symbolic link called jdk to JAVA_HOME by the following command. This allows you to easily switch back and forth between different jvms should you ever need to
cd /usr/lib
ln -s j2sdk1.5-sun jdk
8. Now we need to set the JAVA_HOME environment variable. Add the following at the end of /etc/profile just after export PATH.
JAVA_HOME="/usr/lib/jdk"
export JAVA_HOME
/etc/profile is executed at startup and when a user logs into the system. In order to update the environment you will need to log out and log back in to the system.
10. Check to make sure JAVA_HOME is defined correctly by executing the command below. This should report the location of the Java SDK which should be /usr/lib/jdk.
echo $JAVA_HOME
11. Now test Java with the following command. You should be returned with /usr/bin/java. If so, you have successfully completed this section.
which java
export JAVA_HOME=/usr/java/jdk1.6.0_15
export PATH=$PATH:$HOME/bin:/bin:/usr/local/bin:/usr/bin:/usr/java/jdk1.6.0_15/bin/
Setting Tomcat
Download the binary version to your preferred download directory from here: http://tomcat.apache.org/download-55.cgi. Choose the tar.gz from the core section for 5.5.15.
Now change to that directory and extract the files using the following command:
cd /mydownloads (be sure to change to your download directory)
tar xvzf apache-tomcat-5.5.15.tar.gz
You should now have a new directory called apache-tomcat-5.5.15. Now move this directory to the location where it should be installed. Again, I chose /usr/lib/. Note that this location will be referred to as CATALINA_HOME in the Tomcat documentation.
mv apache-tomcat-5.5.15 /usr/lib
Next change to the /usr/lib/ directory.
cd /usr/lib
Now create a symbolic link called apache-tomcat to CATALINA_HOME by the following command.
ln -s apache-tomcat-5.5.15 apache-tomcat
[root@linuxguy bin]# echo $CATALINA_HOME
/usr/lib/apache-tomcat
[root@linuxguy bin]# pwd
/usr/lib/apache-tomcat/bin
[root@linuxguy bin]# ./startup.sh
The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this program
How to troubleshoot?
[root@linuxguy bin]# chmod +x *.sh
[root@linuxguy bin]# ./startup.sh
Using CATALINA_BASE: /usr/lib/apache-tomcat
Using CATALINA_HOME: /usr/lib/apache-tomcat
Using CATALINA_TMPDIR: /usr/lib/apache-tomcat/temp
Using JRE_HOME: /usr/java/jdk1.6.0_15
Using CLASSPATH: /usr/lib/apache-tomcat/bin/bootstrap.jar
[root@linuxguy bin]#
[root@linuxguy bin]#
In order to run Tomcat, you will need to install JDK and set the JAVA_HOME environment variable to identify the location of the JDK environment on your system. I have chosen to use JDK 5.0.
1. You can download JDK 5.0 at http://java.sun.com/j2se/1.5.0/download.jsp.
2. Click on Download JDK 5.0 Update 6 to go to the download page.
3. Click Accept to accept the license agreement.
4. Next choose the Linux self-extracting file. This is the download for the self-extracting binary file rather than the rpm.
5. Download to your preferred download directory. Change to that directory and make it executable by executing the following command:
chmod +x jdk-1_5_0_06-linux-i586.bin
6. Now execute the file:
./jdk-1_5_0_06-linux-i586.bin
7. You should now have a new directory called j2sdk1.5-sun. Now move this directory to the location where it should be run. I chose /usr/lib/.
mv j2sdk1.5-sun /usr/lib
8. Now create a symbolic link called jdk to JAVA_HOME by the following command. This allows you to easily switch back and forth between different jvms should you ever need to
cd /usr/lib
ln -s j2sdk1.5-sun jdk
8. Now we need to set the JAVA_HOME environment variable. Add the following at the end of /etc/profile just after export PATH.
JAVA_HOME="/usr/lib/jdk"
export JAVA_HOME
/etc/profile is executed at startup and when a user logs into the system. In order to update the environment you will need to log out and log back in to the system.
10. Check to make sure JAVA_HOME is defined correctly by executing the command below. This should report the location of the Java SDK which should be /usr/lib/jdk.
echo $JAVA_HOME
11. Now test Java with the following command. You should be returned with /usr/bin/java. If so, you have successfully completed this section.
which java
export JAVA_HOME=/usr/java/jdk1.6.0_15
export PATH=$PATH:$HOME/bin:/bin:/usr/local/bin:/usr/bin:/usr/java/jdk1.6.0_15/bin/
Setting Tomcat
Download the binary version to your preferred download directory from here: http://tomcat.apache.org/download-55.cgi. Choose the tar.gz from the core section for 5.5.15.
Now change to that directory and extract the files using the following command:
cd /mydownloads (be sure to change to your download directory)
tar xvzf apache-tomcat-5.5.15.tar.gz
You should now have a new directory called apache-tomcat-5.5.15. Now move this directory to the location where it should be installed. Again, I chose /usr/lib/. Note that this location will be referred to as CATALINA_HOME in the Tomcat documentation.
mv apache-tomcat-5.5.15 /usr/lib
Next change to the /usr/lib/ directory.
cd /usr/lib
Now create a symbolic link called apache-tomcat to CATALINA_HOME by the following command.
ln -s apache-tomcat-5.5.15 apache-tomcat
[root@linuxguy bin]# echo $CATALINA_HOME
/usr/lib/apache-tomcat
[root@linuxguy bin]# pwd
/usr/lib/apache-tomcat/bin
[root@linuxguy bin]# ./startup.sh
The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this program
How to troubleshoot?
[root@linuxguy bin]# chmod +x *.sh
[root@linuxguy bin]# ./startup.sh
Using CATALINA_BASE: /usr/lib/apache-tomcat
Using CATALINA_HOME: /usr/lib/apache-tomcat
Using CATALINA_TMPDIR: /usr/lib/apache-tomcat/temp
Using JRE_HOME: /usr/java/jdk1.6.0_15
Using CLASSPATH: /usr/lib/apache-tomcat/bin/bootstrap.jar
[root@linuxguy bin]#
[root@linuxguy bin]#
Sunday, December 6, 2009
JBoss: Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
If you launched JBoss from the command line, the easiest way to stop it is to press ctrl-C. JBoss should begin it's shutdown. Alternatively, you can invoke the shutdown script in the JBoss bin directory.
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -S
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
There're several ways to shutdown JBoss as explained below. If you want to know what JBoss logs in each situation please visit ShutdownLogs wiki.
Stopping JBoss on a remote machine
Note that you will use the lower-case -s flag along with the jnp protocol plus address and port of the Naming service specified in conf/jboss-service.xml
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://myremotemachineOrIP:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
service-bindings
server name="ports-default"
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1098
/delegate-config>
binding port="1099" host="${jboss.bind.address}">
/service-config>
.
.
.
server name="ports-01">
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
>
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1198
/delegate-config>
binding port="1199" host="${jboss.bind.address}">
/service-config>
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1199
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -S
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
There're several ways to shutdown JBoss as explained below. If you want to know what JBoss logs in each situation please visit ShutdownLogs wiki.
Stopping JBoss on a remote machine
Note that you will use the lower-case -s flag along with the jnp protocol plus address and port of the Naming service specified in conf/jboss-service.xml
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://myremotemachineOrIP:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
service-bindings
server name="ports-default"
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1098
/delegate-config>
binding port="1099" host="${jboss.bind.address}">
/service-config>
.
.
.
server name="ports-01">
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
>
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1198
/delegate-config>
binding port="1199" host="${jboss.bind.address}">
/service-config>
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1199
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
JBoss: A Boot-up Script for Jboss Start $ Shutdown
The Content of this site is moved to new location.
Saturday, December 5, 2009
LinuxInterview: How to make script run as service?
Making a script run at boot time needs certain consideration and configuration.The Startup script are usually under /etc/init.d directory.
Some Admin think that by just putting the script under /etc/init.d will make it run as service.
No !! The Story is little different.
Say, I have a script called myscript which I want to run as service either:
/etc/init.d/myscript [restart|reload|start|stop]
or
service myscript start
But little more steps are usually needed.
I am talking about Red Hat Distribution but may run comfortably in other *nix too.
I have a script called myscript which contains:
#cat myscript
#!/bin/sh
service nfs stop
Being a Linux Admin, I will try to put it under /etc/init.d/ directory.
Try to run it as:
service myscript start
And It does run comfortably:
#service myscript start
Shutting down NFS mountd: [ OK ]
Shutting down NFS daemon: [ OK ]
Shutting down NFS services:
But when I try making this service run at boot time:
#chkconfig myscript on
service myscript does not support chkconfig
Hmm...Not working !!!
How to fix it????
So here is the complete solution:
(Assume the name of my script is myscript)
1 - Copy your script into /etc/init.d folder
2 - cd /etc/init.d
3 - chmod +x myscript
4 - Add these lines, including #, right after #!/bin/bash or #!/bin/sh:
# chkconfig: 2345 95 20
# description: Some description
# What your script does (not sure if this is necessary though)
# processname: myscript
5 - chkconfig –level 2345 myscript on
Try now !!!
It will work.
Some Admin think that by just putting the script under /etc/init.d will make it run as service.
No !! The Story is little different.
Say, I have a script called myscript which I want to run as service either:
/etc/init.d/myscript [restart|reload|start|stop]
or
service myscript start
But little more steps are usually needed.
I am talking about Red Hat Distribution but may run comfortably in other *nix too.
I have a script called myscript which contains:
#cat myscript
#!/bin/sh
service nfs stop
Being a Linux Admin, I will try to put it under /etc/init.d/ directory.
Try to run it as:
service myscript start
And It does run comfortably:
#service myscript start
Shutting down NFS mountd: [ OK ]
Shutting down NFS daemon: [ OK ]
Shutting down NFS services:
But when I try making this service run at boot time:
#chkconfig myscript on
service myscript does not support chkconfig
Hmm...Not working !!!
How to fix it????
So here is the complete solution:
(Assume the name of my script is myscript)
1 - Copy your script into /etc/init.d folder
2 - cd /etc/init.d
3 - chmod +x myscript
4 - Add these lines, including #, right after #!/bin/bash or #!/bin/sh:
# chkconfig: 2345 95 20
# description: Some description
# What your script does (not sure if this is necessary though)
# processname: myscript
5 - chkconfig –level 2345 myscript on
Try now !!!
It will work.
LinuxInterview: Difference between Hard Link and Soft Link? - Creative Understanding
There's an enormous difference, actually. There's really no such thing as a "hard link". If anything, there is an action that you can call "creating a hard link".
The thing is, a file can have several names. If you create a hard link (by running `ln' without `-s'), you simply create a new name which points to the exact same file as the original name. For example, if you run the following commands:
Code:
cd /tmp
echo test >file1
ln file1 file2
Then you will have two filenames, /tmp/file1 and /tmp/file2, which both point to the same actual file. Notice the important distinction between a file and its name(s): A name knows which file it points to, but a file doesn't know what name(s) it has.
The reason that I say that there's no such thing as a hard link is because the names file1 and file2 are equivalent. There's no "original" name. You can in no way tell that "file2 is a hard link to file1", or the opposite, or anything evem similar -- they are simply two different names for the same file.
An interesting implication of this is that the `rm' command doesn't actually remove files. Instead, it only removes filenames (the system call that it uses is called `unlink', not `remove' or `delete'). The actual file is only automatically deleted by the system when it has no more names. Thus, if you delete file1, file2 will still points to the same file, and conversely, if you delete file2, file1 will still be pointing to the same file.
A symlink, on the other hand, is a file in its own right. It contains the filename of the file that it points to. If file2 were a symlink to file1, and you deleted file1, the file2 symlink would be "broken" (since the filename that it points to no longer exists). In this case, file1 is the name of the actual, original file, and file2 is just a symlink that points to it by name.
For bonus points: What would be the difference in output from the cat command in the following two sequences of commands, and why?
Sequence 1:
Code:
cd /tmp
echo 1 >file1
ln file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Sequence 2:
Code:
cd /tmp
echo 1 >file1
ln -s file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
The thing is, a file can have several names. If you create a hard link (by running `ln' without `-s'), you simply create a new name which points to the exact same file as the original name. For example, if you run the following commands:
Code:
cd /tmp
echo test >file1
ln file1 file2
Then you will have two filenames, /tmp/file1 and /tmp/file2, which both point to the same actual file. Notice the important distinction between a file and its name(s): A name knows which file it points to, but a file doesn't know what name(s) it has.
The reason that I say that there's no such thing as a hard link is because the names file1 and file2 are equivalent. There's no "original" name. You can in no way tell that "file2 is a hard link to file1", or the opposite, or anything evem similar -- they are simply two different names for the same file.
An interesting implication of this is that the `rm' command doesn't actually remove files. Instead, it only removes filenames (the system call that it uses is called `unlink', not `remove' or `delete'). The actual file is only automatically deleted by the system when it has no more names. Thus, if you delete file1, file2 will still points to the same file, and conversely, if you delete file2, file1 will still be pointing to the same file.
A symlink, on the other hand, is a file in its own right. It contains the filename of the file that it points to. If file2 were a symlink to file1, and you deleted file1, the file2 symlink would be "broken" (since the filename that it points to no longer exists). In this case, file1 is the name of the actual, original file, and file2 is just a symlink that points to it by name.
For bonus points: What would be the difference in output from the cat command in the following two sequences of commands, and why?
Sequence 1:
Code:
cd /tmp
echo 1 >file1
ln file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Sequence 2:
Code:
cd /tmp
echo 1 >file1
ln -s file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Subscribe to:
Posts (Atom)