应用部署为Solaris 10 SMF服务

myapp.xml必须符合/usr/share/lib/xml/dtd/service_bundle.dtd.1规范，其意理解如下：

1. <service_bundle>标签用以告知SMF如何处理myapp.xml文件。本例中myapp.xml是一个manifest文件用以定义SMF服务，所以type赋为“manifest”。同时需要给service_bundle一个名字，一般命名规范是以服务所在安装包名为前缀，所以本例将name赋为“mypackage:myapp”。其实name只要不与系统中已有的相重就可以了，当然对于企业级应用服务应该有一个合适的名字。

2. <service>标签主要定义SMF服务的名称，由于myapp只是一个简单应用，所以name赋为 “application/myapp”。如果myapp是网络服务，则根据命名规范名字应以“network/”开头加myapp，即 “network/myapp”，请参考/var/svc/manifest/下的目录结构以此类推。type当然应赋为“service”。至于 version，根据情况设定，缺省取1。

3. 根据需要SMF服务可以为同一个服务启动多个实例(instance)。比如，在系统中同一种数据库平台可以启动多个服务实例，分别服务于不同的应用；或者同一种WEB服务平台启动多个服务实例，在不同的端口提供不同WEB应用服务等。在SMF框架中只需定义一个SMF service及属性，在同一个service下定义不同的instance和特定属性即可。service下已定义的属性适用于所有instance，但任何一个instance也可以根据需要特定某个或某几个属性。比如增加属性或覆盖service同名属性定义。由于本例非常简单，只需一个服务一个实例就行了，所以采用标签<single_instance/>，所有属性全部采用service中的属性即可。

4. 由于希望myapp服务在系统boot时自动启动，所以将<create_default_instance>标签中enable置为“true”。

5. <dependency>是manifest文件中最难定义的部分，它定义了此服务所依赖的其他资源，包括服务、文件系统等。一个SMF服务根据需要可以定义多个<dependency>，每个<dependency>具有自己的标识名name、grouping、 restart_on、type，以及所依赖的各资源的service_fmri。其中name只是个标识，不相重有意义即可。grouping取值定义了所列其他服务与本资源的依存关系，取值“require_all”是指当所列其他资源全部启动和可用后才能满足本服务启动的要求。restart_on 规定了当所依赖的其他资源发生何种情况时需要重启本服务，取值“none”是指只要本服务处于运行状态就行了，不必考虑所依赖的其他资源的状态是否改变。 type指向依赖资源的类型，比如“service”指服务，“path”指文件系统等。service_fmri指其他服务的FMRI(Fault Management Resource Idengifier)。本例仅需在/tmp目录下生成日志文件，而“milestone/multi-user”所指的运行状态完全可以满足要求，所以 service_fmri设为“svc:/milestone/multi-user”。

有关milestone的概念请参看Solaris Service Management Facility - Quickstart Guide。

6. manifest文件必须定义启动和停止服务的方法，<exec_method>标签即用于此目的。原先利用 /etc/init.d/myapp.sh加合适的参数即可启动和停止myapp，现仍可利用。不过myapp.sh需作小小改动，改动方法请参看下节启停方法客户化。对于启动和停止，分别需要定义两个method，它们的type当然都为“method”，其中一个name设为为“start”， exec表示执行什么动作以完成这个start方法，其动作设为“/export/home/smfdemo/myapp.sh start”。另一个name设为“stop”，由于原脚本是使用pkill命令杀掉myapp进程，所以这里可以直接将“:kill”赋给exec，表示SMF可直接杀掉myapp服务相关的所有进程。timeout_seconds定义了完成启动和停止服务操作所需的最长时间，如果在这个时间内未能完成相应操作，SMF会认为服务存在问题，因为会将服务置为maintenance状态，由人工进行排错。本例中，timeout_seconds设为60 秒足矣。