在ubuntu server里面删除并重新安装munin-node的时候出错: …

在ubuntu server里面删除并重新安装munin-node的时候出错:

Initializing new plugins..Restarting munin-node.. *
Munin-Node appears to be unconfigured.

这样解决:

sudo apt-get remove --purge munin

这样再安装就没有问题了

数据导入的过程也应该是一个“事务Transaction”

上上周导入数据,我们约定了数据格式,写好了导入脚本,进行了充分的测试。但是当天给我们的数据结构却发生了巨大的变化,但是给我们的更新window就是当天,所以我们只能再写程序将格式转化为我们先前约定的格式。我和 @nasiless 同学结对做这件事。经过3、4个小时的努力,转换没问题了,将中间数据转化的操作演练了一下,没啥问题。当准备好停机升级,又从数据提供方得知其中一部分数据是错误的,然后又给我我们一份补丁文件(名-值对,需要覆盖现有值)。我们由于担心重新生成数据非常费时间,所以分析一下补丁对我们操作的影响。@nasiless 同学和我确认应该只影响其中一个中间数据文件,然后写脚本修正了一下。最后我们“成功”导入数据恢复服务了,当时很庆幸居然成功了(那个时候已经是晚上11点了)。当然其中有一部分导入失败的数据(9xx条)我们输出了一份文件准备后面手工输入。

一周后来(期间系统又进来很多新数据),我们发现导入的数据中失败的那部分可能是由于补丁文件也需要应用在另一部分的中间文件上造成的。可是当我们想反推这个过程并重现它的时候,我们发现我们的临时转换脚本(就是把那天修改的数据文件向中间文件转换的程序)居然放在了我的/tmp目录下,而其间我的mac重启过,所以这些脚本已经不见了。剩下的只有那个导入失败的log和映射补丁文件,我们经过推演问题已经变得非常复杂了。几个错误因素结合在一起,数据再回复的确是个非常费脑子的工作。还好经过反复排查,这些结果都是可逆的,不过其中人工操作众多,非常费事。我们也只能硬着头皮做了。因为这个系统还涉及到钱的问题,钱又涉及分帐问题,所以反推非常麻烦。

我们的结果还算好的,因为有方法反退效果。可是最大的问题在于这个过程本身应该是“事务”,必须全部完成或者全部恢复,当时我们的做法没有遵循这个基本的原则。而且我们的导入程序中复用了系统逻辑代码,但是忘记修改事务边界,没有将多个事务join起来,所以造成了脏数据的出现。这个也是后来折腾我们的一个主要原因。

所以教训就是:数据导入操作本身就应该使用事务,确定好所有的事务边界。而且数据导入的流程也应该是一个事务,不应该允许可能出现脏数据的请款存在,因为这种问题往往是追悔莫及的,也就是safe steps的极致。

“刷机惊魂险变砖”始末

周六才到手的G1险些在今天变砖,历程是这样的。内容不专业,不是帮您刷机的,只是告诉您怎样刷坏的。

中午吃饭下楼正巧碰到Andriod牛人“小新(quakelee@twitter)”,吃饭间请他一起研究我新买的G1。小新本人用的也是G1,旁边几位同事也不少G1,刷机大都是由小新帮忙。而小新也欣然接受帮我刷机。

吃饭归来就去我们的“不拆不舒服司机”和“不焊不舒服司机”的小魔屋(SA办公室)刷机。小新看了下我的基本情况,是TIM的西班牙版本机(或者是意大利版),当时的主Rom是hiapk的2.2版本,里面有SPL能够启动Fastboot,副rom不明。

  1. 小新首先察看了一下机器的版本,发现root权限已经有了(俗称“采权”完毕)。因为已经刷了非官方的hipak 2.2 rom所以小新启动检查了刷机的SPL认为这个机器应该比较容易刷新rom。小新首先尝试了刷新SPL到工程版本,后来小新发现这个机器的SPL也能进入3个绿机器人滑滑板的界面,所以小新说这个已经是工程SPL了,可以直接刷新的副Rom(Recovery)到自定义版本的Recovery,这样就可以用它刷主Rom了。
  2. 小新启动了ubuntu,然后让G1进入SPL,连上Fastboot,发现连接一切正常。然后小新就格式化了Recovery分区(fastboot erase recovery),然后小新使用fastboot更新那个自定义recovery,但是出错了,报告signed verify failed,签名错误。小新大呼可能要瞎!他和我解释他没有备份我的recovery,现在无法刷recovery就只有主rom了,而这种情况下面的所有刷机都回困难重重。而且刷不进去自定义rom很有可能是SPL有问题,但是没有了recovery分区就很难刷SPL……
  3. 小新向蛋总求救,听说蛋总身在米国,半夜帮忙,实在感谢。小新咨询了一下当时的情况,发现情况可能比想像中要遭。但是蛋总的意思是这个手机没啥特殊,应该肯定能刷好。小新还去“机锋”和“安卓”论坛寻找有用线索,无果。他尝试了几个不同版本的自定义recovery,都是报告签名错误,包括蛋总推荐的RaMon也不可以。此时气氛凝重,小新告诉我下面每件尝试都是高风险,随时可能变砖。我心想管理员做事谨慎,所以应该不会有问题,充分相信小新。
  4. 死马当活马医,小新发现居然Fastboot现在工作还正常,也能用adb练到手机里面。他与蛋总切磋了一下,蛋总推荐降级,说可以通过fastboot boot recovery.img的方式重启并刷入rom。小新尝试了一下,惊喜的发现居然可以通过这种方法引导进入自定义recovery,当时使用的是RaMon 1.5.2的recovery rom。这个露出了一丝曙光。
  5. 然后小新仔细梳理了一下刷机流程,并对比了他自己的G1,发现问题出在我的baseband和SPL。首先我的baseband是老版本,所以一开始刷入工程版SPL的操作失败了。而后进入的SPL虽然有三个绿色机器人滑滑板界面,但是它是一个新版本的非工程版(或者说官方版本,检测签名的版本)的SPL。它虽然看起来和工程版SPL一样,但是完全不能用来刷自定义rom。
  6. 小新说唯一的出路就是重刷SPL。但是要先升级baseband。其实到了这个地步,我的主rom(hiapk 2.2)还是可以启动的,只是如果不做后面操作一个是以后主rom坏了就再也无法recovery了,再有就是SPL也就无法升级了。所以小新推荐我继续刷机,不过他警告我操作风险很大,我说继续。
  7. 用fastboot boot recovery.img进入自定义recovery,然后刷新了baseband,一开始重启不了了,我们以为要砖。小新想起这个需要重启进入recovery另外一次,所以又fastboot boot了一次recovery,重启就又可以进入主rom系统。也就是说此时机器还是可用,而且离成功进了一步。
  8. 下面要刷SPL,风险很大,小新特意去网上找了一个和它G1一样的版本并检查了md5sum。然后继续fastboot bott recovery.img重启,刷工程SPL很快,小新问了下蛋总这样做没啥风险(用fastboot boot img的方式进入临时recovery刷SPL的这个行为)?蛋总说没有问题。小新重启机器。此时舜佳鹏一两位团队成员跑过来围观,听说现在状况很危急纷纷表示我的机器不会这么容易变“砖”的,但是也幸灾乐祸的表示如果”真得变砖“也不要过度悲伤,然后两人协同超哥去给我买了一瓶美年达。这美年达喝在嘴里那叫一个酸呀,真要砖了那可太心酸了。
  9. 此时心都跳到嗓子眼了。重启后小新用adb试着连,能连上,可以看到引导了。因为这个过程需要再进入recovery两次,所以小新fastboot boot recovery了一次。但是……这次重启后,我俩彻底崩溃了,机器无法引导,adb连上后报错,无法建立连接。所以就不能再次fastboot boot recovery了,那么就瞎了,也就是说砖了。这次小新用低沉的声音和我说:“完了,这次是真砖了……”
  10. 此时屋里鸦雀无声,大家都被“砖了”这个词震惊了,大家纷纷围观过来……我心情无比沉重,小新明显也是,一直和我说对不起。可是我知道这个完全是我造成的,托小新那是找人帮忙,哪有人家帮我的不是。我心想不能给小新压力,故作震惊,说没关系,机器先放在你这里,看看还有啥补救措施啥的,然后我就出去了。
  11. 回到作为先是浑身发冷,然后浑身发热,然后浑身无力。赶紧和老婆用gtalk报告噩耗,还要老婆外出看不到。但是晚上老婆要过来找我看电影,电话不能用了她一定很着急。而且这不是最麻烦的,这是老婆好心怕我手机太破才给我批款子买的,到手里两天,用了还没超过3个小时就变成高科技“板砖”,这是何等可怕的“悲剧”呀,心情一下子十分黯淡。我故作镇静的开始看手头的程序,可是哪有心情呀,幸好pair不在,否则魂不守舍的我肯定会让pair很郁闷。
  12. 恍惚了有半小时还是一个小时?我求助了twitter,有热心朋友帮RT,但是显然也没啥帮助信息出现。心灰意冷呀。此时小新从远处摆出“囧”字脸走向我,和我说:“真的是砖了,你明天拿到村里找奸商看看能否加钱换一个吧。我拿到机器就要拆后盖,其实当时有点恍惚,就像宠物走了想要再检查一遍它的身体一样……超哥和小新阻止了我,并说你先看看机器呀。我一看,发现屏幕居然亮着,系统已经启动了!赛,当时真是喜出望外!

尾声。小新告诉我原来是大胖同学解救了我俩。这个机器按着照相快门键启动就可以引导入SPL,然后就可以刷机,刷机后就好了!所以是大胖救了我们。原因是小新刷的机器都是按return和开机进入SPL,但是大胖的机器按快门和开机进入。所以按照大胖的习惯我的机器就开开了。后来测试发现,我的机器只支持快门+开机进入SPL,而小新的机器只支持return+开机进入SPL,而大胖的机器两个快捷键都可以。所以世界还真是无奇不有。

老婆到达的时候我的G1已经又工作正常了,不过心灵真的受到了打击。一个到手3小时的新G1,居然马上就砖了,本来为了省钱买它,如果再入手一个那还真要用上一个iPhone 3G的价格了,吓人呀。不过还好,修好了,这1850没有打水漂。一个教训就是,下次做这样心跳的事情要多做功课,每一步想好撤退方案再行动,所有危险动作前要double check前置条件是否达到,否则,那还真是一步一步走向“变砖”,连头你都没法回了。

感谢帮助刷机3个半小时的小新,感谢帮助G1起死回生的大胖,感谢资深技术支持蛋总。感谢团队的围观群众舜佳、彭一、远超,还感谢老婆没有责怪我。

刚才好消息传来,居然G1又好了,是在没有Recovery系统的情况下用fastb…

刚才好消息传来,居然G1又好了,是在没有Recovery系统的情况下用fastboot boot recovery.img进recovery系统,然后刷SPL的。但是SPL刷后要重新进入recovery,由于没有,需要再次fastboot boot recovery.img。而后由于我这个版本的机器需要按住照相键重新启动,可是大牛 @quakelele 同学的机器是按住return的,所以一直无法启动,我们都已经以为这只年轻的G1变砖了。我都心灰意冷本来准备掏钱去中关村换的,失落的回到座位开始求助twitter,能看到朋友帮助retweet很感动,可是一时半会儿也没有有效的帮助。还好大胖同学帮忙实验了一下我的“砖”,没想到就正常启动了。他们过来的时候还骗我说只能去中关村了。我拿过来就想拆后盖实验一下,谁知实际上是想给我一个惊喜。机器又正常启动了,换了新的系统……谢谢 @quakelele 、大胖、还有我们team的几位兄弟为了安慰我给我买了美年达。可以放心了。

刚到手第2天,G1砖了,好大的悲剧呀。这次惨了。哥们刷机顺序出了些问题,现在ba…

刚到手第2天,G1砖了,好大的悲剧呀。这次惨了。哥们刷机顺序出了些问题,现在baseband是新的,但是recovery坏掉了,而且SPL也失败了,莫大的悲剧呀。只能看到TIM启动LOGO,然后就卡死了。一筹莫展中。

早上突然看到所谓的2009十大开源软件里面有一个Suse Studio,它是一个…

早上突然看到所谓的2009十大开源软件里面有一个Suse Studio,它是一个很有趣的项目。仔细看了看它支持software applicance,也就是把一个定制的Suse studio distro作为一个虚拟机镜像,运行在自己的Hypervisor上面。维基百科果真是好东西,解释了一下这个听起来有点耳熟,看起来才发现很熟悉的东西。其实它就是虚拟机的运行环境管理器,而且它有两种主要形式(Type1, Type2)。Type 1是一个固件层应用,它直接工作在硬件上面,并为Guest系统(guest operating system)提供运行环境,并监控Guest系统的运行状态,像Xensource的xen控制器,VMware ESX都属于这一类。而Type2就是工作在操作系统上的一个Guest系统运行环境,不直接工作在硬件上层,我们常用的VMWare workstation和Fusion,还有Virtual box就是这一类。所以Hypervisor就是运行环境的管理工具,当然也要提供相应的虚拟运行环境。以后企业内部对在虚拟环境下运行的linux distro的需求会大增,像Suse studio这样的提供在网站自定义distro的服务一定会很受欢迎!

HTC版G1到手了,黑色。昨天到今天一共操作了也就是20分钟,家务活好多呀。刚才…

HTC版G1到手了,黑色。昨天到今天一共操作了也就是20分钟,家务活好多呀。刚才才搞定了无线网连接,我家是的802.11n的wifi,但是昨晚G1一直找不到ssid,手动输入还是连不上。刚才看到有人说要11g才能连,我就把ap修改为802.11a/b/g混合模式,果真能够找到ssid,也能wifi上网了,然后就开始去market扫荡了。昨晚开着EDGE网络,结果早上就欠费了……幸好本来余额不多。下个月要开个150MB包月了。

我真的很讨厌Python的缩进语法,我真的不明白它为啥会存在。没啥美感可言,带来…

我真的很讨厌Python的缩进语法,我真的不明白它为啥会存在。没啥美感可言,带来的是无尽的烦恼。你经常要担心python解释器是否因为我的输入错误产生一些诡异的问题(虽然大部分不是因为这个问题)。不过这增加了很多无形的压力。I have python’s force indentation, it make me sick!

关于Textmate:我的同事都很不喜欢Textmate,总结并回复一下他们所说…

关于Textmate:我的同事都很不喜欢Textmate,总结并回复一下他们所说的原因。

  • 中文显示难看,这个是暂时解决不了的问题,是TM的硬伤。我也很讨厌它,凑合使用瘦体解决。
  • 讨厌它的上下文切换,不喜欢Cmd + T的快速导航,而喜欢左右Tab切换。我坚持认为左右切换Tab是开发者的一个坏习惯,尤其是两个人在结对编成的时候,一个使用缩写的导航远比眼花缭乱的切换左右(尤其是跨越多个的时候)要容易理解的多。所以我在使用Eclipse的时候也推荐同事使用Cmd + e,可是Eclipse让我不喜欢的地方是它排列context的方式是固定的,而不像TM一样是根据访问次序和频度。
  • Django的结构的文件名重复,所以Cmd + T的导航不太好用。这个我想是Django的一个痼疾,非常不友好。一个正确的文件命名可以帮助开发者快速定位代码片段,也帮助你把庞大的代码文件差分开。而Django居然默认了views.py、models.py、forms.py、urls.py,如果每样都有十几个到几十个的时候定位他们是多么烦人的一件事?但是如果有了一个正确的命名以后,用缩写定位他们是TM的杀手锏。相比之下Eclipse和Intellij都使用的是类似grep的搜索方式,只有TM是更聪明的模式匹配。
  • 同事讨厌TM的目录树显示,很小,而且目录排列是按照字表顺序,很不舒服。我觉得我的确也不喜欢它,可是幸运的是我很少和它打交道,因为目录操作我大部分情况下都使用Terminal。还有个很爽的功能就是在TM里面你用Cmd + T打开一个文件以后可以按Ctrl + Cmd + r在目录树中定位这个文件。所以终极使用方案就是搜索优于人工扫描目录。
  • 有人感觉TM的语法高亮差,也有人balme TM的HTML bundle里面连a的内置模板都没有。的确如此,可是1来你可以自己扩展,二来是在Eclipse里面我的同事估计从来没有用过任何快速模板功能……
  • Rails的自动完成是基于上下文的,我觉得大部分时候它已经很够用了。不过没有静态语法检查好像的确是不如Eclipse的Pydev,但是速度上TM从此收益要快于Pydev很多。
  • 最后是版本控制集成。同事们很喜欢Eclipse内置的Subclipse和Subversive,不过这两个东西我都很讨厌,因为如果你没有配置好Java HL的方式访问Svn,那么你就不能在命令行使用svn,否则你的svn功能就会崩溃。我简直想诅咒这个倒霉的问题……相比之下用了Textmate,你有天然的svn bundle,还可以轻松安装hg和git的bundle,让你的开发很清爽。而且它对于在极力推荐git svn转型的情况下非常适合。反正源代码集成功能不是我选择Eclipse的理由,反而是我放弃它的理由。
  • 命令行下的mate让我工作变得很轻松,因为mate .马上就可以开一个新的TM工程,很便捷,轻量。
  • 最后是Python的tabs和space缩进。TM处理的很好,只要你设置Soft tabs ( 4 spaces)使用起来就没有问题了。

最近被开发团队的成员blame的几个错误: 一个从老系统导入新系统的脚本,其中…

最近被开发团队的成员blame的几个错误:

  • 一个从老系统导入新系统的脚本,其中一些是订单导入,还涉及到相关订单的支付问题。结果这个脚本创建订单和支付的操作没有声明事务,而是默认的在它们自己的事务完成后自动提交。结果其中一些因为帐户余额不足无法支付的订单被创建了,造成账目对不上。这个错误的教训就是在复用系统逻辑的时候一定要用心察看事务边界,而且对于导入脚本这样的脚手架也一定要对“事务”有个弦,不能忽略。
  • 一个Django的项目,在重构阶段,一些包正在逐渐被移动到心的地方,我们测试环境中manage.py runserver这几日都正常,但是部署的时候发现mod_python部署报告一个模型无法Import,而后同事又换了mod_wsgi,但是问题依旧。他们用bisect的方法找到了开始出问题的revision,这个revision是我提交的(我那天solo),但是仔细看了diff也很难找到问题,经过多次尝试发现是某一个import后出问题。先开始李明同学怀疑是我用textmate的时候混用了tab和space,但是后来发现问题不它。他们最后定位到这个诡异的问题是循环依赖造成的,虽然说不出具体的问题在哪里,但是经过一些包移动后问题解决了。这个教训是不要太相信Django和脆弱的Python的提示,遇到问题要多怀疑python脆弱的包依赖管理。当然这不是主要问题,对于这个问题也许我们要做的是频繁的部署,这样我们就能早些发现这个问题了。