Skip to content

parse

Parses a frontend service file and writes the result to a directory.

Users may not directly execute this command. It is primarily used internally by 66. 66 automatically handles a non-parsed service by invoking the parse command. Users who wish to parse a service again with the -f option should prefer using the reconfigure command.

However, a system administrator might want to parse a service frontend file under construction to ensure everything is functioning correctly without altering the system's state.

Interface

parse [ -h ] [ -f ] [ -I ] service...
  • Opens and reads the frontend service file.
  • Runs a parser on the file.
  • Writes the parsing result to the /var/lib/66/system/service/svc/foo directory.

The absolute path of the frontend service file can also be set. In this case, the primary path of this absolute path must match /usr/share/66/service or /etc/66/service or $HOME/.66/service directory name e.g /usr/share/66/service/ntpd/0.1.1/ntpd.

This command handles interdependencies and parses any interdependencies needed for the service if they aren't parsed yet. A name listed in the RequiredBy key is never parsed by it: the declaration is kept, and a service named there depends on the declaring one once it is parsed, by its name or through a Depends.

An already parsed service is left as it is, said at verbosity 2. A service is parsed into the tree of the 66 -t option, else the tree of its InTree key, else the current tree.

Every named frontend is checked before anything is written: when one of them is refused, nothing is written, for any of the named services. A frontend is refused with 100 when:

  • a name, the service name or one it names in Depends, RequiredBy, OptsDepends, Provide or Conflict, ends with the suffix -log, reserved to the loggers 66 creates. Only the end of the whole name counts: the instance tpl-log@x is accepted, tpl@x-log is not.
  • a service name, or a name in its Depends, starts with a dot.
  • a Depends names a service that has no frontend and that no service answers to.
  • its keys are invalid: a type, a timeout, a capability, an io path, a CopyFrom path that does not exist, an Emit naming an event with a dot.
  • the frontends make a dependency cycle.
  • it names a member of a module alone (module:member): a module is parsed as a whole.
  • it breaks the rules of a module: a member of type module, or a dependency across the module.
  • it collides with a provided name: see dependencies.

A dependency cycle written on the disk only, outside 66, is named by the services it concerns; parsing the frontends again with -f once the cycle is broken repairs them. An invalid service elsewhere on the system does not refuse the parse: it is named in a warning.

Options

  • -h, --help: prints this help.

  • -f, --force: force. Overwrite an existing parsing result. The named service alone is written again: its dependencies are not parsed again, its Depends is checked again, and a dependency it adds and that was never parsed is parsed. Its activation and its tree do not change, unless 66 -t names another tree. What the frontend drops is undone: a Depends dropped is unlinked; a logger dropped with !log and members dropped from a module are stopped, unsupervised and removed; a Provide name dropped is released, unless a service depends on it, which refuses the parse. A supervised service whose frontend changes its type is refused: free it first with 66 free, or use 66 reconfigure.

  • -I, --no-import: do not import modified configuration files from the previous version used. Refer to Service configuration file for further information.

Usage examples

Parses the frontend file of foo service

66 parse foo

Parses the frontend file of foo service without importing key=value pair previous configuration file

66 parse -I foo

Force to parse again an existing parsing result of foo service

66 parse -f foo

Parses the frontend file of foo service specifying the localization of the frontend file

66 parse /etc/66/service/foo