php-cgi莫名其妙的崩溃

11条回复

homeserver通过FastCGI协议与php-cgi进程进行通信来执行php脚本文件。
一直以来都发现php-cgi进程不是很稳定，可能是我在实现协议上有不当的地方。运行一段时间后，例如一两天，phpcgi进程就会自动结束，也不留下任何相关信息。
目前，我通过写批处理文件，在进程结束后自动建立新进程来临时解决这个问题。之前在windows上是写一个批处理文件，然后copy几万行执行命令，这样就相当于无止境地执行。
在Linux上做的更简单，可能是我不知道在windows的批处理里怎么写循环。

#!/bin/bash
while true
    echo “Starting php server …”
    php-cgi -b 127.0.0.1:8080
    echo “Server exited. Restart it …t”
    sleep 10s
done

为啥要sleep 10s呢？因为php-cgi进程异常结束了，socket还在占用着8080端口，如果不睡眠一下，那么会耗尽CPU资源，知道端口能够使用。这样可能导致日志文件的体积疯狂增长，直到硬盘资源枯竭而止。。。

test

7条回复

这么好的id，真不知道怎么使用好呢~~

唉，最近被那些事儿烦死了，总不能静下来做些自己喜欢的东西。看到iceboy在写自己的MagicGate™，看到气泡熊在破解别人的加密算法，看到FB天天在做算法题，看到TualatriX在玩Chrome了，看到martin已经有自己的公司了，看到HD开源了，看到“C”在设计Vision的UI了。而我呢？好像很忙的样子，却又无所事事。还真希望快点到军训的日子，快点到临近放假的日子。。。

小虾啊小虾~~


(图由iceboy提供。。。)

一首Lisp的赞歌，听听吧

发表评论

Eternal Flame (song parody)

This is a parody of the song
“God Lives on Terra” by Julia Ecklar.
For more information about this song,
visit Songworm.

I was taught assembler
in my second year of school.
It’s kinda like construction work —
with a toothpick for a tool.
So when I made my senior year,
I threw my code away,
And learned the way to program
that I still prefer today.

Now, some folks on the Internet
put their faith in C++.
They swear that it’s so powerful,
it’s what God used for us.
And maybe it lets mortals dredge
their objects from the C.
But I think that explains
why only God can make a tree.

For God wrote in Lisp code
When he filled the leaves with green.
The fractal flowers and recursive roots:
The most lovely hack I’ve seen.
And when I ponder snowflakes,
never finding two the same,
I know God likes a language
with its own four-letter name.

Now, I’ve used a SUN under Unix,
so I’ve seen what C can hold.
I’ve surfed for Perls, found what Fortran’s for,
Got that Java stuff down cold.
Though the chance that I’d write COBOL code
is a SNOBOL’s chance in Hell.
And I basically hate hieroglyphs,
so I won’t use APL.

Now, God must know all these languages,
and a few I haven’t named.
But the Lord made sure, when each sparrow falls,
that its flesh will be reclaimed.
And the Lord could not count grains of sand
with a 32-bit word.
Who knows where we would go to
if Lisp weren’t what he preferred?

And God wrote in Lisp code
Every creature great and small.
Don’t search the disk drive for man.c,
When the listing’s on the wall.
And when I watch the lightning burn
Unbelievers to a crisp,
I know God had six days to work,
So he wrote it all in Lisp.

Yes, God had a deadline.
So he wrote it all in Lisp.

这首歌是一位研究AV的朋友好几年前介绍的。某吉他男（程序员）写的一首关于God使用Lisp的歌曲，蛮幽默滑稽的。在GNU的ftp上可以下载。我后来不知什么时候做了一个歌词文件，也是我到目前做的唯一一个LRC文件。。。

The song：
eternal-flame.ogg
The lyric：
eternal-flame. lrc

String Reverse in C++

7条回复

今夜帮沛公改了个C++程序，反转输出一个句子。觉得他写的程序过于麻烦，既使用了string又使用了char数组。
于是下了下面的程序：

#include iostream
#include cstring
int main()
{
char s[10000];
gets(s);
for(char*p; p=strrchr(s,’ ‘); *p=’\0’)
std::cout–(p+1)–” “;
std::cout–s–std::endl;
return 0;
}

但沛公喜欢简洁一点，就简化一下，如下：
#include
int main(char*p, char s[10000])
{
for(gets(s); p=strrchr(s,’ ‘); *p=’\0’)
std::cout–(p+1)–” “;
std::cout–s–std::endl;
}

(*^__^*) 嘻嘻…… 还可以试试非主流C++ ， 如下：


好神奇啊~~

10条回复

编译器真聪明，而且速度蛮快的。那么添加多几个是不是会变得慢呢？
复制多一些，看看情况。。。

这回无语了，编译了5分钟，结果还是内存达到2GB耗尽而终结。

博客搬家到美国了

13条回复

现在博客使用一个美国宾夕法尼亚州的主机，所以不要惊讶访问本站的响应速度突然变得慢了很多。只是响应很迟钝，传输速度上还是没多大问题的，至少下载一个图片不会让你等很久。

为什么要把博客搬家呢？

也许很简单，因为现在用的是一个Linux服务器。现在用起来觉得比Windows安全很多。为什么呢？

其实也怪我笨。用了都快七八年的Windows操作系统，现在我对它的安全机制却一无所知。例如假设一个php的apache服务器，用webshell竟然可以对服务器硬盘意淫。

可能是我没有学过如何配置一个Windows Server。我菜鸟，我幸福！

也有可能而且很可能是Windows把太多东西都隐藏起来了而不让你们知道，所以我一直没有接触过。这就很好地解释了为什么那么多注入windows内幕之类的书呢。。。

总之，觉得Linux很好用。我不用windows也不仅仅是因为安全问题，至少我很长时间没有被XX捉弄过（4年来用同一个的盗版xp，还没有中国病毒，也没有重装过系统）。

现在的服务器装着CentOS，配置了一个专门运行服务器的受限用户，另外还给每个站点分配一个用户。运行程序可以方便地限制程序使用的内存，CPU，IO等资源，真好！

贴一下服务器的配置：
[xiaoxia@home ~]$ cat /proc/cpuinfo
processor     : 0
vendor_id     : GenuineIntel
cpu family     : 6
model         : 15
model name     : Intel(R) Xeon(R) CPU         X3220 @ 2.40GHz
stepping        : 11
cpu MHz         : 2400.090
cache size     : 4096 KB

processor     : 1
vendor_id     : GenuineIntel
cpu family     : 6
model         : 15
model name     : Intel(R) Xeon(R) CPU         X3220 @ 2.40GHz
stepping        : 11
cpu MHz         : 2400.090
cache size     : 4096 KB

[xiaoxia@home ~]$ cat /proc/meminfo
MemTotal:     1488000 kB
MemFree:     1303632 kB

内存好像是动态变化的，好神奇。但提供商说保证至少有512M。

别看这个CPU以为很强大的服务器了，更强大的见下图：

原来Linux和Windows下的socket还是有那么多不同的

8条回复

之前以为linux和windows下的socket都是符合posix标准的，在一个环境下能够正常使用在另外一个环境也没问题。但没想到两者还是有那么多不同。

1.最先发现的是在windows上需要调用那个WSAStartup进行初始化才能使用socket。

2.linux下关闭socket用close，而windows上用closesocket。

3.后来发现shutdown的参数名称不同，windows上用SD_BOTH，linux上是SHUT_RDWR。

4.在linux下如果不正常关闭socket会触发SIGPIPE异常，所以我使用signal( SIGPIPE, SIG_IGN );忽略之。

5.linux下可以使用read，write函数操作socket，也可以使用send，recv。windows上只能使用send，recv？（不考虑udp的sendfrom和recvfrom）

今天又发现一个很大的不同点了，造成了homeserver在短时间内生成了一个20GB的日志文件，用完了vps的硬盘空间。如果一个正在使用中的socket使用close来关闭之而不调用shutdown，则该socket还是处于连接中，只是在进程的文件描述符中移除了（right？）所以导致了使用那个socket的线程一直没有收到关闭信号，阻塞在socket的recv上无法被关闭。而在windows上调用closesocket就彻底地断开了连接了。

下面是网上提供的信息：
close—–关闭本进程的socket id，但链接还是开着的，用这个socket id的其它进程还能用这个链接，能读或写这个socket id
shutdown–则破坏了socket 链接，读的时候可能侦探到EOF结束符，写的时候可能会收到一个SIGPIPE信号，这个信号可能直到socket buffer被填充了才收到，shutdown还有一个关闭方式的参数，0 不能再读，1不能再写，2 读写都不能。

所以，以后关闭socket还是同时使用shutdown和close好。

 

补充一下（2010-06-13）：
1、在linux下，shutdown会引起在recv和send中阻塞的线程返回-1。但是在windows下，除非closesocket，否则线程仍然阻塞。

2、windows的描述符是递增的，linux的描述符是重用的。也就是说你在linux下关闭了描述符0，然后打开一个文件，这个文件就是用了描述符0。

sgos2好几个月没有更新

13条回复

sgos2已经好几个月没有更新了，主要是因为我上大学后太忙了。Endless homework，做不好随时有挂科的危险。虽然还参加了ACM，但是却还没有一天认认真真做过算法的练习题目。而不像某K，可以晚晚写算法，真好。

有不少人都发觉sgos2很久没有更新，其实我一直没有放弃sgos2。只是我比较忙，另外几个参与开发的朋友可能也没多大劲头了。

sgos2的微内核结构还是挺好的。我至少在这几年里不会打算重写sgos，因为觉得它已经很好，稳定、安全、效率就是最好。不过目前面临的问题是，因为每个驱动是独立的进程，进程之间需要高效率的通信，所以我打算，把基于字符串通信的bxml改成只使用几个寄存器传值的快速消息机制。然后如果有必要的话，把bxml的通信弄到用户层实现，通过内存共享进行字符串和二进制数据的传输。这样就可以尽可能把没有必要的内存拷贝省去了。内核里也不需要任何字符串操作，因为字符串操作带来了很多安全问题。之前为了解决字符串和大堆数据传递的安全问题，我甚至还打算在内核里使用try catch的异常处理机制（Linux里有）。

大概到军训或者放寒假之后，或许我就可以再次全身心地投入到sgos2的开发之中。因为在国内对os研究是如此至少让我看到了深入接触它的必要性和未来的发展前景。