The Base SmartOS Zone

The Base SmartOS Zone

SmartOS Zones make for excellent blank slates to do development or production work from.

Except as it turns out, they're not blank slates.  The two most minimal Zone images, base and minimal start out with over a dozen running processes on them.

What are those processes and what functionality do they provide?  Which of them can we disable if we need or want to?


Since SmartOS Zones version 16.2.0 released yesterday, let's spin up a base Zone image and check out our running processes.

Here's the manifest I used for this demonstration:

        "brand": "joyent",
        "image_uuid": "13f711f4-499f-11e6-8ea6-2b9fb858a619",
        "alias": "base_test",
        "hostname": "base_test",
        "max_physical_memory": 256,
        "quota": 20,
        "resolvers": [ "", "" ],
        "nics": [ {
                        "nic_tag": "admin",
                        "ip": "dhcp"
                } ]


Notice: I performed this test using version 16.2.0 of both base-64 and minimal-64.  Besides a few slight deviations (minimal calls rsyslogd -c5 -n and base does not) all running processes were the same.

Immediately after logging in, I polled the process list:

# ps ax
  7239 ?        S  0:00 zsched
  7299 ?        S  0:00 /sbin/init
  7323 ?        S  0:00 /lib/svc/bin/svc.startd
  7328 ?        S  0:02 /lib/svc/bin/svc.configd
  7384 ?        S  0:00 /lib/inet/ipmgmtd
  7607 ?        S  0:00 /usr/sbin/nscd
  7625 ?        S  0:00 /sbin/dhcpagent
  7626 ?        S  0:00 /usr/lib/pfexecd
  7774 ?        S  0:00 /opt/local/sbin/rsyslogd
  7779 ?        S  0:00 /usr/sbin/cron
  7782 ?        S  0:00 /usr/lib/inet/inetd start
  7784 ?        S  0:00 /usr/lib/saf/sac -t 300
  7787 ?        S  0:00 /usr/lib/saf/ttymon
  7788 ?        S  0:00 /usr/lib/utmpd
  7831 ?        S  0:00 /usr/lib/ssh/sshd
  7994 pts/2    S  0:00 /usr/bin/login -z global -f root
  7995 pts/2    S  0:00 -bash
  8062 pts/2    O  0:00 ps -ax
  7796 console  S  0:00 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p base_test console login:

We can immediately discount the three processes tied to the pts/2 terminal since those processes are associated with our active login.


Each active zone has an associated kernel process, named zsched.  This process owns all kernel threads doing work on behalf of the zone, and enables the zones subsystem to keep track of per-zone kernel threads.

This process is critical to the proper functioning of a zone, and as such, it is not possible to disable this process from within the zone.


In traditional UNIX, init is the "father of all processes" that was responsible for spawning and restarting service processes that made up the running operating system.

Since Solaris 10, most of this responsibility has now been offloaded to the Service Management Facility (SMF).  Init is now primarily responsible for initializing core components of SMF (namely svc.startd and svc.configd) and restarting them if they fail.

This process is automatically restarted by the Illumos kernel if it is killed, and as such, it is not possible to disable this process from within the zone.


This process is the master process management daemon for the Service Management Facility subsystem.  It's responsible for starting, stopping, restarting, and signaling services based on administrative requests as well as system or application failures.

While this process can be disabled (/etc/inittab), doing so would disable SMF entirely, and is not recommended.


This process is the configuration repository daemon for the Service Management Facility subsystem.  It is responsible for maintaining the configurations for all services on the system, as well as passing administrative requests for services to be started, stopped, restarted, or signaled to the master process management daemon (described above).

This process is automatically started by svc.startd and cannot be independently disabled.


This process handles administrative events for network IP interfaces and IP/TCP/UDP/SCTP/ICMP tunables.  It is managed by SMF and provides the back-end that ipadm uses.

While this process can be disabled (with the service identifier svc:/network/ip-interface-management:default), doing so would prevent network configuration, and is not recommended.

In testing with a non-networked SmartOS Zone, I was unable to get svc:/network/physical:default to properly online at all, with or without ipmgmtd.


This process provides a cache for most name service requests, improving local and network lookup performance.  It specifically provides cache services for the following databases:

  • passwd
  • group
  • hosts
  • ipnodes
  • exec_attr
  • prof_attr
  • user_attr
  • ethers
  • rpc
  • protocols
  • networks
  • bootparams
  • auth_attr
  • services
  • netmasks
  • printers
  • projects

While this process can be disabled (with the service identifier svc:/system/name-service-cache:default) it really should be kept on due to the performance advantage it provides.


This process implements the client half of the dynamic host configuration protocol (DHCP) on Solaris/Illumos.  It will only be running when the zone has network interfaces configured to use DHCP, and as such, should never be manually enabled or disabled.


This process manages the Solaris/Illumos Role Based Access Control (RBAC) system.

It is managed by SMF (with the service identifier svc:/system/pfexec:default) and probably shouldn't be disabled at risk of disrupting normal system operation.


This process provides a reliable message logging service for processes which do not handle their own logging.

It is managed by SMF (with the service identifier svc:/pkgsrc/rsyslog:default) and probably shouldn't be disabled at risk of disrupting normal system operation.


This process is able to start other processes as other users at specified dates and times, making it very convenient for running regularly scheduled commands.  SmartOS already makes use of cron to perform periodic operations (such as rotating logs and checking for vulnerabilities in installed packages).

It is managed by SMF (with the service identifier svc:/system/cron:default) and while it could be disabled, I can't really think of a situation where I'd recommend it.


This process is a delegated restarter for inet services.  It is currently part of SMF, and is quite similar to svc.startd with the added functionality of optionally listening for network requests for services.  Out of the box, it is responsible for maintaining the following services:

  • svc:/network/nfs/rquota:default The remote quota service (for remote NFS clients accessing local shares)
  • svc:/network/rpc/gss:default The daemon that generates and validates security tokens between the kernel rpc and the GSS-API layers.
  • svc:/network/security/ktkt_warn:default Notifies users when their Kerberos tickets are about to expire or automatically renews them before they expire.
  • svc:/network/rpc/rex:default RPC remote execution.
  • svc:/network/login:eklogin Remote login (rlogin) service (encrypted+kerberos).
  • svc:/network/login:klogin Remote login (rlogin) service (kerberos).
  • svc:/network/login:rlogin Remote login (rlogin) service.
  • svc:/network/rexec:default Remote execution service.
  • svc:/network/shell:default Remote shell server.
  • svc:/network/shell:kshell Remote shell server (kerberos).

Inetd is managed by SMF (with the service identifier svc:/network/inetd:default) and unless you're using NFS or rlogin (which has all but been replaced by ssh) I recommend that you disable this service.

You can also check with inetadm before you disable it to see if it would disrupt any services.


The Service Access Controller (SAC) appears to be part of the Service Access Facility or the subsystem that manages terminal connectivity into the system.  Port monitors (ttymon, see below) as described by SAF would be the rough Linux equivalent of a getty, and SAC manages those terminal monitors.

SAC is managed by SMF (with the service identifier svc:/system/sac:default) and unless you're making extensive use of TTYs, I would recommend disabling this service as it poses no apparent disruption to the system.


This process is responsible for maintaining the user accounting databases (utmp/utmpx) in cases where individual processes are unable to correctly update the database, usually failing to properly terminate a session when they close.

It is managed by SMF (with the service identifier svc:/system/utmp:default) and probably shouldn't be disabled at risk of creating possibly erroneous user accounting databases.


This is the OpenSSH daemon and is responsible for providing the server end-point for secure encrypted communications via SSH.  Chances are that you will want to keep this one on unless you never intend on logging directly into this zone from the network (instead, going through the global zone and zlogin).

OpenSSH is managed by SMF (with the service identifier svc:/network/ssh:default) and should only be disabled if you do not want SSH logins to be possible at all.


Besides using SAC/SAF, SMF also can call Port Monitors directly, and this service is an example of that.

As far as I can tell, this ttymon instance connects directly to the virtual console you would connect to with the vmadm console <uuid> command from the global zone.

It is directly managed by SMF (with the service identifier svc:/system/console-login:default) and while I would normally recommend disabling it, it does appear to still be required.


Without too much effort, we've developed a rough idea of what the default processes of a SmartOS zone are, as well as which ones can be disabled without too much of an impact on zone functionality.

In most normal circumstances, I would recommend disabling both the inetd and sac services unless they are required in your specific case:

# svcadm disable svc:/network/inetd:default svc:/system/sac:default

In situations where you do not need or want to support SSH login access, you can also safely disable the sshd process entirely.

# svcadm disable svc:/network/ssh:default

Consider that you really should establish some other mechanism to perform maintenance if you do this.