Sunucu yönetim tarafındaki bu seferki sorunumuz mysql ‘in pid-file hatası ile ilgili

Bu hata benim 15dakikamı zehir etti fakat en sonunda problemin üstesinden geldim. Hatamız bir arkadaşımın vz vps müşterisinin karşılaştığı bir hata idi. Arkadaşım üstesinden gelemediği için birde ben bakmak istedim. Problem için gerekli my.cnf ayarlarını yaparak service mysql restart komutunu uyguladım fakat mysql bir türlü pid dosyası üzerinde işlem yapamamaktaydı bu nedenden dolayı kendisini başlatamadı. Ondan sonra birçok kez cpanel’in /script/ dizini altındaki perl scriptler yardımıyla sorunu çözmek için yola koyuldum fakat cpanel bu konuda bana pek yardımcı olacağa benzemiyordu:)

Daha önceden karşılaştığım bir hata aklıma gelerek mysql kullanıcısına ait tabloların onarma ihtiyacı duyacağını hissettim. ve aşağıdaki komutları uygulayarak bu sorunun üstesinden geldim.

cd /var/lib/mysql/mysql
myisamchk -r *.MYI

ve sql’imiz özlediğimiz açılışını bize gösterdi:)

root@server [~]# service mysql restart
Shutting down MySQL. SUCCESS!
Starting MySQL. SUCCESS!
root@server [~]#

İyi Günler
Yazan: Gökhan Bozbuğa

Linux plesk php version update işleminde sorun yaşayan arkadaşlar için kısa bir yol söyleyeceğim. Sorunsuz bir şekilde artık php versionlarınızı update edebilirsiniz.

Komutlar sırayla:
wget -q -O – http://www.atomicorp.com/installers/atomic.sh |sh
yum update php
yum install php-soap
yum install php-json
/usr/local/psa/admin/sbin/websrvmng -a
/etc/init.d/httpd reload

Kurulum bittikten sonra php -v komutu ile güncel php versiyonunuzu görebilirsiniz. Eğerki daha önceden kullandığınız ioncube gibi eklentileri 5.1 ve önceki sürümlere ait ise bunu php.ini dosyanızdan yeni php sürümünüze göre değiştirmeniz gerekecektir.

Kolay Gelsin:)
Yazan: Gökhan Bozbuğa

Geçen gün esx server’da karşılaştığım I/O hatasından bahsedeceğim. IBM System x3650 sunucularımızdan birinde aldım bu hatayı. Öncelikle raid yapısında oluşan bir hata olduğunu zannederek raid kartı update ederek yeniden raid yapılandırma işlemi gerçekleştirdim. Çok geçmeden aynı hatayı yeniden aldığımda sorunun başka birşeyden kaynaklandığını anladım. Ve sırasıyla öncelikle disklerde tarama yaparak disk yapısında arıza olup olmadığını test ettim ve bir hata bulamadım. Bu nedenle birtek ram veya slotlarla ilgili sorun olduğunu anladım. Bu sunucu ikinci el temin edildiğinden ram mhz’lerini kontrol etmem gerektiğini hissettim ve gördüm ki bazı ram’lerde uyuşmazlık tespit ettim. Doğal olarak farklı mhz’lerde olan ramleri bir kenara ayırarak sunucuyu yeniden kurup çalıştırmaya başladım. Uzun bir süredir server stabil şekilde çalışmaktadır.

Böyle bir hata ile karşılaştığınızda bu uygulamayı yapmadan geçmeyin:)

Kolay Gelsin.

Bunun Yanında Tmp Dizininin Çabuk Dolmasından Yana Şikayetçi Olan Ve tmp Dizininin Alanını Genişletmek İsteyenler İçin Anlatiyorum

SSH mize Giriş Yapiyoruz ;

Aşağıdaki Kodları Sırası İle Giriyoruz..

umount -l /tmp

dd if=/dev/zero of=/usr/tmpDSK bs=1024 count=2048000

mkfs.ext3 /usr/tmpDSK

mount -o loop,rw,noexec,nosuid /usr/tmpDSK /tmp

chmod 1777 /tmp

Böylece TMP dizinimiz 2 Gb Genişliğine Ulaşmiş Oldu,
Count= den Sonraki Bölümü İstediğimiz Gibi Değiştirebilirsiniz