Guest User

Untitled

a guest
Jul 17th, 2018
83
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 9.62 KB | None | 0 0
  1. Service Control Facility – Keys:
  2.  
  3. Label <string>
  4. This required key uniquely identifies the job to SCF.
  5.  
  6. UserName <string>
  7. This optional key specifies the user to run the job as.
  8.  
  9. GroupName <string>
  10. This optional key specifies the group to run the job as. If UserName is set and GroupName is not, the the group will be set to the default group of the user.
  11.  
  12. inetdCompatibility <boolean>
  13. The presence of this key specifies that the daemon expects to be run as if it were launched from inetd.
  14.  
  15. Wait <boolean>
  16. This flag corresponds to the "wait" or "nowait" option of inetd. If true, then the listening socket is passed via the standard in/out/error file descriptors. If false, then accept is called on behalf of the job, and the result is passed via the standard in/out/error descriptors.
  17.  
  18. Program <string>
  19. This key maps to the first argument of execvp(3).
  20.  
  21. ProgramArguments <array of strings>
  22. This key maps to the second argument of execvp(3).
  23.  
  24. EnableGlobbing <boolean>
  25. This flag causes SCF to use the glob(3) mechanism to update the program arguments before invocation.
  26.  
  27. EnableTransactions <boolean>
  28. This flag instructs SCF that the job promises to use vproc_transaction_begin(3) and vproc_transaction_end(3) to track outstanding transactions that need to be reconciled before the process can safely terminate. If no outstanding transactions are in progress, then SCF is free to send the SIGKILL signal.
  29.  
  30. KeepAlive <boolean>
  31. This optional key is used to control whether your job is to be kept continuously running or to let demand and conditions control the invocation. The default is false and therefore only demand will start the job. The value may be set to true to unconditionally keep the job alive.
  32.  
  33. SuccessfulExit <boolean>
  34. If true, the job will be restarted as long as the program exits and with an exit status of zero. If false, the job will be restarted in the inverse condition. This key implies that "RunAtLoad" is set to true, since the job needs to run at least once before we can get an exit status.
  35.  
  36. NetworkState <boolean>
  37. If true, the job will be kept alive as long as the network is up, where up is defined as at least one non-loopback interface being up and having IPv4 or IPv6 addresses assigned to them. If false, the job will be kept alive in the inverse condition.
  38.  
  39. PathState <dictionary of booleans>
  40. Each key in this dictionary is a file-system path. If the value of the key is true, then the job will be kept alive as long as the path exists. If false, the job will be kept alive in the inverse condition. The intent of this feature is that two or more jobs may create semaphores in the file-system namespace.
  41.  
  42. OtherJobEnabled <dictionary of booleans>
  43. Each key in this dictionary is the label of another job. If the value of the key is true, then this job is kept alive as long as that other job is enabled. Otherwise, if the value is false, then this job is kept alive as long as the other job is disabled. This feature should not be considered a substitute for the use of IPC.
  44.  
  45. RunAtLoad <boolean>
  46. This optional key is used to control whether your job is launched once at the time the job is loaded.
  47. The default is false.
  48.  
  49. RootDirectory <string>
  50. This optional key is used to specify a directory to chroot(2) to before running the job.
  51.  
  52. WorkingDirectory <string>
  53. This optional key is used to specify a directory to chdir(2) to before running the job.
  54.  
  55. EnvironmentVariables <dictionary of strings>
  56. This optional key is used to specify additional environmental variables to be set before running the
  57. job.
  58.  
  59. Umask <integer>
  60. This optional key specifies what value should be passed to umask(2) before running the job.
  61.  
  62. TimeOut <integer>
  63. The recommended idle time out (in seconds) to pass to the job. If no value is specified, a default time out will be supplied by SCF for use by the job at check in time.
  64.  
  65. ExitTimeOut <integer>
  66. The amount of time SCF waits before sending a SIGKILL signal. The default value is 20 seconds. The value zero is interpreted as infinity.
  67.  
  68. ThrottleInterval <integer>
  69. This key lets one override the default throttling policy imposed on jobs by SCF. The value is in seconds, and by default, jobs will not be spawned more than once every 10 seconds. The principle behind this is that jobs should linger around just in case they are needed again in the near future.
  70. This not only reduces the latency of responses, but it encourages developers to amortize the cost of program invocation.
  71.  
  72. WatchPaths <array of strings>
  73. This optional key causes the job to be started if any one of the listed paths are modified.
  74.  
  75. QueueDirectories <array of strings>
  76. Much like the WatchPaths option, this key will watch the paths for modifications. The difference being that the job will only be started if the path is a directory and the directory is not empty.
  77.  
  78. StartOnMount <boolean>
  79. This optional key causes the job to be started every time a filesystem is mounted.
  80.  
  81. StartInterval <integer>
  82. This optional key causes the job to be started every N seconds. If the system is asleep, the job will be started the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep.
  83.  
  84. StartCalendarInterval <dictionary of integers or array of dictionary of integers>
  85. This optional key causes the job to be started every calendar interval as specified. Missing arguments are considered to be wildcard. The semantics are much like crontab(5). Unlike cron which skips job invocations when the computer is asleep, SCF will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep.
  86.  
  87. Minute <integer>
  88. The minute on which this job will be run.
  89.  
  90. Hour <integer>
  91. The hour on which this job will be run.
  92.  
  93. Day <integer>
  94. The day on which this job will be run.
  95.  
  96. Weekday <integer>
  97. The weekday on which this job will be run ( and 7 are Sunday).
  98.  
  99. Month <integer>
  100. The month on which this job will be run.
  101.  
  102. StandardInPath <string>
  103. This optional key specifies what file should be used for data being supplied to stdin when using stdio(3).
  104.  
  105. StandardOutPath <string>
  106. This optional key specifies what file should be used for data being sent to stdout when using stdio(3).
  107.  
  108. StandardErrorPath <string>
  109. This optional key specifies what file should be used for data being sent to stderr when using stdio(3).
  110.  
  111. Debug <boolean>
  112. This optional key specifies that SCF should adjust its log mask temporarily to LOG_DEBUG while dealing with this job.
  113.  
  114. WaitForDebugger <boolean>
  115. This optional key specifies that SCF should instruct the kernel to have the job wait for a debugger to attach before any code in the job is executed.
  116.  
  117. SoftResourceLimits <dictionary of integers>
  118. HardResourceLimits <dictionary of integers>
  119. Resource limits to be imposed on the job. These adjust variables set with setrlimit(2). The following keys apply:
  120.  
  121. Core <integer>
  122. The largest size (in bytes) core file that may be created.
  123. CPU <integer>
  124. The maximum amount of cpu time (in seconds) to be used by each process.
  125. Data <integer>
  126. The maximum size (in bytes) of the data segment for a process; this defines how far a program may extend its break with the sbrk(2) system call.
  127. FileSize <integer>
  128. The largest size (in bytes) file that may be created.
  129. MemoryLock <integer>
  130. The maximum size (in bytes) which a process may lock into memory using the mlock(2) function.
  131. NumberOfFiles <integer>
  132. The maximum number of open files for this process. Setting this value in a system wide daemon will set the sysctl(3) kern.maxfiles (SoftResourceLimits) or kern.maxfilesperproc (HardResource-Limits) value in addition to the setrlimit(2) values.
  133. NumberOfProcesses <integer>
  134. The maximum number of simultaneous processes for this user id. Setting this value in a system wide daemon will set the sysctl(3) kern.maxproc (SoftResourceLimits) or kern.maxprocperuid (HardResourceLimits) value in addition to the setrlimit(2) values.
  135. ResidentSetSize <integer>
  136. The maximum size (in bytes) to which a process's resident set size may grow. This imposes a limit on the amount of physical memory to be given to a process; if memory is tight, the system will prefer to take memory from processes that are exceeding their declared resident set size.
  137. Stack <integer>
  138. The maximum size (in bytes) of the stack segment for a process; this defines how far a program's stack segment may be extended. Stack extension is performed automatically by the system.
  139. Nice <integer>
  140. This optional key specifies what nice(3) value should be applied to the daemon.
  141.  
  142. AbandonProcessGroup <boolean>
  143. When a job dies, SCF kills any remaining processes with the same process group ID as the job. Setting this key to true disables that behavior.
  144.  
  145. LaunchOnlyOnce <boolean>
  146. This optional key specifies whether the job can only be run once and only once. In other words, if the job cannot be safely respawned without a full machine reboot, then set this key to be true.
  147.  
  148.  
  149. DEPENDENCIES:
  150. Unlike many bootstrapping daemons, SCF has no explicit dependency model. Interdependencies are expected to be solved through the use of IPC. It is therefore in the best interest of a job developer who expects dependents to define all of the sockets in the configuration file. This has the added benefit of making it possible to start the job based on demand instead of immediately.
Add Comment
Please, Sign In to add comment