If you want details about how storage devices are performing on Redhat/Centos/Fedora use the vmstat and iostat commands.
After installing Centos 5.3 the iostat command is not available. To install it use yum:
# yum install sysstat
Occasionally as a Linux administrator you will be in the situation where working on a remote server and you are left with no option but to force a reboot the system. This may be for a number of reasons, but where I have found it most frequent is when working on Linux clusters in a remote location.
When the "reboot" or "shutdown" commands are executed daemons are gracefully stopped and storage volumes unmounted.
This is usually accomplished via scripts in the /etc/init.d directory which will wait for each daemon to shut down gracefully before proceeding on to the next one. This is where a situation can develop where your Linux server fails to shutdown cleanly leaving you unable to administer the system until it is inspected locally. This is obviously not ideal so the answer is to force a reboot on the system where you can guarantee that the system will power cycle and come back up. The method will not unmount file systems nor sync delayed disk writes, so use this at your own discretion.
To force the kernel to reboot the system we will be making use of the magic SysRq key.
The magic_SysRq_key provides a means to send low level instructions directly to the kernel via the /proc virtual file system.
To enable the use of the magic SysRq option type the following at the command prompt:
echo 1 > /proc/sys/kernel/sysrq
Then to reboot the machine simply enter the following:
echo b > /proc/sysrq-trigger
Voilà! Your system will instantly reboot.
{linkr:related;keywords:linux;limit:5;title:Related Articles}
{linkr:bookmarks;size:small;text:nn;separator:%20;badges:2,1,18,13,19,15,17,12}
After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).
At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:
# drbdadm secondary resource
# drbdadm disconnect resource
# drbdadm -- --discard-my-data connect resource
On the other node (the split brain survivor), if its connection state is also StandAlone, you would enter:
# drbdadm connect resource
You may omit this step if the node is already in the WFConnection state; it will then reconnect automatically.
If all else fails and the machines are still in a split-brain condition then on the secondary (backup) machine issue:
drbdadm invalidate resource
After an extended period of intense software development, we are pleased to announce the release of Recital 10 which is a milestone in our development efforts.
The Recital 10 release notes can be found here.
- Recital
A powerful scripting language with an embedded database used for developing desktop database applications on Linux and Unix.
- Recital Server
A cross-platform SQL database and application server.
- Recital Web
A server-side scripting language with an embedded SQL database for creating web 2.0 web applications.
$ lsof | grep db.exe | grep accounts db.exe 16897 john 6uw REG 253,0 20012 3413872 /usr/recital100/qa/accounts.dbf db.exe 16897 john 7u REG 253,0 4176 3413885 /usr/recital100/qa/accounts.dbxIf you want to check for locks you can use lslk, for example;
$ lslk | grep db.exe | grep accounts db.exe 16897 253,0 3413872 20012 w 0 0 0 12319 0 /usr/recital100/qa/accounts.dbfIf you don't have lslk installed you can install it with one of the updaters, for example on redhat linux:
$ yum update lslk
Unfortunately java does not support __FILE__ and __LINE__ but you can get the same functionality with this code which can be placed in one of your libraries.
public static void showTrace(String msg)
{
if (msg.length() > 0) System.out.println(msg);
System.out.println("Trace: " +
"file " + new Throwable().getStackTrace()[1].getFileName() +
" class " + new Throwable().getStackTrace()[1].getClassName() +
" method " + new Throwable().getStackTrace()[1].getMethodName() +
" line " + new Throwable().getStackTrace()[1].getLineNumber());
}
If you have software packages which you wish to share with others or simply between your own personal machines, a neat and easy solution is to create your own YUM repository and provide your .repo file for download.
YUM is by far the easiest method of installing software on Red hat, Centos and Fedora. Not only does it mean you don't need to trawl the web looking for somewhere to download the packages, YUM does a great job of satisfying any package dependencies. As long as the required packages are available in the enabled repositories on your system, YUM will go out and get everything you need.
To create your own YUM repository, you will need to install the yum-utils and createrepo packages:
yum install yum-utils createrepo
yum-utils contains the tools you will need to manage your soon to be created repository, and createrepo is used to create the xml based rpm metadata you will require for your repository.
Once you have installed these required tools, create a directory in your chosen web server's document root e.g:
mkdir -p /var/www/html/repo/recital/updates
Copy the rpm's you wish to host into this newly created directory.
The next step is to create the xml based rpm metadata. To create this use the createrepo program we installed earlier.
At the shell type the following command:
createrepo -v -s md5 /var/www/html/repo/recital/updates
This will create the required metadata in the repodata directory of your /var/www/html/repo/recital/updates directory.
root@test repodata]# ls -l rwotal 44 -rw-r--r-- 1 root root 28996 Jan 13 21:42 filelists.xml.gz -rw-r--r-- 1 root root 284 Jan 13 21:42 other.xml.gz -rw-r--r-- 1 root root 1082 Jan 13 21:42 primary.xml.gz -rw-r--r-- 1 root root 951 Jan 13 21:42 repomd.xml
To do a final consistency check on your repository run the following command:
verifytree /var/www/html/repo/recital/updates
We now have a fully functioning YUM repository for our hosted rpm packages.
The next process is to create a .repo file in the client systems /etc/yum.repos.d directory.
Navigate to the /etc/yum.repos.d directory on your system as root.
Using your preferred text editor to create the .repo file. In this example I will call it recital.repo.
Now paste in the following lines:
[Recital] name=Recital Update Server baseurl=http://ftp.recitalsoftware.com/repo/recital/updates enabled=1 gpgcheck=1
Once that is saved, at the shell prompt on the same machine (YUM client system).
$ yum repolist Loaded plugins: presto, refresh-packagekit repo id repo name status Recital Recital Update Server enabled: 1 adobe-linux-i386 Adobe Systems Incorporated enabled: 17 fedora Fedora 12 - i386 enabled: 15,366
As you can see the Recital repo is now being picked up and we have access to all the packages it is hosting.
See how easy that was!
Platforms supported
- Intel® / AMD™ 32 bit Linux
- Intel® / AMD™ 64 bit Linux
- HP PA-RISC HP-UX® 10.20 and above
- Sun® SPARC Solaris™ 8 and above
- HP Alpha OpenVMS 7.2-1 and above
- SCO® OpenServer 5.0.5 and above
- Sun® Intel® Solaris™ 10 and above
- IBM AIX® 4.3 and above
- HP Integrity OpenVMS 8.2-1 and above
- HP Intel® Itanium® HP-UX® 11.23 and above
- Mac OS X leopard 10.5 and above
Large File Support is available for Windows, Itanium HP-UX and Linux.