2811 月 2014

Fix for Chrome crash in Yosemite 10.10.2

by flavorzyb

Temporary fix

Put the following in a file “patch.m”:

#import <AppKit/AppKit.h>
__attribute((constructor)) void Patch_10_10_2_entry()
{
NSLog(@”10.10.2 patch loaded”);
}
@interface NSTouch ()
– (id)_initWithPreviousTouch:(NSTouch *)touch newPhase:(NSTouchPhase)phase position:(CGPoint)position isResting:(BOOL)isResting force:(double)force;
@end
@implementation NSTouch (Patch_10_10_2)
– (id)_initWithPreviousTouch:(NSTouch *)touch newPhase:(NSTouchPhase)phase position:(CGPoint)position isResting:(BOOL)isResting
{
return [self _initWithPreviousTouch:touch newPhase:phase position:position isResting:isResting force:0];
}
@end

Compile it:

clang -dynamiclib -framework AppKit patch.m -o patch.dylib

Use it:

env DYLD_INSERT_LIBRARIES=/path/to/patch.dylib “/path/to/Google Chrome.app/Contents/MacOS/Google Chrome”

Safer way

A safer way would be to copy the 10.1.1 AppKit.framework and create as a local framework for just Google Chrome:

cd /Applications/Google Chrome.app/Contents/
mkdir Frameworks
cp -R path-to-10.1.1/AppKit.framework Frameworks/
install_name_tool -change /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit @executable_path/../Frameworks/AppKit.framework/Versions/C/AppKit MacOS/Google Chrome

link: http://www.reddit.com/r/apple/comments/2n721c/temporary_fix_for_chrome_crash_in_yosemite_10102/

1111 月 2014

防止linux出现大量 FIN_WAIT1,提高性能

by flavorzyb

当连接数多时，经常出现大量FIN_WAIT1,可以修改 /etc/sysctl.conf

修改

net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0

然后:

/sbin/sysctl -p

使之生效

#######################################################################################

apache服务器的time_wait过多 fin_wait1过多等问题

1。time_wait状态过多。

通常表现为apache服务器负载高，w命令显示load average可能上百，但是web服务基本没有问题。同时ssh能够登陆，但是反应非常迟钝。

原因：最可能的原因是httpd.conf里面keepalive没有开，导致每次请求都要建立新的tcp连接，请求完成以后关闭，增加了很多 time_wait的状态。另，keepalive可能会增加一部分内存的开销，但是问题不大。也有一些文章讨论到了sysctl里面一些参数的设置可以改善这个问题，但是这就舍本逐末了。

2。fin_wait1状态过多。fin_wait1状态是在server端主动要求关闭tcp连接，并且主动发送fin以后，等待client端回复ack时候的状态。fin_wait1的产生原因有很多，需要结合netstat的状态来分析。

netstat -nat|awk ‘{print awk $NF}’|sort|uniq -c|sort -n

上面的命令可以帮助分析哪种tcp状态数量异常

netstat -nat|grep “:80″|awk ‘{print $5}’ |awk -F: ‘{print $1}’ | sort| uniq -c|sort -n
则可以帮助你将请求80服务的client ip按照连接数排序。

回到fin_wait1这个话题，如果发现fin_wait1状态很多，并且client ip分布正常，那可能是有人用肉鸡进行ddos攻击、又或者最近的程序改动引起了问题。一般说来后者可能性更大，应该主动联系程序员解决。

但是如果有某个ip连接数非常多，就值得注意了，可以考虑用iptables直接封了他。

解决linux下大量的time_wait问题

vi /etc/sysctl.conf
编辑/etc/sysctl.conf文件，增加三行：

引用

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.route.gc_timeout = 100
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1

说明：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
再执行以下命令，让修改结果立即生效：

引用
/sbin/sysctl -p

用以下语句看了一下服务器的TCP状态：

引用
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
返回结果如下：
ESTABLISHED 1423
FIN_WAIT1 1
FIN_WAIT2 262
SYN_SENT 1
TIME_WAIT 962
效果：处于TIME_WAIT状态的sockets从原来的10000多减少到1000左右。处于SYN_RECV等待处理状态的sockets为0，原来的为50～300。

通过上面的设置以后，你可能会发现一个新的问题，就是netstat时可能会出现这样的警告：

引用
warning, got duplicate tcp line
这正是上面允许tcp复用产生的警告，不过这不算是什么问题，总比不允许复用而给服务器带来很大的负载合算的多

尽管如此，还是有解决办法的：
1、安装rpm包：
[root@root2 opt]# rpm -Uvh net-tools-1.60-62.1.x86_64.rpm
Preparing… ########################################### [100%]
1:net-tools ########################################### [100%]
[root@root2 opt]#

对于下载的是源码的rpm则需要使用以下方法安装：

2、安装rpm源码包方法：
a)         安装src.rpm:
# [root@root1 opt]# rpm -i net-tools-1.60-62.1.src.rpm
……
b)        制作rpm安装包：
[root@root1 opt]# cd /usr/src/redhat/SPECS/
[root@root1 SPECS]# rpmbuild -bb net-tools.spec
c)        rpm包的升级安装：
[root@root1 SPECS]# pwd
/usr/src/redhat/SPECS
[root@root1 SPECS]# cd ../RPMS/x86_64/
[root@root1 x86_64]# rpm -Uvh net-tools-1.60-62.1.x86_64.rpm

3、再使用netstat来检查时系统正常：
说明：
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。
net.ipv4.route.gc_timeout = 100 路由缓存刷新频率，当一个路由失败后多长时间跳到另一个
默认是300
net.ipv4.tcp_syn_retries = 1 对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右。

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

link: http://blog.chinaunix.net/uid-8786588-id-3663436.html

0911 月 2014

Mac下Sublime text3065破解

by flavorzyb

Mac下3065破解方法

使用vi打开SublimeText

使用命令:%!xxd 转换搜索 3342 3442 替换成 3242 3442

:%!xxd -r转回

:wq保存退出

—– BEGIN LICENSE —–
Andrew Weber
Single User License
EA7E-855605
813A03DD 5E4AD9E6 6C0EEB94 BC99798F
942194A6 02396E98 E62C9979 4BB979FE
91424C9D A45400BF F6747D88 2FB88078
90F5CC94 1CDC92DC 8457107A F151657B
1D22E383 A997F016 42397640 33F41CFC
E1D0AE85 A0BBD039 0E9C8D55 E1B89D5D
5CDB7036 E56DE1C0 EFCC0840 650CD3A6
B98FC99C 8FAC73EE D2B95564 DF450523
—— END LICENSE ——

link: http://zhixinhu.blog.51cto.com/3132199/1546931

0711 月 2014

TCP连接异常断开的检测

by flavorzyb

TCP是一种面向连接的协议，连接的建立和断开需要通过收发相应的分节来实现。某些时候，由于网络的故障或是一方主机的突然崩溃而另一方无法检测到，以致始终保持着不存在的连接。下面介绍一种方法来检测这种异常断开的情况

1) 在TCP协议中提供了KEEPALIVE检测。该选项使能后，在一个TCP连接上，若指定的一段时间内没有数据交换，则自动发送分节等待对方确认。

SO_KEEPALIVE : 该选项设置是否打开探测
TCP_KEEPIDLE : 开始发送探测分节前等待的空闲时间
TCP_KEEPINTVL: 两次发送探测分节的时间间隔
TCP_KEEPCNT: 判定断开前发送探测分节的次数

2) 设定探测相关选项值

     int keepalive = 1;             // 打开探测
int keepidle = 60;        // 开始探测前的空闲等待时间
int keepintvl = 10;        // 发送探测分节的时间间隔
int keepcnt = 3;        // 发送探测分节的次数

3) 设置套接字的属性

if (setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepalive, sizeof (keepalive) < 0)
{
perror(“fail to set SO_KEEPALIVE”);
exit(-1);
}
if (setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void *) &keepidle, sizeof (keepidle) < 0)
{
perror(“fail to set SO_KEEPIDLE”);
exit(-1);
}
if (setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepintvl, sizeof (keepintvl) < 0)
{
perror(“fail to set SO_KEEPINTVL”);
exit(-1);
}
if (setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepcnt, sizeof (keepcnt) < 0)
{
perror(“fail to set SO_KEEPALIVE”);
exit(-1);
}

一旦打开KEEPALIVE探测，当TCP连接异常断开后，对sockfd进行recv操作会返回-1，并且errno的值为ETIMEDOUT。

这样一来就可以很方便的在应用程序中检测TCP连接的情况，如果检测到异常断开最简单的处理就是关闭连接。

link: http://www.embedu.org/Column/Column318.htm

0511 月 2014

Erlang开发MMO的一些思考

by flavorzyb

有利的部分

erlang是好的，吸引了很多人的兴趣。不少人甚至将erlang体系的影响带到了自己所在的其他语言项目中，构建一些类似erlang的基础设施。包括我。

随意挥霍的process。端游从早期的单进程支持一个游戏服，发展到现在的多进程支持一个游戏服。其中涉及多个进程协作的逻辑越来越多，异步任务相互之间由于时间差带来的问题也越来越频繁。
通常我总会利用状态机或者类似的办法管理异步任务，但并不能顾及到每一处，而且状态机增加了理解代码的难度。
erlang轻量的process使我能为每个异步任务创建一个独立的执行过程，同时变量不可变的机制几乎消除了多线程中的资源共用的问题。
发送消息太简单。
用C++，发送消息从socket干起，还只能发给一个真正的系统进程，然后switch分发处理。
在异步任务逐渐增多的环境下，有时候很希望语法糖是：能将消息发送给某个异步任务。需要消息平台是一种逻辑上的抽象，而不是底层的socket。
这个可以C++包装一个，而erlang提供了一个极其完善的面向process的消息系统，process又可以映射到异步任务中。
ETS，还有Mnesia，it’s great
在多进程支持一个游戏功能的情况下，有大把的数据需要在不同的进程之间同步共享。也用C++包装一个类似的系统能降低很多重复的数据同步工作。
erlang提供了ETS甚至Mnesia，几乎无条件的为我们提供了数据的分布、持久和恢复。

困难的部分

用erlang开发游戏最困难的地方就是实现场景逻辑。这里没有异步任务，这里是效率、指针和角色相互操作的天堂，但是对erlang来说可能是地狱。
常见的是player/NPC角色之间的立即相互修改，从地图区域查询一批player/NPC角色等。在指针环境下这些操作非常有效率。
一个实时战斗的MMORPG要求核心逻辑要达到25帧/S，区域地图在线1000人。

如果我们为每个player/NPC映射到process用于交互，那么他们必然使用消息去操作访问对方。这很美，但是效率不行。因为player/NPC的操作访问实在太频繁了，这一来erlang就变成一个消息繁忙的系统，真正的游戏计算反而耽误了。
每个场景一个process，场景中所有的player/NPC集中保存到tuple,list中，通过参数传递。
这样具体操作player/NPC的数据确实快了，但是erlang的原生list类型不是利于搜索的类型，这一趟趟查下来也就将计算时间花光光了。
另外通过参数传递也会导致每个相关的子函数都要留一个口子。
每个场景一个process，场景中的所有player/NPC都保存到进程字典中。
进程字典的存取速度在erlang中算快了，插入100ns，查询40ns。ETS的速度是us。参见进程字典到底有多快

游戏的三种逻辑

如果要用erlang来做MMORPG，那规划一下游戏的基本逻辑模块，根据模块的特性选择不同的erlang模式，是有意义的。像C++那样一种模式就行得通的做法，并不适用于erlang。

自我修改逻辑
比如升级，强化之类，就是改改自己的属性，改改自己的技能。
这种逻辑erlang可以为每个player/NPC创建process负责，也可以一个process处理多个player/NPC的类似逻辑。客户端对于这种操作的延时总能容忍1,2秒，慢慢来，性能没关系。
低频角色交互逻辑
比如组队，领取任务，NPC思考等等，角色需要相互操作对方数据。同样也是延时容忍较高，可以尽情发挥erlang在这种交互逻辑中的异步任务支持能力。
高频角色交互逻辑
同一个场景中，角色交互频率最高的就是移动和战斗。
移动影响相互间的视野，战斗则直接读取修改彼此的数据。不要忘了，1000人25帧/S的计算。

移动和战斗

这一块比较纯粹，由一个process为一个场景的player/NPC提供服务，基本上有下面几样内容就搞定计算：

pos,角色坐标
atb,角色属性
skill,技能列表
state,状态列表
同屏表
地图数据
事件列表

前4条属于角色数据，简单操作即可。
同屏表通过四叉树管理角色的空间，为各种类型的群攻判定提供快目标的快速查询。
地图数据为角色检测技能释放的空间合法性，以及战斗寻路。
事件列表则每帧更新技能、状态等数值的计算。

效率优化

仅仅是纯粹的技能效果计算，erlang在虚拟机上的效率肯定不及C++。不过属性计算这块要求的性能并不高，猜测还是能扛下这个计算。
费时、难写的计算可能有两块，同屏表和地图数据。
erlang的数据类型很难高效的处理关系型结构，空间四叉树和地图三角关系用erlang实现起来相当凑合。那么，同屏表和地图的功能到底作为场景战斗process的一个功能，还是以独立process的形式服务呢？
process发送消息的性能大概是1us。
通常一个角色的一次战斗计算需要访问同屏表和地图功能各一次，4us。1000人的话是4ms。1帧40ms，那么每帧大概有30ms左右的时间用于完整的战斗计算，包括同屏计算和地图计算。
为了进一步提高同屏计算和地图计算的性能，可以用C++实现erlang的内置函数。此外，原先逐个角色串行计算同屏功能和地图功能，可以改并行：

先收集全部角色的同屏计算需求
将全部计算需求均匀发送到多个同屏表process进行计算
一边收集结果一边继续计算剩下的战斗部分。

地图计算也采用类似的并行处理，即可提高效率。

link: http://www.erlang-cn.com/807.html

0111 月 2014

Mac OS启动服务优化高级篇

by flavorzyb

Mac下的启动服务主要有三个地方可配置：

1，系统偏好设置->帐户->登陆项

2，/System/Library/StartupItems 和 /Library/StartupItems/

3，launchd 系统初始化进程配置。

前两种优化比较简单，本文主要介绍的是第三种更为复杂的launchd配置优化。

launchd是Mac OS下，用于初始化系统环境的关键进程。类似Linux下的init, rc。

我们先来看一下Mac OS X的启动原理：

1，mac固件激活，初始化硬件，加载BootX引导器。

2，BootX加载内核与内核扩展(kext)。

3，内核启动launchd进程。

4，launchd根据 /System/Library/LaunchAgents , /System/Library/LaunchDaemons , /Library/LaunchDaemons, Library/LaunchAgents , ~/Library/LaunchAgents 里的plist配置，启动服务守护进程。

看完了Mac OS X的启动原理，我们不难发觉 /System/Library/LaunchAgents , /System/Library/LaunchDaemons , /Library/LaunchDaemons, Library/LaunchAgents 五个目录下的plist属性文件是优化系统的关键。

下面再来理解几个基础概念：

/System/Library和/Library和~/Library目录的区别?

/System/Library目录是存放Apple自己开发的软件。

/Library目录是系统管理员存放的第三方软件。

~/Library/是用户自己存放的第三方软件。

LaunchDaemons和LaunchAgents的区别?

LaunchDaemons是用户未登陆前就启动的服务(守护进程)。

LaunchAgents是用户登陆后启动的服务(守护进程)。

上面提到的五个目录下的plist文件格式及每个字段的含义：

Key	Description	Required
Label	The name of the job	yes
ProgramArguments	Strings to pass to the program when it is executed	yes
UserName	The job will be run as the given user, who may not necessarily be the one who submitted it to launchd.	no
inetdCompatibility	Indicates that the daemon expects to be run as if it were launched by inetd	no
Program	The path to your executable. This key can save the ProgramArguments key for flags and arguments.	no
onDemand	A boolean flag that defines if a job runs continuously or not	no
RootDirectory	The job will be chrooted into another directory	no
ServiceIPC	Whether the daemon can speak IPC to launchd	no
WatchPaths	Allows launchd to start a job based on modifications at a file-system path	no
QueueDirectories	Similar to WatchPath, a queue will only watch an empty directory for new files	no
StartInterval	Used to schedule a job that runs on a repeating schedule. Specified as the number of seconds to wait between runs.	no
StartCalendarInterval	Job scheduling. The syntax is similar to cron.	no
HardResourceLimits	Controls restriction of the resources consumed by any job	no
LowPriorityIO	Tells the kernel that this task is of a low priority when doing file system I/O	no
Sockets	An array can be used to specify what socket the daemon will listen on for launch on demand	no

看不懂上面地plist配置吗?没关系，我们的优化策略是完全卸载服务，所以我们不用关心plist里的配置含义。

开始优化禁用服务，我们需要用到Mac OS提供的一个工具指令-launchctl

launchctl 指令会针对服务设置一个禁用标志，launchd启动时会先检查这个服务是否被禁用，从而确定是否需要启用这个服务。

禁用服务的方法1

先找到禁用标志文件 /var/db/launchd.db/com.apple.launchd/overrides.plist，查看你要禁用的服务是否已被禁用了。

有些服务已被禁用，但未列在overrides.plist里。此时，你还需要检查这个服务的plist文件Label字段是否已经标记为 Disable。

确认这个服务未禁用后，我们就可以通过调用如下命令，来禁用服务：

sudo launchctl unload plist文件路径

sudo launchctl unload -w plist文件路径

比如，我想禁用spotlight，则输入

sudo launchctl unload /System/Library/LaunchAgents/com.apple.Spotlight.plist

sudo launchctl unload -w /System/Library/LaunchAgents/com.apple.Spotlight.plist

禁用完服务以后，重启Mac OS即可生效。

禁用服务的方法2，一种更有效且暴力的方法(推荐)

先卸载服务

sudo launchctl unload /System/Library/LaunchAgents/com.apple.Spotlight.plist

然后将plist文件mv到其他目录备份。重启。搞定。是不是很简单!

我个人比较喜欢这种禁用服务的方式，所以推荐一下。

如果发现服务禁用后，系统或软件出现异常，可以通过如下命令，还原服务：

方法1:

sudo launchctl load -wF plist文件路径

方法2:

将备份的plist文件mv回原来的文件夹。

sudo launchctl load plist文件路径

注意：系统级服务的禁用要异常小心，请在禁用前google，确保你熟知这个服务的作用。否则可能导致系统无法启动。

最安全的做法就是不要去禁用它了。

当然，用户服务我们还是可以放心禁用的，有问题最多再启用呗。

下面是我禁用的服务列表：

/System/Library/LaunchDaemons/com.apple.metadata.mds.plist (禁用spotlight的前提)

/System/Library/LaunchAgents/com.apple.Spotlight.plist (Spotlight)

/Library/LaunchDaemons/com.google.keystone.daemon.plist (Google Software Update)

/Library/LaunchAgents/com.google.keystone.root.agent (Google Software Update)

~/Library/LaunchAgents/com.google.keystone.agent.plist (Google Software Update，用户下的进程不需要加 sudo)

~/Library/LaunchAgents/com.apple.CSConfigDotMacCert-ken.wug@me.com-SharedServices.Agent.plist (me.com的共享服务，我不用)

/System/Library/LaunchDaemons/org.cups.cupsd.plist (打印机)

/System/Library/LaunchDaemons/org.cups.cups-lpd.plist (打印机)

/System/Library/LaunchDaemons/com.apple.blued.plist (蓝牙)

/System/Library/LaunchAgents/com.apple.AirPortBaseStationAgent.plist (apple无线基站，我没有这个设备)

知道守护进程(服务)名，如何找到对应的plist文件?

将进程(服务)名拷贝，然后到 /System/Library/LaunchAgents , /System/Library/LaunchDaemons , /Library/LaunchDaemons, Library/LaunchAgents , ~/Library/LaunchAgents 五个目录里，通过以下命令查找：

ll|grep 进程(服务)名

比如

ll|grep blued

在 /System/Library/LaunchDaemons 中找到了它。接下来，请按上面指导的步骤，禁用该服务。

link: http://www.3lian.com/edu/2013/04-26/67191.html

0111 月 2014

三种方式配置Mac OS X的启动项

by flavorzyb

在Mac OS X中，有三种方式来实现启动项的配置：1）Login Items；2）StartupItems；3）launchd daemon。

1.Login Items

打开System Preferences，选择System -> Accounts，选择Login Items选项卡，将/Applications目录下的.app直接拖进右边的列表中。重启电脑之后就会发现列表中的程序在开机之后就自动启动了。

2.StartupItems

StartupItems，顾名思义，就是在系统启动过程中运行的程序，它们可以是运行完就立即终止的程序（比如，开机清空废纸篓），也可以是一直持续在系统运行周期的后台进程。

StartupItems一般存放在以下两个路径下：

1）/System/Library/StartupItems

2）/Library/StartupItems

大部分与系统相关的StartupItems都放在/System/Library/StartupItems这个路径下，它们会先于/Library/StartupItems路径下的执行，因为前者路径下的StartupItems提供了系统级的基础服务，比如crash reporting，core graphics services，system accounting等，而后者路径在默认情况下是不存在的，需要自己手动创建。

这里我们以/Library/StartupItems目录下的IcebergControlTower为例。

简单来说，在Mac OS X上，一个StartupItems包含以下两个方面的内容：

1）可执行程序；

2）包含依赖进程关系的plist文件（StartupParameters.plist）。

2.1 The Property List

2.1.1 Plist的key值与含义

StartupParameters.plist 是一个属性列表，包含了运行可执行程序的必要条件。

该plist需要获得root权限，包含了几个方面的内容：

1）Description；

对该服务的一个简单的描述，仅仅是描述，并不是说明实际的进程名称。

2）Provides；

指定StartupItems提供的服务。如图plist文件Provides中说明，StartupItems开启的后台进程名为：Iceberg Control Tower。

Provides可以指定多个服务，反映在图中就是Item0，Item1…等。这里只有Item0。

3）Uses；

指定了在StartupItems加载之前需要开启的服务。Mac OS X系统先尝试着加载Uses中指定的服务，然后再加载StartupItems。也就是说，即使Uses中指定的服务没有加载成功，系统仍然会加载StartupItems。

4）OrderPreference；

指定执行StartupItems的时间顺序。这个顺序的重要程度排在Uses之后，是指定执行完Uses之后的顺序。可能的取值包括：First, Early, None(default), Late, Last。

5）Messages。

2.1.2 创建一个StartupParameters.plist文件

[html] view plain copy

<?xml version=“1.0” encoding=“UTF-8”?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN”
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=“1.0”>
<dict>
<key>Description</key>
<string>Iceberg Control Tower Initilaization</string>
<key>Provides</key>
<array>
<string>Iceberg Control Tower</string>
</array>
<key>Uses</key>
<array>
<string>Disks</string>
</array>
<key>OrderPreference</key>
<string>None</string>
</dict>
</plist>

2.2 The Executable File

注意：1）可执行文件的名称和它所在的文件夹的文件名是一样的，这是系统默认的规则。

2）操作可执行文件需要获得root权限。

3）可执行文件是一个shell脚本。

打开IcebergControlTower文件目录下同名的可执行文件，可以看到脚本的具体内容：

一般的可执行文件包含这样几个方面的内容：

1）./etc/rc.common

Apple提供的一个脚本库，该脚本库里包含了为可执行文件引进参数的接口。在这里load这个库主要是调用RunService。

2）StartService(), StopService(), RestartService()

当可执行文件接收到的参数为start，stop或者restart时，执行相对应的函数。

参数含义：

start：开机过程中开启服务；

stop：关机过程中停止服务；

restart：在特定条件下重启服务。

3）RunService “$1”

执行传递给该脚本的第一个参数指定的服务。

“$1” 表示传给该脚本的第一个参数。例如，传入的参数为start，则执行StartService()。

3. Launchd Daemon

launchd是Mac OS下用于初始化系统环境的关键进程，它是内核装载成功之后在OS环境下启动的第一个进程。

采用这种方式来配置自启动项很简单，只需要一个plist文件，通常（同时也是系统推荐）是将plist放在~/Library/LaunchAgents路径下。

3.1 plist文件格式及每个字段的含义：

1）Label【required】

该项服务的名称。

2）OnDemand【optional】

10.4提供的一个key值，功能与KeepAlive的基本功能相似，在10.5及之后的系统中被KeepAlive替代。KeepAlive扩展了更多的功能，除了使用单一的boolean作为key值之外，还能使用字典结合多个key值。

3）Program【ProgramArgument是required的，在没有ProgramArgument的情况下，必须要包含Program这个key】

指定可执行文件的路径。

4）RunAtLoad【optional】

标识launchd在加载完该项服务之后立即启动路径指定的可执行文件。默认值为false。

5）WorkingDirectory【optional】

该key在开启可执行文件之前，指定当前工作目录的路径。

6）KeepAlive【optional】

这个key值是用来控制可执行文件是持续运行呢，还是满足具体条件之后再启动。默认值为false，也就是说满足具体条件之后才启动。当设置值为ture时，表明无条件的开启可执行文件，并使之保持在整个系统运行周期内。

3.2 创建一个plist文件：

[html] view plain copy

<?xml version=“1.0” encoding=“UTF-8”?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN”
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=“1.0”>
<dict>
<key>Label</key>
<string>com.yourcompany.HSPA_USB_MODEM</string>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/Application/HSPA USB MODEM.app/Running</string>
<key>RunAtLoad</key>
<true/>
<key>WorkingDirectory</key>
<string>/Application/HSPA USB MODEM.app</string>
</dict>
</plist>

4.三种方式的区别

初步了解了系统的启动过程之后（http://blog.csdn.net/abby_sheen/article/details/7817132），再来看这三种配置启动项的方式，就很容易理解这三种方式之间的差异了。

总的来说，LoginItems 和StartupItems的区别较明显。

	StartupItems	LoginItems
Depedency Ordering	Need	Do not Need
Load Timing	during startup	after a user logs in
Launched by WHO	by root, but not necessarily	the user
Processes types	background processes and processes that terminate after running	any Mac OS X executable

对于我们自定义的Launchd daemon，通常（同时也是系统推荐）是放在~/Library/LaunchAgents路径下。launchd进程需要在用户login之后才能加载。这种方式与LoginItems最大的区别在于，启动的进程不同。LoginItems是通过loginwindow去启动的，而Launchd daemon是通过com.apple.launchd.peruser启动。

link: http://blog.csdn.net/abby_sheen/article/details/7817198

2014 年 11 月
日	一	二	三	四	五	六
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

Monthly Archives: 11 月 2014

Fix for Chrome crash in Yosemite 10.10.2

Temporary fix

Safer way

防止linux出现大量 FIN_WAIT1,提高性能

Mac下Sublime text3065破解

TCP连接异常断开的检测

Erlang开发MMO的一些思考

有利的部分

困难的部分

游戏的三种逻辑

移动和战斗

效率优化

Mac OS启动服务优化高级篇

三种方式配置Mac OS X的启动项

1.Login Items

2.StartupItems

2.1 The Property List

2.1.1 Plist的key值与含义

2.1.2 创建一个StartupParameters.plist文件

2.2 The Executable File

3. Launchd Daemon

3.1 plist文件格式及每个字段的含义：

3.2 创建一个plist文件：

4.三种方式的区别