2010-05-04 12 views
7

Sto creando un servizio linux, nel file dello scheletro si dice che è necessario eseguire vari comandi rc (rc-status, rc_reset) per aggiornare lo stato del servizio. Cosa significa in realtà? Ho cercato su google ma non riesco a trovare molti dettagli. Qualcuno mi può aiutareChe cos'è il file rc.status in linux

risposta

7

I comandi da rc.status sono effettivamente Su specifico penso. AFAICT gestiscono due cose: l'output per l'utente e lo stato di ritorno finale dello script. rc_status controlla se il comando precedente (ovvero avvio/riavvio/arresto di un servizio) è stato eseguito correttamente e imposta il "valore di stato", che è il valore restituito da rc_exit (che viene inserito alla fine dello script init.d) . Source

È possibile scrivere lo script della shell senza di essi, ma presumo che contribuiscano a garantire che lo script sia conforme ai requisiti LSB e si integri bene con altri script di sistema. Scommetto che la maggior parte di questo è effettivamente documentato nel file /etc/rc.status, però. Semplicemente non ho una scatola di fortuna a portata di mano.

1

È necessario uno script di shell per arrestare/avviare/riavviare il servizio e per dare il suo stato. Questi sono generalmente chiamati script rc. Dai un'occhiata alla directory /etc/init.d per vedere alcuni esempi - /etc/init.d/klogd è piuttosto semplice.

Il motivo per cui si trovano in init.d è perché devono essere eseguiti automaticamente all'avvio per ripristinare il servizio.

Ogni variante Linux tende ad essere un po 'diverso da come l'avvio opere ma il sistema Debian è abbastanza tipico in quanto è la base per molte altre distribuzioni - vedi Debian Boot Up Manager

0

Ecco l'Blocca i commenti da /etc/init.d/skeleton da SUSE Linux Enterprise Server 11 SP3:

#!/bin/sh 
# 
#  Template SUSE system startup script for example service/daemon FOO 
#  Copyright (C) 1995--2005 Kurt Garloff, SUSE/Novell Inc. 
#   
#  This library is free software; you can redistribute it and/or modify it 
#  under the terms of the GNU Lesser General Public License as published by 
#  the Free Software Foundation; either version 2.1 of the License, or (at 
#  your option) any later version. 
#     
#  This library is distributed in the hope that it will be useful, but 
#  WITHOUT ANY WARRANTY; without even the implied warranty of 
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 
#  Lesser General Public License for more details. 
#  
#  You should have received a copy of the GNU Lesser General Public 
#  License along with this library; if not, write to the Free Software 
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, 
#  USA. 
# 
# /etc/init.d/FOO 
# and its symbolic link 
# /(usr/)sbin/rcFOO 
# 
# Template system startup script for some example service/daemon FOO 
# 
# LSB compatible service control script; see http://www.linuxbase.org/spec/ 
# 
# Note: This template uses functions rc_XXX defined in /etc/rc.status on 
# UnitedLinux/SUSE/Novell based Linux distributions. If you want to base your 
# script on this template and ensure that it works on non UL based LSB 
# compliant Linux distributions, you either have to provide the rc.status 
# functions from UL or change the script to work without them. 
# See skeleton.compat for a template that works with other distros as well. 
# 
### BEGIN INIT INFO 
# Provides:   FOO 
# Required-Start: $syslog $remote_fs 
# Should-Start:  $time ypbind smtp 
# Required-Stop:  $syslog $remote_fs 
# Should-Stop:  ypbind smtp 
# Default-Start:  3 5 
# Default-Stop:  0 1 2 6 
# Short-Description: FOO XYZ daemon providing ZYX 
# Description:  Start FOO to allow XY and provide YZ 
# continued on second line by '#<TAB>' 
# should contain enough info for the runlevel editor 
# to give admin some idea what this service does and 
# what it's needed for ... 
# (The Short-Description should already be a good hint.) 
### END INIT INFO 
# 
# Any extensions to the keywords given above should be preceeded by 
# X-VendorTag- (X-UnitedLinux- X-SuSE- for us) according to LSB. 
# 
# Notes on Required-Start/Should-Start: 
# * There are two different issues that are solved by Required-Start 
# and Should-Start 
# (a) Hard dependencies: This is used by the runlevel editor to determine 
#  which services absolutely need to be started to make the start of 
#  this service make sense. Example: nfsserver should have 
#  Required-Start: $portmap 
#  Also, required services are started before the dependent ones. 
#  The runlevel editor will warn about such missing hard dependencies 
#  and suggest enabling. During system startup, you may expect an error, 
#  if the dependency is not fulfilled. 
# (b) Specifying the init script ordering, not real (hard) dependencies. 
#  This is needed by insserv to determine which service should be 
#  started first (and at a later stage what services can be started 
#  in parallel). The tag Should-Start: is used for this. 
#  It tells, that if a service is available, it should be started 
#  before. If not, never mind. 
# * When specifying hard dependencies or ordering requirements, you can 
# use names of services (contents of their Provides: section) 
# or pseudo names starting with a $. The following ones are available 
# according to LSB (1.1): 
# $local_fs  all local file systems are mounted 
#    (most services should need this!) 
# $remote_fs  all remote file systems are mounted 
#    (note that /usr may be remote, so 
#    many services should Require this!) 
# $syslog   system logging facility up 
# $network  low level networking (eth card, ...) 
# $named   hostname resolution available 
# $netdaemons  all network daemons are running 
# The $netdaemons pseudo service has been removed in LSB 1.2. 
# For now, we still offer it for backward compatibility. 
# These are new (LSB 1.2): 
# $time   the system time has been set correctly 
# $portmap  SunRPC portmapping service available 
# UnitedLinux extensions: 
# $ALL   indicates that a script should be inserted 
#    at the end 
# * The services specified in the stop tags 
# (Required-Stop/Should-Stop) 
# specify which services need to be still running when this service 
# is shut down. Often the entries there are just copies or a subset 
# from the respective start tag. 
# * Should-Start/Stop are now part of LSB as of 2.0, 
# formerly SUSE/Unitedlinux used X-UnitedLinux-Should-Start/-Stop. 
# insserv does support both variants. 
# * X-UnitedLinux-Default-Enabled: yes/no is used at installation time 
# (%fillup_and_insserv macro in %post of many RPMs) to specify whether 
# a startup script should default to be enabled after installation. 
# It's not used by insserv. 
# 
# Note on runlevels: 
# 0 - halt/poweroff    6 - reboot 
# 1 - single user   2 - multiuser without network exported 
# 3 - multiuser w/ network (text mode) 5 - multiuser w/ network and X11 (xdm) 
# 
# Note on script names: 
# http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/scrptnames.html 
# A registry has been set up to manage the init script namespace. 
# http://www.lanana.org/ 
# Please use the names already registered or register one or use a 
# vendor prefix. 
#... 
# Source LSB init functions 
# providing start_daemon, killproc, pidofproc, 
# log_success_msg, log_failure_msg and log_warning_msg. 
# This is currently not used by UnitedLinux based distributions and 
# not needed for init scripts for UnitedLinux only. If it is used, 
# the functions from rc.status should not be sourced or used. 
#. /lib/lsb/init-functions 
# 
# Shell functions sourced from /etc/rc.status: 
#  rc_check   check and set local and overall rc status 
#  rc_status  check and set local and overall rc status 
#  rc_status -v  be verbose in local rc status and clear it afterwards 
#  rc_status -v -r ditto and clear both the local and overall rc status 
#  rc_status -s  display "skipped" and exit with status 3 
#  rc_status -u  display "unused" and exit with status 3 
#  rc_failed  set local and overall rc status to failed 
#  rc_failed <num> set local and overall rc status to <num> 
#  rc_reset   clear both the local and overall rc status 
#  rc_exit   exit appropriate to overall rc status 
#  rc_active  checks whether a service is activated by symlinks 
#... 
# 
# Return values acc. to LSB for all commands but status: 
# 0 - success 
# 1  - generic or unspecified error 
# 2  - invalid or excess argument(s) 
# 3  - unimplemented feature (e.g. "reload") 
# 4  - user had insufficient privileges 
# 5  - program is not installed 
# 6  - program is not configured 
# 7  - program is not running 
# 8--199 - reserved (8--99 LSB, 100--149 distrib, 150--199 appl) 
# 
# Note that starting an already running service, stopping 
# or restarting a not-running service as well as the restart 
# with force-reload (in case signaling is not supported) are 
# considered a success. 
#... 
## Check status with checkproc(8), if process is running 
## checkproc will return with exit status 0. 
# 
# Return value is slightly different for the status command: 
# 0 - service up and running 
# 1 - service dead, but /var/run/ pid file exists 
# 2 - service dead, but /var/lock/ lock file exists 
# 3 - service not running (unused) 
# 4 - service status unknown :-(
# 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.) 

Ecco il blocco di commenti da /etc/rc.status da SUSE Linux Enterprise Server 11 SP3:

# /etc/rc.status 
# vim: syntax=sh 
# Definition of boot script return messages 
# 
# The bootscripts should use the variables rc_done and rc_failed to 
# report whether they failed or succeeded. See /etc/init.d/skeleton for 
# an example how the shell functions rc_status and rc_reset are used. 
# 
# These functions make use of the variables rc_done and rc_failed; 
# rc_done_up and rc_failed_up are the same as rc_done and rc_failed 
# but contain a terminal code to move up one line before the output 
# of the actual string. (This is particularly useful when the script 
# starts a daemon which produces user output with a newline character) 
# 
# The variable rc_reset is used by the master resource control script 
# /etc/init.d/rc to turn off all attributes and switch to the standard 
# character set. 
# 
# \033   ascii ESCape 
# \033[<NUM>G move to column <NUM> (linux console, xterm, not vt100) 
# \033[<NUM>C move <NUM> columns forward but only upto last column 
# \033[<NUM>D move <NUM> columns backward but only upto first column 
# \033[<NUM>A move <NUM> rows up 
# \033[<NUM>B move <NUM> rows down 
# \033[1m  switch on bold 
# \033[31m  switch on red 
# \033[32m  switch on green 
# \033[33m  switch on yellow 
# \033[m  switch off color/bold 
# \017   exit alternate mode (xterm, vt100, linux console) 
# \033[10m  exit alternate mode (linux console) 
# \015   carriage return (without newline) 
+0

Questo in realtà non risponde alla domanda. –