一段时间以前，我们的项目中服务器程序的发布很麻烦，得在测试服务器上执行好几个命令才能发布完成。

为了简化这些操作，制作了一个php页面，将一些shell在php中调用，之后在浏览器里点击几个按钮就可以完成打包，部署工作了。

这样子正常使用了一段时间后，有一个周日到公司加班，一到公司QA同事就告诉我客户端连接不到测试服务器，无法测试。

之后我连接到服务器检查日志，我发现在当天零晨04：00左右，几个服务器程序全部正常停止了，在日志中记录了完整的停止信息。

当时就很奇怪，粗略查了一下，怀疑可能是某个定时任务执行引起的。再之后就把这事儿忘记了，因为一直忙着项目，周末也经常加班，经常重新部署新的应用，所以这个问题就被忽略了。

今天早上一来公司，又有同样的现象发生。

再查日志时间，还是在04：00左右，所有的服务器程序自动停止了。

查看定时任务，怀疑是一个叫logrotate的定时任务引起来的，因为它总是在零晨4点左右执行。logrotate会向apache的httpd进行发送一个kill －HUP，以便执行日志循环。

可奇怪的是即使收到HUP，最多也只是把它的子进程全部杀死，而我通过php启动的java进程在启动后已经不是它的子进程，但还属于同一个进程组里，难道apache向进程组里的所有都发送了hup信号？

下载了apache中源代码，搜索了一下hup，在worker.c中发现了以下面的注释：

Apache doesn't keep track of their pids, it just sends SIGHUP to the process group, ignoring it in the root process

应该是证实的我的猜测，因为我对Linux c编程不熟悉，只能看个大概，不知道是否确实如此。

找到的原因，那如何避免呢？

1. 停止Apache的logrotate，因为这个apache日志很少，一年不删除都没问题

2. 在java程序中忽略HUP信号，在网上搜到了一个 Java - Signal Handling

不知道好不好用，也没来得及试验，先记在这里，有时间再测试。

经历过这么一回，我明白了在生产环境下可千万不能这么做，呵呵。

有没有在打开目录的时候，出现类似下面的错误？

无法打开位置“file:///home/dong" 没有注册为处理此文件的应用程

如图所示：

解决办法：

第一种，麻烦一些，编辑～/.local/share/applications/mimeapps.list

在文件尾增加一行配置即可

inode/directory=nautilus-folder-handler.desktop;nautilus-browser.desktop;

第二种，很方便，

随便找到一个目录，选中后点击右键，应该有一项就叫“使用其它程序打开...”菜单项，点击它后选择“文件浏览器”，确定即可。

GParted是一个很帅的分区工具，因为最近看着我那3G多的swap分区总觉得很不舒服，想缩小一些，分1G给它用足够了，另外2G可以做一个小的文件分区，就研究了两个晚上。

为了调整swap分区的大小，需要做一个Live usb（cd也可以），但是下载了当前最新版本0.4.7-1.iso,使用UBUNTU自带的"usb启动盘创建器"做了一个live usb,重启电脑后无法引导,折腾了好几回都不行.

于是又下了它的zip文件,准备参照它的文档手工创建一下live usb,步骤如下:

1. mkfs.vfat -F 32 /dev/sdb1

2.  unzip gparted-live-0.4.5-2.zip -d /media/usb/

3. cd /media/usb/utils/linux

4. makeboot.sh /dev/sdb1

完成后,重启系统,选择使用USB引导,这回能够正常进入了.

这么点儿小东西折腾了我两个晚上,失败啊.

2007年的时候，写过一个blog，Ubuntu下最好用的浏览器 Konqueror

今年已经是2009年了，Google Chrome Linux版发布也有些日子了，这个"最好"应该换人了.

自从在Ubuntu下装了Chrome，基本上很少再用其他的浏览器了，用了这些日子体会如下：

1.速度很好，可以说是很快

2.操作很方便，界面和Windows版相差不大

3.内存占用较小

4.已经可以播放Flash了

鉴于以上几点,满足日常的上网功能已经很不错了,强烈推荐.

在更新的过程中关闭ubuntu，我已经不是第一次了。

以前就有过两回，结果是系统启动不了，修复失败，最后重装了系统。

今天手特别贱，在更新时把窗口管理器给换了，用了几天Gnome Shell感觉别扭，还是换回到熟悉的metacity，换的过程很正常，在终端中执行metacity --replace就可以了,就在这时,我又敲了个ctrl+c,这下可好,整个桌面全死了,什么也操作不了.而这时update-manager应该正在安装新程序,因为硬盘灯闲得厉害,我就在键盘上瞎按,不知道按到哪,系统重启了.

在引导的过程中就不大正常了,屏幕狂闪,连基本的登录都不能进行了.

还好有一个备份的kernal,重启后进入它的修复模式,检查了一下,怀疑安装程序没有完成,把原来的显卡驱动给删除了,新的却没有完成安装,执行这个命令:

sudo dpkg --configure -a

以下是这个操作的说明:

--configure package...|-a|--pending

              Reconfigure  an  unpacked  package.  If -a or --pending is given

              instead of package, all unpacked but unconfigured  packages  are

              configured.

              Configuring consists of the following steps:

              1.  Unpack  the  conffiles, and at the same time back up the old

              conffiles, so that they can be restored if something goes wrong.

              2. Run postinst script, if provided by the package.

果然发现好些新下载的更新包还没有安装完成.

修复完成后,重启,恢复正常,在此留念,以后决不在更新的时候重启系统.

国庆前三天，抽时间把编程卓越之道（第二卷）剩下的部分读完了，读完之后，越发觉得像我这样一直以来几乎只使用Java编程的程序员应该仔细读读，以后有时间应该再重读一遍，呵呵。

最近很忙，昨天休息，晚上就把电脑升级到了Ubuntu 9.10,今天试了一下，发现输入法改成了IBUS,感觉比sci要好用一些，不过无线又用不了，安装了最新的驱动也不管用，将就着先用有线上网了。

明天再继续体验新系统，第一感觉挺好，呵呵。

原文:http://codedependents.com/2009/07/01/top-5-static-analysis-plugins-for-eclipse/ 好像是被拦了，内容如下:

Static Analysis

How is it that static analysis is still a best kept secret while so much lips service is paid to code reviews?  We have long since understood that boring repetitive jobs should be left for the machines, but when it comes to code inspection there seems to be a mental block.  Humans hold the advantage when reviewing architecture, use of design patterns and code organization, but a machine will find when a known null value is dereferenced 100% of the time and that can hardly be said for even the OCD coders I know.  Therefore, I present the top five static analysis tools for Eclipse.  While you might not have the delight of working on a project running continuous integration with a full unit test suite, code coverage, and static analysis, you can at least run your own private versions and rest comfortably knowing you’ve done your best.

Code Coverage

I assume at the very least that you’ve written some unit tests in Junit or maybe TestNG, the next step is to see if you are actually testing enough of your code.  Code coverage has saved me a number of times when I’ve been a little lax in my TDD discipline.  Having written some code, followed by some tests, its very easy to forget that one code branch and fail to exercise it; EclEmma to the rescue.  EclEmma installs a Coverage mode right next to the run and debug modes that are standard to Eclipse.  Simply run your unit test with the Coverage mode and bang, your code shows up bright green, yellow or red, letting you quickly know where you forgot a test or two.

Bytecode Analysis

The next level of analysis comes from the well respected FindBugs tool.  After installing the plugin, FindBugs inspects the actual .class files of your compiled code for well know bugs and other suspicious behavior.  I’m constantly surprised at the lack of false positives and overall quality of the bugs it finds, from comparing strings with ==, to failing to close resources, and more, its spot on.

Code Complexity Analysis

Next in my list of favorites is complexity analysis.  These metrics, from simple lines of code in a method to the lesser know but more powerful Cyclomatic Complexity and Efferent Coupling, are the closest thing to a “stinky code” test that software engineering has come up with.  If you strive for loose coupling and DRY code, then EclipseMetrics is right up your alley.  Once it is installed you will see warnings where your methods are overly long or complex, or your classes are poorly organized.  Let the OCD run wild.

Dependancy Analysis

Dependancies are one of those things that can go unnoticed until they bite you in the rear.  Once circular dependancies creep in it can become incredibly hard to break apart and modularize your code.  This might not seem important in a small to medium sized project but once a project scales up, the need to break it apart becomes critical and keeping your ducks in a line from the get go makes life that much easier.  For this task we employ JDepend4Eclipse.

Source Code Analysis

Finally we come to PMD. This is the twin brother of FindBugs.  Where FindBugs checks the .class file, PMD checks the .java file.  There is a lot of overlap here but you can find some interesting things like unused code that javac might have optimized away in the .class file.

以上工具我目前在用得只有FindBugs,下面我想在工作中应用一下EclipseMetrics, JDepend4Eclipse.应该有帮助，呵呵。

chromium(chrome at linux)真不是一般的快，在Linux下终于有一个用得顺手的浏览器了.

10 Essential SQL Tips for Developers