Month: May 2013

วันนี้ในกลุ่ม sysadmin บน facebook คุยกันเรื่องของ ubuntu mirror ของ PSU แล้วมีประเด็นของการใช้ script สำหรับการ mirror

ตัว script ที่ว่านี้ จะเป็น shell script ธรรมดา ที่จะไปเรียกใช้โปรแกรม rsync ที่จะทำหน้าที่ mirror ข้อมูลจาก primary ftp/rsync site ของ ubuntu มาเก็บไว้ที่เครื่อง server ของ PSU ตัว script จะถูกเรียกใช้โดย cron กำหนดไว้ใน crontab และเรียกใช้ 4-6 ครั้งใน 1 วัน (หรือ run ทุกๆ 6 หรือ 4 ชั่วโมง) ระยะเวลาที่ใช้ในการ run script ไม่แน่นอนว่าจะใช้เวลาเท่าไหร่ ขึ้นอยู่กับปริมาณของข้อมูลที่จะต้อง mirror จากต้นทางมายังปลายทาง

ถึงแม้ว่าการใช้ rsync จะช่วยให้ transfer เฉพาะไฟล์ ที่มีการเปลี่ยนแปลงไป หลังจากการ mirror ครั้งสุดท้ายมา แต่ในบางครั้งจำนวนของข้อมูลที่เปลี่ยนแปลงไป ก็อาจจะมากกว่าปกติ เช่นในช่วงเวลาที่มีการเปลี่ยน release ซึ่งทำให้มีไฟล์ใหม่ๆ เพิ่มขึ้นเป็นจำนวนมาก ทำให้ จากช่วงปกติ ซึ่งอาจจะใช้เวลาเพียง 1-2 ชม. ในการ mirror และ mirror ทุกๆ 4 ชม. ก็เพียงพอ ในช่วงเวลาของการปรับเปลี่ยน release ถ้าจะ mirror ให้เสร็จ ก็อาจจะใช้เวลาถึง 12 ชม. เป็นต้น

จะเกิดอะไรขึ้น ถ้าในการ mirror ครั้งที่แล้ว ยังไม่เสร็จสิ้นสมบูรณ์ แล้วก็ถึงเวลาของการ mirror รอบถัดไป?

ถ้าไม่มีการตรวจสอบใดๆเลย กระบวนการของการ mirror ในครั้งถัดมาก็จะเริ่มทำงาน ในขณะที่รอบแรกยังไม่เสร็จ และ ถ้ามีข้อมูลที่ถูกเปลี่ยนแปลงมากจริงๆ ถึงรอบที่ 4-5 ของการ mirror แล้ว … การ mirror ครั้งแรกก็ยังไม่เสร็จเรียบร้อยดี … และพอถึงขั้นนี้แล้ว ระบบจะมีภาระงานสะสมมากขึ้นเรื่อยๆ และระบบเริ่มช้าลง และ จำนวน process ของการ mirror ที่คั้งค้างอยู่ก็จะเพิ่มขึ้นเรื่อยๆ เพราะ process หลังๆ ก็จะไปหน่วงการทำงานของ process แรกๆให้ทำงานช้าลงไปด้วย

ครั้งแรกที่ผมเจอปัญหาในลักษณะนี้ process ของการ mirror ที่ run ค้างอยู่ทำให้ load ของระบบสูงกว่า 100 โชคยังดีที่ load ที่สูงขึ้นเกิดจาก i/o ของการเขียน disk ซึ่งยังทำให้สามารถ secure shell เข้าไปได้ สามารถ run คำสั่ง ps auxw เพื่อตรวจสอบได้ ถึงแม้จะช้าอยู่มาก แต่ก็ทำให้ทราบว่าปัญหาเกิดจากอะไร และเอาข้อมูลนั้นมาแก้ไขปัญหาในภายหลังได้

สำหรับปัญหาแบบนี้ วิธีการแก้ไข ก็ไม่ได้ยากอะไร การทำงานของ mirror process ในครั้งหลังที่ถูก start ขึ้นมาด้วย cron ไม่ควรที่จะทำงานต่อ ถ้า process แรกที่ทำงานอยู่ ยังทำงานไม่เสร็จ ควรที่จะปล่อยให้ process แรกทำงานให้เสร็จเท่านั้นเอง

ในแง่ของ shell script ก็สามารถทำได้ โดยการใช้ lock file ก่อนที่จะเริ่มต้นทำงาน ก็ตรวจสอบดูก่อนว่า มี lock file อยู่หรือเปล่า ถ้ามี ก็แสดงว่ายังมี process เดิมทำงานอยู่ ไม่ต้องทำอะไร ให้ terminate ไป ถ้าไม่มี lock file ก่อนที่จะเริ่มต้นทำงาน ก็สร้าง lock file ขึ้นมา เพื่อบอกว่า กำลังทำงานนี้อยู่ หลังจากทำงานเสร็จแล้ว ก็ลบ lock file นั้นทิ้ง เพื่อบอกว่า process ทำงานเสร็จแล้ว

เขียนเป็น script คร่าวๆ ได้ประมาณนี้ครับ

LOCK="/tmp/script-name.lock"
if [ -f "$LOCK" ]; then
    # lock file exist
    echo "Previous process is still running..."
    exit  -1 # Terminate script here
fi

# No other process, we do our job as usual

...

# end of our duty, do cleaning up, remove lock file

rm -f $LOCK

exit 0  # Terminate normally

วิธีการนี้ เป็นวิธีการที่ใช้อยู่แล้ว สำหรับ mirror script ของ ubuntu แต่ล่าสุดนี้ มีปัญหาเกิดขึ้นก็คือ process ของการ mirror ที่ควรจะ run เป็นระยะๆ กลับหยุดทำงานไปหลายวัน

ปัญหาที่เกิดขึ้นก็คือ script ที่ cron เรียกให้ทำงานนั้น ไม่ได้ทำงานเสร็จ ตามปกติของมัน ซึ่งจะมีการลบ lock file ทิ้งไป ซึ่ง สาเหตุอาจจะเกิดขึ้นได้จากหลายๆกรณี ในส่วนที่ผมเคยเจอ ก็คือ “ไฟดับ” ระบบที่ผมดูแลอยู่ในตอนนั้นถึงจะมี UPS backup แต่ไม่มีส่วนของการ monitor UPS และควบคุมให้ shutdown เครื่องแบบอัตโนมัติ ถ้าเกิดไฟดับนานเกินไป และ battery ของ UPS ไม่สามารถจ่ายไฟฟ้าให้นานพอจนกระทั่งไฟฟ้ากลับมาเป็นปกติได้ ตัว script ก็ตายไปกลางคัน พร้อมๆกับเครื่อง และ lock file นั้นก็ไม่ได้ถูกลบไป ทำให้ script ที่ run โดย cron ในรอบถัดไปไม่สามารถทำงานในส่วนของการ mirror ได้ เพราะ lock file ยังอยู่ (ตัว lock file ไม่ได้เก็บไว้ใน /tmp หรือ /var/lock) ส่วนกรณีอื่นๆ ก็จะเป็นกรณีที่ script เกิดตายไปกระทันหันโดยสาเหตุอื่นๆ เช่น out of memory หรือ process ถูก kill โดยกรณีอื่นๆ และ lock file ก็ถูกทิ้งค้างเอาไว้

ตัว script ที่ผมใช้ในสมัยหลัง ก็เลยมีส่วนของการตรวจสอบเพิ่มขึ้นมาอีกอย่างหนึ่ง ก็คือ นอกจากจะ สร้าง lock file แล้ว ก็จะเก็บ process id ของ script เอาไว้ใน lock file นั้นด้วย ในการทำงานของ script ส่วนของการตรวจสอบว่า process ของ script ที่ทำงานอยู่ก่อนหน้านี้ ยังทำงานอยู่หรือเปล่า นอกจากตรวจสอบว่ามี lock file แล้ว ก็จะตรวจสอบว่า process ของ lock file นั้น ยังมีอยู่ในระบบหรือเปล่า

ส่วนของการเก็บ process id ของ script นั้น ใช้วิธีการ

    echo "$$" > $LOCK

ได้เลยตัว special shell variable ‘$$’ จะเป็นหมายเลข process id ของ shell ที่ใช้ในการ run script ตัวนั้น

ส่วนการตรวจสอบว่า process นั้นยังทำงานอยู่หรือเปล่า ก็ใช้ process id ที่เก็บอยู่ใน lock file เอามาตรวจสอบ ซึ่งเราอาจจะตรวจสอบ โดยการใช้คำสั่ง

    ps ax | grep $previous_pid | grep -v grep

ดูก็ได้ แต่จริงแล้ว ก็มีวิธีง่ายกว่านั้น ก็คือ สำหรับ Linux แล้ว จะมี virtual directory ที่ชื่อว่า /proc และ ทุกๆ process จะถูกสร้างเป็น sub directory ใน /proc โดยใช้ชื่อเป็นหมายเลขของ process id ดังนั้น แทนที่เราจะตรวจสอบโดยการใช้คำสั่ง ps ซึ่งจะต้องส่ง ourput ไปให้คำสั่ง grep อีก 2 รอบ ก็สามารถตรวจสอบเพียงแค่ว่ามี directory นั้นอยู่หรือเปล่าได้เลย โดยการใช้

    if [ -d /proc/$previous_pid ]; then
    ...
    fi

ตัวอย่าง script ที่ใช้งานวิธีการนี้

#!/bin/sh
TASKNAME="this"
LOCK="/tmp/${TASKNAME}.LCK"
LOG="/tmp/${TASKNAME}.log"

lock() {
    if [ -f $LOCK ]; then
       D=`date`
       task_pid=`cat $LOCK`
       if [ -d "/proc/$task_pid" ]; then
          # it's possible that this_pid is different task, but
          # it is very unlikely.
          echo "$D : Previous process (pid: $task_pid) is running"
          exit
       else
          # Lock is not clean up properly, assume
          echo "$D : clean up previous lock file (pid: $task_pid)"
       fi
    fi
    echo $$ > $LOCK
}

unlock() {
    rm -f $LOCK
}

do_myjob() {
    START=`date`
    sleep 10    # This is the real 'task' of this script
    STOP=`date`
    echo "Process start at: $START" >> $LOG
    echo "Process stop at : $STOP"  >> $LOG
}

lock
do_myjob
unlock

ใน script ตัวอย่างข้างต้น สมมติ save ให้อยู่ในชื่อว่า t และกำหนด permission ให้สามารถ execute ได้ โดยใช้

$ editor t
$ chmod +x t

เราสามารถ ตรวจสอบการทำงานของ script ดูได้ โดย ทดลอง run

$ ./t

ซึ่งมันจะรอเวลา 10 วินาที ตาม “sleep 10” ในฟังก์ชัน do_myjob() ก่อนที่จะกลับมาที่ shell prompt อีกครั้งนึง และในไฟล์ /tmp/this.log จะแสดง เวลาเริ่มต้นทำงาน และ ทำงานเสร็จ
ถ้า run script ด้วยคำสั่ง

$ ./t & ./t

ตัว script ตัวแรกจะทำงานตามปกติ แต่ตัวที่สอง จะแสดงข้อความว่า “…Previous process (pid: xxxxx) is running” และ เราจะไม่สามารถ run script ครั้งที่สองได้ จนกว่า process ที่ run ค้างอยู่ทำงานเสร็จแล้ว และ ถ้าตรวจสอบใน log file ก็จะเห็นว่า การทำงานของ script จะเป็น [start, stop], [start, stop] ไปเรื่อยๆ ไม่มีการซ้อนเหลือมกัน

แต่ใน script ตัวนี้ ถ้าหาไป comment บรรทัด lock; do_myjob; unlock เป็น

# lock
do_myjob
# unlock

แล้วทดลอง run script

$  ./t & ./t

ก็จะเห็นว่า script สามารถ run ซ้อนกันได้ และ ใน log file ก็จะเห็นเป็น star, stat, stop, stop ซ้อนเหลื่อมกัน ซึ่งเป็นกรณีที่เราไม่ต้องการให้เกิดขึ้น

script ตัวนี้ อาจจะไม่ได้สมบูรณ์ 100% ในการใช้การตรวจสอบว่า มี process เดิมยังทำงานค้างอยู่หรือเปล่า เพราะมีความเห็นไปได้ว่า process id ที่มีอยู่และตรวจสอบจาก /proc ได้นั้น ไม่ได้เป็น process ของ script ตัวนี้ ที่ทำงานไปในครั้งที่แล้ว และยังทำงานไม่เสร็จ แต่เป็น process อื่นๆ ซึ่งไม่เกี่ยวข้องกับ script ตัวนี้เลยก็เป็นไปได้ เพราะ process id จะมีการเอากลับมาใช้ใหม่ หลังจากใช้ไปจนครบแล้ว แต่ โอกาสเช่นนั้น จะเกิดขึ้นได้น้อยมาก (process id เป็น process id เดียวกับ script ที่ terminate ไปแล้วแบบผิดปกติ และ process ที่ไม่เกี่ยวข้องทำงานอยู่ในช่วงเวลานี้พอดี) การตรวจสอบเพ่ิมเติม จะทำให้ script มีความซับซ้อนมากขึ้น โดยใช่เหตุ ก็เลยทิ้งไว้เท่านี้ครับ ผู้ที่สนใจ อาจจะตรวจสอบโดยใช้ ข้อมูลอื่นๆ ใน /proc/$process_id เช่น cmdline ดูได้ ทิ้งไว้ให้ไปลองทำเป็นการบ้านดูครับ 🙂