66

Software

obarun.org

This documentation explains the differences in options and interface changes between versions v0.6.1.3 and 0.7.0.0. Futhers information can be found to the upgrade page concerning behavior changes, frontend @key changes and more.

General Interface changes

Generally, the prefix is removed from commands, for example, 66-enable becomes 66 enable, 66-start becomes 66 start, and so on except for a few special commands – see below.

Debug command

Admin command

User command

Extra tools

New command

General options changes

Previous tools accepted the options -h, -z, -l, -T and -t. These options are now integrated into the general 66 command. Let’s take an examples:

Help accessibility

All commands and subcommands accept the -h option to access their respective help.

• 66 -h: get the help of the general command
• 66 tree -h: get the help of the tree subcommand
• 66 tree resolve -h: get the help of resolve subcommand of the tree subcommand

General exit codes

All commands and subcommands return:

• 0 success
• 100 wrong usage
• 111 system call failed

Interface and Options changes by command

If not specified, the interface (except for the name itself – see General Interface changes) or the options do not change.

66-scandir

66-scandir and 66-scanctl was combined together into the command 66 scandir.

New subcommands was integrated to 66 scandir to avoid using options from s6-svscanctl.

66-init

As s6-rc was dropped, the specification of the type of the service is not needed anymore. This program was integrated to 66 tree command – see 66 tree init documentation for futhers information.

66-svctl

This tool previously deals only with classic service whereas 66 signal deals with all kind of services type.

66-all

This tool previously handles all services for trees, the new command handles all enabled services for trees.

66-tree

66-enable

With the previous version, services must be enabled to be able to start the service. It is not mandatory anymore with the new version. A service can be started without enabling it first. As result, the enable process is not responsible of the parse process even if it parse the service if the service was never parsed before.

66-disable

66-start

66-stop

Converting service frontend file from 0.6.2.0 version to 0.7.0.0

Manual intervention is required to upgrade the frontend file to version 0.7.0.0, as both the longrun and bundle types have been eliminated. Additionally, certain fields have been altered, deprecated, or removed.

• The longrun type should be converted to the classic type. To achieve this, simply replace @type=longrun with @type=classic. This conversion is performed by 66 during the parse process, but the change is not applied to the frontend file.

• The @extdepends= field has been removed and has no effect. To address this, switch the service definition in this field to the @depends= field. For example, a service declaring @depends=(consolekit) and @extdepends=(dbus) should be converted by removing the @extdepends field and appending dbus to the @depends=(dbus consolekit) field.

• The @shebang field is deprecated and will be removed in a future release. To define the shebang for our script, place it at the beginning of the @execute field right after the opened parentheses, without any space, new line, or other characters. For example, for an sh script, the beginning of the @execute field must be

  @execute = (!#/usr/bin/sh
  echo myscript
  ....
  )
  

  The incorret way is

  @execute = (
  #!/usr/bin/sh
  echo myscript
      ....
  )
  

  The following is also incorrect

  @execute = ( #!/usr/bin/sh
  echo myscript
      ....
  )
  

  Failure to adhere to the correct syntax will result in an Error format during the execution of the service.

• The bundle type no longer exists. To achieve a similar behavior, you can emulate the functionality of a bundle by using a oneshot type. Define the @depends= field with the service name previously defined in your bundle type under the @contents field. The @execute field of the oneshot service should simply be defined as true. For instance, the following bundle

  [main]
  @type=bundle
  @version=0.0.1
  @description="launch network"
  @user=(root)
  @contents=(connmand openntpd)
  

  will be converted to following oneshot service ``` [main] @type=oneshot @version=0.0.1 @description="launch network” @user=(root) @depends=(connmand openntpd)

  [start] @execute=(true) ```

  Certainly, you can replace the bundle type with the module type. However, depending on your specific cases, the module type might overcomplicate the service itself.

• The module type must be redefined from scratch due to significant changes in the directory module structure.. Refers to the module-creation documentation for detailed information.

Cleaning the 66 directories and files

The heart structure of 66 has been reframed, resulting in a simplified directory architecture. Clean unused files and directories from the previous release by following the instructions below. Additionally, refer to the deeper understanding documentation about the 66 architecture.

/var/lib/66

You can safely remove the following directories and files:

• /var/lib/66/current directory.

• /var/lib/66/system/:

  Any other directories and files except for the /var/lib/66/.resolve and /var/lib/66/service directories from this directory.

The exact same task applies to the ${HOME}/.66 directory. Also, you can remove the ${HOME}/.66/module directory.

/etc/66

You can safely remove the following /etc/66/module directory.