在我的看法如果想要教從來沒有經驗的初學者，C語言雖然是最扎實的一條路，也同時是最難走的一條路，以我自己的經驗來說，從國一到國三我自學了三年的VB，到了高中才開始學C/C++，我敢說如果沒有VB那樣簡易上手的那段時期，而一開始就學習如C/C++如此困難的程式語言，或許我會被挫折感打敗

程式語言的學習與思考是可以從高階的層次開始的，先忽略細節，避免太過困難、抽象的概念，有趣的實際小應用入門，C語言顯然都不具備有這樣的特性，與其使用C語言，Python、Basic、Ruby等語言才是更容易上手的，在網路上我所看到很多從5歲到10歲左右就開始學程式語言的高手，都是從Basic之類的語言開始的，但我從來沒有看過有5歲就能從C語言入門的，我想這就顯示出了簡易語言對於入門的重要性。

MIT使用Python做為CS入門程式設計課程

MIT用Python做為Computer science入們程式設計課程的語言，我想這已經不是新聞了，即使大師們活在巨塔中，至少也有網路吧? 這是一個宅在家裡都能學到最新事物的時代，接觸點新的事物好嗎? 很多人都學一招半式教一輩子，或許如果學的是古典音樂，這可能過個一百年都不會改變，但是不幸的是我們所在的是改變最快速的產業，不要期待學校能教多新的東西，但只希望不要跟世界脫節太多，或許你會反駁，很多東西過很久都不會變，像是概念上的東西，但是我會說，我用更現代的工具可以做得更好，一樣可以教不變的概念，只是看你有沒有心想要去做得好而已

這些課程都能在網路上免費找到，以下為MIT的6.00 Introduction to Computer Science and Programming上課的影片，在第一堂課33分左右，裡面的講者提到了程式語言，他說以前他接受的是lisp的訓練，可是他現在教的是Python，我想光這點就顯示出了國外一流大學和國內大學的心態差別，國內的李大師只會很開心的描述當年學了什麼東西，然後把這些十年前、二十年、三十年前學到的東西教給學生，更糟的是國內的李大師之流都沒有太豐富的實戰經驗，他們都以發論文為生，但國外的一流大學的老師其實是很多都有豐富的業界實戰經驗，他們懂得外面真正需要的是什麼

剩下還有很多堂課的影片，在網路上搜尋都找得到，所以就不在此列出

You can see there are some gaps in the plot, that’s caused by server restarting.  Of course, for users, that would definitely be bad experience.  Thus, I’m thinking how to solve this problem recently.  Before we go into the design, let’s look the reasons for restarting server first.

• To deploy new version of program
• To fix bugs
• The process is using to much memory
• To reload environment, ulimit -n for example (the limit count of file descriptor under unix-like environment)
• To migrate from host A to host B

For simply employe new version of program, we can use reload function of Python to reload modules.  But there is some problems, reload function only rerun the module, those created instances are still there, it might work if the change is minor.  On the other hand,  reloading can’t solve memory usage problem, process environment change problem.  And here comes the final reason, to migrate service from host A to B.  Indeed, it is difficult not to make any down time for such migration, and there is little chance to do such migration, therefore, we’ll only focus on migration in same host.

The idea

The biggest challenge is, how to migrate those working connections?  My idea is simple, create a new process, and transfer those connection to the new process, and shut the old one down.  Following diagrams show my method.

The Master is a process which is charge for managing migration and receiving command from other process.  And the process A is for running service.

Before we perform the migration, the Manager startup process B, and wait it says it’s readly.

When process B said "Hey! I’m ready", then manager tell process A to send the connection state descriptor to process B.  Process B receive the state, and take over the service.

Finally, process B took over the service, then master tells process A "You are fired." and the process A rolls itself out.

That’s it, the service was migrated, and there is no down time.

The problem – socket transfer

The idea sounds good, right? But still, we have some technical problem to solve.  It is "How to transfer socket (file descriptor) from one process to another?".  To solve this problem, I have some study, and eventually I know two methods to achieve the goal.

Child process

For most of unix-like OS, child processes inherit file descriptors from their parent.  Of course we can use this feature to migrate our service, but however, it got its limitation.  You can only transfer file descriptors to child process.

Sendmsg

Another way to achieve same goal is, to use sendmsg through a unix domain socket to send the file descriptors.  With sendmsg, you can transfer file descriptors to almost any processes you like, that’s much flexible.

A simple implementation

To simplify the example, we only implement process A and process B here, it is quite enough for two process to complete the migration.  Before we go into the details, there is another problem to solve, which is sendmsg is not a standard function in Python.  Fortunately, there is a third party library named sendmsg provides this function.  To install sendmsg, it is easy, just type

easy_install sendmsg

And here you are.  Okay, following are the two programs.

a.py

import os
import socket
import sendmsg
import struct
 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', 5566))
s.listen(1)
conn, addr = s.accept()
conn.send('Hello, process %d is serving\n' % os.getpid())
print 'Accept inet connection', conn
 
us = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
us.bind(('mig.sock'))
us.listen(1)
uconn, addr = us.accept()
print 'Accept unix connection', uconn
 
payload = struct.pack('i', conn.fileno())
sendmsg.sendmsg(
    uconn.fileno(), '', 0, (socket.SOL_SOCKET, sendmsg.SCM_RIGHTS, payload))
print 'Sent socket', conn.fileno()
print 'Done.'

b.py

import os
import socket
import sendmsg
import struct
 
us = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
us.connect(('mig.sock'))
print 'Make unix connection', us
 
result = sendmsg.recvmsg(us.fileno())
identifier, flags, [(level, type, data)] = result
print identifier, flags, [(level, type, data)]
fd = struct.unpack('i', data)[0]
print 'Get fd', fd
 
conn = socket.fromfd(fd, socket.AF_INET, socket.SOCK_STREAM)
os.close(fd)
conn.send('Hello, process %d is serving\n' % os.getpid())
raw_input()

The flow is simple, the a.py accept an inet socket and open an unix domain socket, wait b.py to take over the service.  And here we runs b.py, it connects to a.py, receives the fd of socket and takes over providing service.

The result

As the result shows, there is not down time between the service migration.

It is very useful to employ this technique in server programs.  You can even migrate service from Python server to a C/C++ server, or vice versa.  Also, to keep the memory usage low, you can also migrate the service to same program periodically.  I will try to employ this technique in my servers to achieve zero down time migration.  If you are interesting in this technique, have a try, it is fun and useful :)

圖中被切斷的山峰都是伺服器重啟的時候，無疑的這對使用者來說是不好的體驗，對於一般網頁HTTP這類stateless的伺服器來說重啟是無所謂，但串流伺服器就不一樣，因此最近我在思考如何解決這樣的問題，首先想到的是伺服器重開的原因，不外乎有幾種

• 部署新版的程式
• 為了修正BUG
• 記憶體用量過高
• 重新讀取執行環境，例如ulimit -n，也就是檔案數量的限制大小
• 從主機A移到主機B

以Python的伺服器來說，如果只是單單只是為了部署新版的程式，Python有個reload函數可以重讀整個module，因此可以設個管理用的後門用來重載模組，但是這樣做有個問題，就是已經產生的instance還是一樣，其實說穿了等於是重新執行那個module，如果只是簡單的改版還好，但複雜的改版就可能牽扯到太多因素難以透過這樣來更新，而除此之外，很多重開的因素像是記憶體用量過高，或著執行的環境參數改變，這些都無可避免的一定得建新的process，至於從A主機移到B主機，基本上是難以避免的一定得重啟伺服器，除非有某個前端的伺服器保持連線，後端的伺服器進行交移工作才有可能，而主機轉移的狀況其實很少出現，因此這篇文章要探討的是如何辦到同一臺機器內的服務轉移

方法

最大的問題就在於，連線中的socket該如保持住連線，最簡單的想法就是建立新的process，將目前的連線交給新的process，新的process接手完所有的連線開始運作後舊的process就能終止了，當然所謂的連線還包函了服務的狀態，我們在者裡稱之為 CSD (Connection State Descriptor)，大致想法如下面圖片所示

首先Process A是正在運行的process，而Manager是負責控制遷移的process

此時Manager啟動了要負責接手的Process B

接著Manager通知A將連線狀態傳送給Process B，B接手後繼續提供服務，並且告知接收完成

在確定B能夠接手服務並且正確執行後，這時Manager就能將A中止，走到這裡服務就算是完整地移交了，中間沒有任何間斷

技術層面問題 – Socket的轉移

這樣的做法理論上看起來確實可行沒錯，但是最主要有技術上的問題得解決，就是如何將socket，或著是file descriptor轉移到另一個process，在我找過相關的資料後知道目前有兩個方法

child process

這個方法主要是因為child process在生成後會繼承parent process的file descriptor，但是缺點就是只限於child process，如果我們想將服務移交給另一個完整的獨立process這個方法就會行不通，因此使用上會有很多限制

sendmsg

另一個方法就是unix domain的socket有提供一個函數叫sendmsg，可以將file descriptor轉移到任何process，這樣一來實用性就比child process高很多，於是我決定採用此方法

簡易的實作

在這樣的轉移架構設計，Manager主要目的是要能夠對外有個統一個process能溝通，如果不需要的話其實兩個process就能達成服務轉移，為了實作簡單因此這個例子只用了兩個process進行轉移

還有另一個問題是Python標準函式庫裡沒有sendmsg，不過幸好有第三方函式庫已經準備好，就叫做sendmsg，安裝也很簡單，只要打

easy_install sendmsg

就可以了，接下來就是兩個範例程式

a.py:

import os
import socket
import sendmsg
import struct
 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', 5566))
s.listen(1)
conn, addr = s.accept()
conn.send('Hello, process %d is serving\n' % os.getpid())
print 'Accept inet connection', conn
 
us = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
us.bind(('mig.sock'))
us.listen(1)
uconn, addr = us.accept()
print 'Accept unix connection', uconn
 
payload = struct.pack('i', conn.fileno())
sendmsg.sendmsg(
    uconn.fileno(), '', 0, (socket.SOL_SOCKET, sendmsg.SCM_RIGHTS, payload))
print 'Sent socket', conn.fileno()
print 'Done.'

b.py

import os
import socket
import sendmsg
import struct
 
us = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
us.connect(('mig.sock'))
print 'Make unix connection', us
 
result = sendmsg.recvmsg(us.fileno())
identifier, flags, [(level, type, data)] = result
print identifier, flags, [(level, type, data)]
fd = struct.unpack('i', data)[0]
print 'Get fd', fd
 
conn = socket.fromfd(fd, socket.AF_INET, socket.SOCK_STREAM)
os.close(fd)
conn.send('Hello, process %d is serving\n' % os.getpid())
raw_input()

大致上的流程很簡單，首先a.py接收一個inet的連線，接著就開一個unix socket，等待b.py上線，然後把服務透過sendmsg轉移給b.py

執行結果

由執行結果我們可以看見，原本的連線是由process A提供的，然後轉交給process B，中間沒有任何中斷

有了這樣的技術基礎和想法，接著就剩下的是細節，基本上連線的狀態盡量以抽象的方式提供，如此一來任何程式只要能夠處理連線狀態就能夠接手，甚至可以由Python寫的伺服器轉移到由C/C++寫的伺服器，這些都可以辦到，中間服務都不會有間斷，而且也可以像HTTP伺服器一樣，處理到一定的量自動開新的process轉移給自己，如此一來可以保持低記憶體用量，有相當多的好處，未來我會試著將伺服器以這樣的想法改寫，應該就能做到無停機更新，有興趣的話也可以自己試試看

I use email as error logging report, but however, as you can see if there is something wrong with my servers in same time, network outage for instance, there will be so many error report mails come in my mailbox like crazy.  Therefore think a central log might be a good idea, then I decide to develop a simple central logging system for my own servers.  Here is a screenshot of the Logy web page.

It categorizes your logging records by IP address automatically, and also, you can set a application name for different applications which are running in same box.  And one important feature is, it is base on Flask :)

It is super easy to write records to Logy, here is an example:

import logging
 
import ex_loghandlers
 
rootLogger = logging.getLogger('')
rootLogger.setLevel(logging.DEBUG)
 
sream_handler = logging.StreamHandler()
# set up the http handler which writes records to Logy server
http_handler = ex_loghandlers.ExHTTPHandler(host='localhost:5000',
                                            url='/sink/TEST/myapp',
                                            method='POST')
rootLogger.addHandler(sream_handler)
rootLogger.addHandler(http_handler)
 
logger1 = logging.getLogger('myapp.area1')
logger2 = logging.getLogger('myapp.area2')
 
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
logger1.info('How quickly daft jumping zebras vex.')
logger2.warning('Jail zesty vixen who grabbed pay from quack.')
logger2.error('The five boxing wizards jump quickly.')
 
try:
    raise Exception("Boom")
except:
    logger1.fatal("Huston, we've got a problem", exc_info=True) 
 
logger1.info('Everything goes fine, now.')

You need to install my module named ex_loghandlers before you can run this script, it contains an ExHTTPHandler which provides extra information for Logy.

Here are some more information of Logy:

PyPi page: http://pypi.python.org/pypi/logy

Bitbucket: https://bitbucket.org/victorlin/logy/src

這個程式主要是用來解決繁體中文的.PO檔和簡體之間的互換問題，因為翻譯完繁體中文，基本上和簡體沒有太大差別，用Google translate轉成簡體就可以，但是手工作起來很煩，這種事情當然是交給程式執行

安裝方法很簡單

easy_install po_translate

使用也很簡單

po_translate input.po output.po zh-TW zh-CN

像這樣就能輕鬆的透過Google translate把繁中的.PO檔轉成簡中的

相關連結

PyPi的連結

Bitbucket的Repo

It is written in Python, you can install it by

easy_install apply_firewall

Or you can download it here:

http://pypi.python.org/pypi/apply_firewall/

I hope this could be helpful for linux administrators :D

不同的網路框架模型

網路隨著時代發展，已經成為現代生活中越來越重要的重要的基礎，而做為提供這些服務的伺服器，負載的連線也越來越多，因此網路程式的軟體、硬體架構也一直在演變，才有辦法承載越來越多的連線數量，有人希望在一台機器能夠同時處理1萬個連線以上，所以提出C10K問題，並且之後有不少新的的技術來達成這個目標，而在此我們只專注在於軟體的架構上，首先介紹最簡單的架構

阻塞式單一行程

這樣的網路程式非常的簡單，只有一個迴圈，單一個行程，處理完一個要求後才繼續處理下一個，理所當然這樣的效能非常差，因為連線在完成前其它的連線都無法被處理，現代的伺服器已經很少看見這樣的架構，但因為優點是簡單，如果沒有什麼大量同時連線要處理，其實這樣的架構就很足夠

阻塞式多行程

因為既然單一行程只能同時處理一個請求，那很簡單的想法就是每個請求開一個行程去處理，如此一來就能同時處理更多的請求，但是這樣做有缺點，行程的copy如果是fork的話，有os paging system在成本上其實還好，但是還是有，而且越多的連線就表示需要越多的context-switch，當連線量多到一定程度時，可能大部份的CPU時間都在忙著進行context-switch，如此一來這樣的架構在此情況下是沒有效率的，但是優點是寫伺服器的部份事實上和寫單一行程阻塞式不會差太多，一樣簡單好寫

阻塞式多行程多執行緒

除了多行程多阻塞式，有些程式為了減少process copy的成本，或是其它的考量，會在多個行程上開多個執行緒來處理請求，也有可能是單行程多執行緒，但是基本上和上面這幾種都沒有太大的差別，而引進了執行緒帶來了一些額外的問題，dead lock、race condition等等，當不同的執行緒如果在一起有共同的東西要處理，這些常見的同作問題就會出現，使得程式得寫得更小心

非阻塞式事件驅動

為了解決上面提到多行程和多執行緒等所帶來的問題，有一種做法是只有單一主要的迴圈來檢查有無網路IO的事件發生，再來決定要怎樣處理，這樣的好處在於省掉了context-switch、process copy等等成本，也不會有dead lock、race condition等問題，但缺點在於程式的部份會變複雜，因為當你一件事件被觸發，有事情還沒做完，你就得記下目前狀態，再下次事件觸發時再依先前的狀態來決定接下來要做什麼，不像上面是線性的程式執行那樣直觀，Twisted就是這樣的網路框架

非阻塞式Coroutine

那你或許會想，有沒有可能我們能有事件驅動的好處，和阻塞式那樣的直觀好處呢? 答案或許就是Coroutine，基本上它的本質也是事件驅動，只有單一的迴圈在檢查事件的發生，但是加上了coroutine的概念，而Gevent就是這樣的函式庫

Coroutine

講了這麼多次coroutine，我相信大部份的讀者可能還是不懂這到底是什麼鬼東西，對於大部份程式設計師而言這應該都算是較陌生的名字，對我而言，在一開始這也是個令人困惑的名詞，但事實上只要理解以後就會發現coroutine不是這麼的難懂，用簡單的一句話來說Coroutine，就是可以暫時中斷，之後再繼續執行的程序，我們來看一個例子，事實上Python就有最基礎的Coroutine，也就是generator

# -*- coding: utf8 -*-
def foo():
    for i in range(10):
        # 丟資料並且把主控權交給呼叫者
        yield i
        print u'foo: 主控又回到我手上了，打我阿笨蛋'
 
bar = foo()
# 執行coroutine
print bar.next()
print u'main: 現在主控權在我們手上，做點雜事'
print 'main:hello baby!'
# 回到剛才foo這個coroutine中斷的地方繼續執行
print bar.next()
print bar.next()

執行結果:

0
main: 現在主控權在我們手上，做點雜事
main:hello baby!
foo: 主控又回到我手上了，打我阿笨蛋
1
foo: 主控又回到我手上了，打我阿笨蛋
2

看到了嗎? 我們的foo在執行的過程中被中斷又繼續了好幾次，這就是coroutine，你可能覺得這樣一點用都沒有，我在一開始也這樣想，thread的context-switch也是可以暫停然後再繼續執行，所以這樣的特性好處在哪裡? 有幾個重點在於

• thread之間需要context-switch，而且成本很高，但是coroutine之間的切換很快
• coroutine的成本很低，可以很輕易的產生大量的coroutine
• 這些事情全是在同一個thread裡發生的，因此不會有race condition等問題發生 (還是可能會有)
• thread的context-switch雖然我們可以進行某種程度的控制，但是很多部份還是得靠OS來決定要先排程哪個thread，而coroutine的執行是由我們自己控制的

接著我們用圖來說明coroutine和thread之間的差別

你可以發現，Coroutine所做的其實就只是在單一thread裡面不同的coroutine裡互相切換，本質上和thread很像，所以也有些coroutine叫做micro-thread，而切換通常都是我們主動去做的，看到下面這張，當你建立了不同的thread，context-switch未必是在你預期的情況下發生的，而且通常都是由OS引發的，除此之外，如果你老爸夠有錢，買了最新的Intel iCore 2000的一千核心CPU，那麼恭喜你，你的thread可能是由不同的processor執行，因此不同thread的程式真正的同時執行是有可能的

等等! 這時候你可能抓起你手邊的OS恐龍本敲你自己的頭，你這樣問道: 嘿! 恐龍本上面有提到FCFS、RR等等排程演算法，那Coroutine呢? 答案是如同我們前面提到，這由我們自己決定，這是好處之一，這時你可能又會抓著你的頭髮大叫 "網路呢? 網路呢? 講了半天我只看到Coroutine之間切來切去，我根本看不到在這裡面的半點網路成份，哪怕是一公克也好"

確實，當我一開始在讀相關資料時也很困惑，ˊ這樣跳來跳去又如何? 網路應用到底在哪裡? 現在就回到我們的主題來

少了非同步IO的Coroutine，就像少了哇沙必的生魚片

到目前為止都很難和網路有什麼相關的聯想，但是想到網路就會想到IO，而事實上這樣的優點就是在於有大量IO時會顯得特別好用，我們考慮一下當遇到IO時就將主控權交給別人

Gevent的運作方式基本上就很類似這張圖，它的Coroutine是由greenlet實作的，而每個Coroutine都有一個parent，最頂層的Coroutine就是main thread或是當前的thread，每當Coroutine遇到IO的時候，就將主控權交給root coroutine，它會視哪些coroutine的IO event是已完成的，就將主控權交給他，其實就只是這樣而已，事實上程式寫起來完全和一般的阻塞式伺服器沒什麼兩樣，但是它千真萬確是非同步的，這就是它神奇的地方，我們來看點實際的例子，我們直接拿gevent範例裡的同步下載程式

#!/usr/bin/python
# Copyright (c) 2009 Denis Bilenko. See LICENSE for details.
 
"""Spawn multiple workers and wait for them to complete"""
 
urls = ['http://www.google.com', 'http://www.yandex.ru', 'http://www.python.org']
 
import gevent
from gevent import monkey
 
# patches stdlib (including socket and ssl modules) to cooperate with other greenlets
monkey.patch_all()
 
import urllib2
 
def print_head(url):
    print 'Starting %s' % url
    data = urllib2.urlopen(url).read()
    print '%s: %s bytes: %r' % (url, len(data), data[:50])
 
jobs = [gevent.spawn(print_head, url) for url in urls]
 
gevent.joinall(jobs)

這程式太簡單了對吧? 但它確實能做到極高效能的同步下載，我們做一點簡單的解釋，首先令人困惑的是monkey.patch_all()，會有這行，是因為Python內建的各種函式庫裡的IO函式庫、及會阻塞住的函數，例如Sleep都會讓整個程式卡住，而不是利用Selector/epoll之類的功能來處理，所以monkey這個函式庫就是負責將Python內建的函式庫取代成以gevent的非同步形式的函式，如此一來當執行到那些IO之類的動作，會切到MainThread的coroutine進行排程，而非直接卡在那裡等結果，而當IO動作真的完成了，gevent內部會將該coroutine標示為可執行的，因此下次有機會就會排到那個coroutine，看到下面的spawn，就是在產生coroutine，在這裡的coroutine因為事實上是greenlet這個Python函式庫題供的，所以事實上叫做greenlet

你可以在腦中想像一下，spawn首先呼產生了三個執行print_head的routine ，在joinall的地方，把主控權交給第一個print_head，而在函數裡遇到了urllib2.urlopen這個IO動作，因此它將自己設為等待狀態，並且將主控權交還給MainThread，而MainThread將主控權排給了第二個print_head，同樣的也遇到了urllib IO動作，第三個也是一樣，而這三個都在等待，主控權便再次回到了MainThread，它等待有哪個gevent的IO事件完成了，就將主控權交給它，如此一來，重覆這樣的過程，三個網頁的同步下載就在coroutine的切換之間完成了，當三函數return，joinall也會結束，整個程式就跑完了

一開始會很難理解，但一但弄清楚之後就會瞭解這樣寫法的簡單和實用性，你可以忘記它背後的原理，把它當作是一般的阻塞式網路程式來寫，就會很輕鬆，但又輕量、高效能，以上大概就談到這裡，有興趣可以玩玩看gevent

#!/bin/env python
"""Simple tool for rotating nginx log file
 
@author: Victor Lin (bornstub@gmail.com) blog: http://blog.ez2learn.com
"""
import os
import shutil
import optparse
import datetime
import logging
import subprocess
 
log = logging.getLogger(__name__)
 
def main():
    parser = optparse.OptionParser()
    parser.add_option('-p', '--pid', dest='pidFile', metavar="FILE", help='/path/to/nginx.pid')
    parser.add_option('-l', '--log', dest='logFile', metavar="FILE", help='/path/to/logfile')
    parser.add_option('-f', '--format', dest='nameFormat',
        help='format of rotated log file name' )
    parser.add_option('-o', '--owner', dest='owner', help='the owner user of log file to set')
    (options, args) = parser.parse_args()
 
    if not os.path.exists(options.logFile):
        log.info('The log file %s does not exist', options.logFile)
        return
 
    # move the log file
    newName = datetime.date.today().strftime(options.nameFormat)
    log.info('Move log file %s to %s', options.logFile, newName)
    subprocess.check_call('mv %s %s' % (options.logFile, newName), shell=True)
 
    if options.owner:
        log.info('Set owner of %s to %s', newName, options.owner)
        subprocess.check_call('chown %s %s' % (options.owner, newName), shell=True)
 
    # tell nginx to reopen the file
    log.info('Reopen log file')
    pid = int(open(options.pidFile, 'rt').read())
    os.kill(pid, 10)
 
    log.info('done')
 
if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    main()

Usage:

python nginx_log_rotate.py -p /usr/nginx/logs/nginx.pid -l "/usr/nginx/logs/YOURDOMAIN.log" -f "/home/USER/logs/YOURDOMAIN.%Y-%m-%d" -o OWNER_USER

For example, you can set up a crontab task for rotating the log file like this:

0 0 * * * python nginx_log_rotate.py -p /usr/nginx/logs/nginx.pid -l "/usr/nginx/logs/YOURDOMAIN.log" -f "/home/USER/logs/YOURDOMAIN.%Y-%m-%d" -o OWNER_USER

site-packages

PIL

__init__.py

_imaging.pyd

_imagingcms.pyd

… and other files of PIL

See? Python can only see __init__ and those stuff belong to PIL, but it can’t find the package PIL,  that’s why it failed.  To solve this issue, it is simple, just create another PIL directory in the original PIL directory, and move every in it into the new sub PIL directory.  They you will get something like this:

site-packages

PIL

PIL

__init__.py

other PIL sutff here …

That’s it!  Now python can see and find the PIL package.  Surely, the release of PIL  it is broken,  but fortunately, it is not difficult to fix.  Hope this article could be helpful for people who also encountered this problem.

# -*- coding: utf8 -*-
'''
Created on 2010/4/27
 
@author: Victor-mortal
'''
 
import os
import sys
import urllib
import json
import logging
import optparse
import codecs
import htmllib
 
log = logging.getLogger(__name__)
 
def unescape(s):
    p = htmllib.HTMLParser(None)
    p.save_bgn()
    p.feed(s)
    return p.save_end()
 
def translate(text, sourceLanguage, destLanguage):
    """Translate a text
 
    @param text: text to translate
    @param sourceLanguage: the language original text is in
    @param destLanguage: language to translate to
    """
    log.info('Translate %s from %s to %s', text, sourceLanguage, destLanguage)
    query = dict(v='1.0',
                 q=text.encode('utf8'),
                 langpair='%s|%s' % (sourceLanguage, destLanguage))
    file = urllib.urlopen(
        'http://ajax.googleapis.com/ajax/services/language/translate',
        data=urllib.urlencode(query)
    )
    result = file.read()
    file.close()
    jsonResult = json.loads(result)
    if not jsonResult['responseData']:
        return None
    return unescape(jsonResult['responseData']['translatedText'])
 
def main():
    logging.basicConfig(level=logging.INFO)
 
    parser = optparse.OptionParser(
        usage="usage: %prog sourcePoFile destPoFile sourceLanguage destLanguage"
    )
    (_, args) = parser.parse_args()
 
    sourceFilePath = args[0]
    destFilePath = args[1]
    sourceLang = args[2]
    destLang = args[3]
 
    log.info('Translate %s (in %s) to %s (in %s)',
             sourceFilePath, sourceLang, destFilePath, destLang) 
 
    result = []
    sourceFile = codecs.open(sourceFilePath, 'rt', encoding='utf8')
    for line in sourceFile.readlines():
        if line.startswith('msgstr'):
            _, msg = line.split(' ', 1)
            msg = msg.strip()
            msg = msg[1:-1]
            translatedMsg = translate(msg, sourceLang, destLang)
            if not translatedMsg:
                translatedMsg = msg
            result.append(('msgstr "%s"\n' % translatedMsg))
        else:
            result.append(line)
    sourceFile.close()
 
    destFile = codecs.open(destFilePath, 'wt', encoding='utf8')
    destFile.writelines(result)
    destFile.close()
 
if __name__ == '__main__':
    main()

使用方法很簡單

python po_translate.py 來源po檔 目的po檔 來源語言 目的語言

而語言的代碼，在Google translate的API文件中有寫，事實上它能做的不只有繁簡轉換，要翻成其它語言也可以，只是如果你能接受那品質的話