1SMARTD(8)                   SMART Monitoring Tools                   SMARTD(8)


6       smartd - SMART Disk Monitoring Daemon


10       smartd [options]


14       [This man page is generated for the Linux version of smartmontools.  It
15       does not contain info specific to other platforms.]
17       smartd is a daemon that monitors the Self-Monitoring, Analysis and  Re‐
18       porting Technology (SMART) system built into most ATA/SATA and SCSI/SAS
19       hard drives and solid-state drives.  The purpose of SMART is to monitor
20       the  reliability  of  the hard drive and predict drive failures, and to
21       carry out different types of drive self-tests.  This version of  smartd
22       is  compatible  with  ACS-3,  ACS-2,  ATA8-ACS, ATA/ATAPI-7 and earlier
23       standards (see REFERENCES below).
25       smartd will attempt to enable SMART monitoring on ATA devices  (equiva‐
26       lent  to smartctl -s on) and polls these and SCSI devices every 30 min‐
27       utes (configurable), logging SMART errors  and  changes  of  SMART  At‐
28       tributes via the SYSLOG interface.  The default location for these SYS‐
29       LOG  notifications  and   warnings   is   system-dependent   (typically
30       /var/log/messages  or  /var/log/syslog).   To change this default loca‐
31       tion, please see the '-l' command-line option described below.
33       In addition to logging to a file, smartd can also be configured to send
34       email  warnings  if  problems are detected.  Depending upon the type of
35       problem, you may want to run self-tests on the disk, back up the  disk,
36       replace the disk, or use a manufacturer's utility to force reallocation
37       of bad or unreadable disk sectors.   If  disk  problems  are  detected,
38       please  see the smartctl manual page and the smartmontools web page/FAQ
39       for further guidance.
41       If you send a USR1 signal to smartd it will immediately check the  sta‐
42       tus  of  the  disks, and then return to polling the disks every 30 min‐
43       utes.  See the '-i' option below for additional details.
45       smartd can be configured  at  start-up  using  the  configuration  file
46       /etc/smartmontools/smartd.conf  (Windows:  EXEDIR/smartd.conf).  If the
47       configuration file is subsequently modified, smartd can be told to  re-
48       read  the  configuration  file  by sending it a HUP signal, for example
49       with the command:
50       killall -HUP smartd.
52       On startup, if smartd finds a syntax error in the  configuration  file,
53       it will print an error message and then exit.  However if smartd is al‐
54       ready running, then is told with a HUP signal to re-read the configura‐
55       tion  file, and then find a syntax error in this file, it will print an
56       error message and then continue, ignoring the contents of the  (faulty)
57       configuration file, as if the HUP signal had never been received.
59       When  smartd  is running in debug mode, the INT signal (normally gener‐
60       ated from a shell with CONTROL-C) is treated in the same way as  a  HUP
61       signal:  it makes smartd reload its configuration file.  To exit smartd
62       use CONTROL-\.
64       [Linux only] If smartd is started as a systemd(1) service and 'Type=No‐
65       tify' is specified in the service file, the service manager is notified
66       after successful startup.  Other state changes are reported via systemd
67       notify  STATUS messages.  Notification of successful reloads (after HUP
68       signal) is not supported.  To detect this process start-up type, smartd
69       checks  whether  the environment variable 'NOTIFY_SOCKET' is set.  Note
70       that it is required to set the '-n' ('--nofork') option in  the  'Exec‐
71       Start=/usr/sbin/smartd' command line if 'Type=Notify' is used.
73       On  startup,  in  the  absence of the configuration file /etc/smartmon‐
74       tools/smartd.conf, the smartd daemon first scans for all  devices  that
75       support SMART.  The scanning is done as follows:
77       LINUX:   Examine  all  entries  "/dev/hd[a-t]" for IDE/ATA devices, and
78                "/dev/sd[a-z]", "/dev/sd[a-z][a-z]" for ATA/SATA  or  SCSI/SAS
79                devices.  Disks behind RAID controllers are not included.
81                If  directive '-d nvme' or no '-d' directive is specified, ex‐
82                amine all entries "/dev/nvme[0-99]" for NVMe devices.
84       smartd then monitors for all possible SMART  errors  (corresponding  to
85       the  '-a'  Directive  in the configuration file; see the smartd.conf(5)
86       man page).


90       -A PREFIX, --attributelog=PREFIX
91              Writes smartd attribute information (normalized and  raw  attri‐
92              bute  values)  to  files 'PREFIX''MODEL-SERIAL.ata.csv' or 'PRE‐
93              FIX''VENDOR-MODEL-SERIAL.scsi.csv'.  At  each  check  cycle  at‐
94              tributes are logged as a line of semicolon separated triplets of
95              the    form    "attribute-ID;attribute-norm-value;attribute-raw-
96              value;".   For  SCSI  devices  error  counters  and  temperature
97              recorded in the form "counter-name;counter-value;".   Each  line
98              is  led  by  a date string of the form "yyyy-mm-dd HH:MM:SS" (in
99              local time).
101              MODEL and SERIAL are build from drive identify information,  in‐
102              valid characters are replaced by underline.
104              If    the    PREFIX    has    the    form   '/path/dir/'   (e.g.
105              '/var/lib/smartd/'), then files 'MODEL-SERIAL.ata.csv' are  cre‐
106              ated  in  directory  '/path/dir'.   If  the  PREFIX has the form
107              '/path/name' (e.g. '/var/lib/misc/attrlog-'), then files 'nameM‐
108              ODEL-SERIAL.ata.csv'  are  created  in  directory '/path/'.  The
109              path must be absolute, except if debug mode is enabled.
111       -B [+]FILE, --drivedb=[+]FILE
112              [ATA only] Read the drive database from FILE.  The new  database
113              replaces the built in database by default.  If '+' is specified,
114              then the new entries prepend the built in entries.   Please  see
115              the smartctl(8) man page for further details.
117       -c FILE, --configfile=FILE
118              Read  smartd configuration Directives from FILE, instead of from
119              the default  location  /etc/smartmontools/smartd.conf  (Windows:
120              EXEDIR/smartd.conf).   If  FILE does not exist, then smartd will
121              print an error message and exit with nonzero status.  Thus,  '-c
122              /etc/smartmontools/smartd.conf'  can be used to verify the exis‐
123              tence of the default configuration file.
125              By using '-' for FILE, the configuration is read  from  standard
126              input.  This is useful for commands like:
127              echo /dev/sdb -m user@home -M test | smartd -c - -q onecheck
128              to perform quick and simple checks without a configuration file.
130       -C, --capabilities[=mail]
131              [Linux  only] Use libcap-ng to drop unneeded Linux process capa‐
132              bilities(7).  The following capabilities are kept in the  effec‐
133              tive   and   permissive   sets:   CAP_SYS_ADMIN,  CAP_SYS_RAWIO,
134              CAP_MKNOD.  If the '-u, --warn_as_user' option  (see  below)  is
135              used with a non-privileged user or group, the following capabil‐
136              ities are also kept:  CAP_SETGID,  CAP_SETUID.   The  capability
137              bounding set is cleared.
139              [NEW  EXPERIMENTAL  SMARTD  7.3 FEATURE] Mail notification is no
140              longer suppressed if capabilities are dropped.   It  depends  on
141              the  local  MTA  whether  mail could be send from a root process
142              with all capabilities dropped.  It works with the postfix MTA.
144              If '--capabilities=mail' is specified, the  following  capabili‐
145              ties  are  added  to  the  bounding set: CAP_SETGID, CAP_SETUID,
146              CAP_CHOWN, CAP_FOWNER, CAP_DAC_OVERRIDE.   This  allows  one  to
147              send mail with the exim MTA.
149       -d, --debug
150              Runs  smartd  in "debug" mode.  In this mode, it displays status
151              information to STDOUT rather than logging it to SYSLOG and  does
152              not  fork(2) into the background and detach from the controlling
153              terminal.  In this mode, smartd also prints more verbose  infor‐
154              mation  about  what  it is doing than when operating in "daemon"
155              mode.  In this mode, the INT signal (normally generated  from  a
156              terminal  with  CONTROL-C) makes smartd reload its configuration
157              file.  Please use CONTROL-\ to exit
159       -D, --showdirectives
160              Prints a list (to STDOUT) of all the possible  Directives  which
161              may    appear   in   the   configuration   file   /etc/smartmon‐
162              tools/smartd.conf, and then exits.   These  Directives  are  de‐
163              scribed  in the smartd.conf(5) man page.  They may appear in the
164              configuration file following the device name.
166       -h, --help, --usage
167              Prints usage message to STDOUT and exits.
169       -i N, --interval=N
170              Sets the interval between disk checks to N seconds, where N is a
171              decimal integer.  The minimum allowed value is ten and the maxi‐
172              mum is the largest positive integer that can be  represented  on
173              your system (often 2^31-1).  The default is 1800 seconds.
174              [NEW  EXPERIMENTAL  SMARTD  7.3  FEATURE]  The interval could be
175              overridden with the '-c i=N' directive, see  smartd.conf(5)  man
176              page.
178              Note  that the superuser can make smartd check the status of the
179              disks at any time by sending it the SIGUSR1 signal, for  example
180              with the command:
181              kill -SIGUSR1 <pid>
182              where  <pid>  is  the process id number of smartd.  One may also
183              use:
184              killall -USR1 smartd
185              for the same purpose.
187       -l FACILITY, --logfacility=FACILITY
188              Uses syslog facility FACILITY to log the messages  from  smartd.
189              Here  FACILITY  is one of local0, local1, ..., local7, or daemon
190              [default].  If this command-line option is not used, then by de‐
191              fault messages from smartd are logged to the facility daemon.
193              If you would like to have smartd messages logged somewhere other
194              than the default location, include (for example) '-l local3'  in
195              its  start  up argument list.  Tell the syslog daemon to log all
196              messages    from    facility    local3    to    (for    example)
197              '/var/log/smartd.log'.
199              For more detailed information, please refer to the man pages for
200              the local syslog daemon, typically syslogd(8),  syslog-ng(8)  or
201              rsyslogd(8).
203       -n, --no-fork
204              Do  not  fork into background; this is useful when executed from
205              modern init methods like initng, minit, supervise or systemd.
207       -p NAME, --pidfile=NAME
208              Writes pidfile NAME containing  the  smartd  Process  ID  number
209              (PID).   To  avoid  symlink  attacks  make sure the directory to
210              which pidfile is written is only  writable  for  root.   Without
211              this  option,  or if the --debug option is given, no PID file is
212              written on startup.  If smartd is killed with a maskable  signal
213              then the pidfile is removed.
215       -q WHEN, --quit=WHEN
216              Specifies  when,  if  ever, smartd should exit.  The valid argu‐
217              ments are to this option are:
219              nodev - Exit if there are no devices to monitor, or if  any  er‐
220              rors  are  found  at startup in the configuration file.  This is
221              the default.
223              errors - Exit if there are no devices to monitor, or if any  er‐
224              rors   are   found  in  the  configuration  file  /etc/smartmon‐
225              tools/smartd.conf at startup or whenever it is reloaded.
227              nodevstartup - Exit if  there  are  no  devices  to  monitor  at
228              startup.   But  continue to run if no devices are found whenever
229              the configuration file is reloaded.
231              never - Only exit if a fatal error occurs (no  remaining  system
232              memory,  invalid command line arguments).  In this mode, even if
233              there are no devices to monitor, or if  the  configuration  file
234              /etc/smartmontools/smartd.conf  has errors, smartd will continue
235              to run, waiting to load a configuration file listing  valid  de‐
236              vices.
238              nodev0  - [NEW EXPERIMENTAL SMARTD 7.3 FEATURE] Same as 'nodev',
239              except that the exit status is 0 if there are no devices to mon‐
240              itor.
242              nodev0startup  -  [NEW  EXPERIMENTAL SMARTD 7.3 FEATURE] Same as
243              'nodevstartup', except that the exit status is 0 if there are no
244              devices to monitor.
246              errors,nodev0  -  [NEW  EXPERIMENTAL SMARTD 7.3 FEATURE] Same as
247              'errors', except that the exit status is 0 if there are  no  de‐
248              vices to monitor.
250              onecheck  -  Start  smartd in debug mode, then register devices,
251              then check device's SMART status once, and then exit  with  zero
252              exit status if all of these steps worked correctly.
254              This last option is intended for 'distribution-writers' who want
255              to create automated scripts to determine whether or not to auto‐
256              matically start up smartd after installing smartmontools.  After
257              starting smartd with this  command-line  option,  the  distribu‐
258              tion's  install  scripts should wait a reasonable length of time
259              (say ten seconds).  If smartd has not exited with zero status by
260              that  time,  the  script should send smartd a SIGTERM or SIGKILL
261              and assume that smartd will not operate correctly on  the  host.
262              Conversely, if smartd exits with zero status, then it is safe to
263              run smartd in normal daemon mode.  If smartd is unable to  moni‐
264              tor any devices or encounters other problems then it will return
265              with non-zero exit status.
267              showtests - Start smartd in debug mode, then  register  devices,
268              then  write a list of future scheduled self tests to stdout, and
269              then exit with zero exit status if all  of  these  steps  worked
270              correctly.  Device's SMART status is not checked.
272              This  option  is  intended to test whether the '-s REGEX' direc‐
273              tives in smartd.conf will have the desired effect.   The  output
274              lists  the  next test schedules, limited to 5 tests per type and
275              device.  This is followed by a summary of all tests of each  de‐
276              vice within the next 90 days.
278       -r TYPE, --report=TYPE
279              Intended  primarily  to help smartmontools developers understand
280              the behavior of smartmontools on non-conforming  or  poorly-con‐
281              forming  hardware.  This option reports details of smartd trans‐
282              actions with the device.  The option can be used multiple times.
283              When  used  just once, it shows a record of the ioctl() transac‐
284              tions with the device.  When used more than once, the detail  of
285              these  ioctl() transactions are reported in greater detail.  The
286              valid arguments to this option are:
288              ioctl - report all ioctl() transactions.
290              ataioctl - report only ioctl() transactions with ATA devices.
292              scsiioctl - report only ioctl() transactions with SCSI devices.
294              nvmeioctl - report only ioctl() transactions with NVMe devices.
296              Any argument may include a positive integer to specify the level
297              of  detail that should be reported.  The argument should be fol‐
298              lowed by a comma then the integer with no spaces.  For  example,
299              ataioctl,2  The  default  level is 1, so '-r ataioctl,1' and '-r
300              ataioctl' are equivalent.
302       -s PREFIX, --savestates=PREFIX
303              Reads/writes  smartd  state  information  from/to  files   'PRE‐
304              FIX''MODEL-SERIAL.ata.state'     or    'PREFIX''VENDOR-MODEL-SE‐
305              RIAL.scsi.state'.  This preserves SMART  attributes,  drive  min
306              and  max temperatures (-W directive), info about last sent warn‐
307              ing email (-m directive), and the time  of  next  check  of  the
308              self-test REGEXP (-s directive) across boot cycles.
310              MODEL  and SERIAL are build from drive identify information, in‐
311              valid characters are replaced by underline.
313              If   the   PREFIX    has    the    form    '/path/dir/'    (e.g.
314              '/var/lib/smartd/'),  then  files  'MODEL-SERIAL.ata.state'  are
315              created in directory '/path/dir'.  If the PREFIX  has  the  form
316              '/path/name' (e.g. '/var/lib/misc/smartd-'), then files 'nameMO‐
317              DEL-SERIAL.ata.state' are created in  directory  '/path/'.   The
318              path must be absolute, except if debug mode is enabled.
320              The  state  information  files  are read on smartd startup.  The
321              files are always (re)written  after  reading  the  configuration
322              file,  before  rereading the configuration file (SIGHUP), before
323              smartd shutdown, and after a check forced by SIGUSR1.   After  a
324              normal  check  cycle,  a  file is only rewritten if an important
325              change (which usually results in a SYSLOG output) occurred.
327       -w PATH, --warnexec=PATH
328              Run the executable PATH  instead  of  the  default  script  when
329              smartd  needs  to  send warning messages.  PATH must point to an
330              executable  binary  file  or  script.   The  default  script  is
331              /etc/smartmontools/smartd_warning.sh.
333       -u USER[:GROUP], --warn-as-user=USER[:GROUP]
334              [NEW  EXPERIMENTAL SMARTD 7.3 FEATURE] Run the warning script as
335              a non-privileged user instead of root.  The  USER  and  optional
336              GROUP  may be specified as numeric ids or names.  If no GROUP is
337              specified, the default group of USER is used instead.
339              If a warning occurs, a child process is  created  with  fork(2).
340              This  process  closes  all  inherited file descriptors, connects
341              stdio to /dev/null, changes the user and group ids, removes  any
342              supplementary  group  ids  and  then calls the popen(3) function
343              from the standard library.
345              If '0:0' is specified, user and group are not changed,  but  the
346              remaining actions still apply.
348              If  '-'  is specified, popen(3) is called directly.  This is the
349              default.
351       -V, --version, --license, --copyright
352              Prints version, copyright, license, home page and  SVN  revision
353              information for your copy of smartd to STDOUT and then exits.


357       smartd
358       Runs  the daemon in forked mode.  This is the normal way to run smartd.
359       Entries are logged to SYSLOG.
361       smartd -d -i 30
362       Run in foreground (debug) mode, checking the disk status every 30  sec‐
363       onds.
365       smartd -q onecheck
366       Registers  devices,  and checks the status of the devices exactly once.
367       The exit status (the shell $?  variable) will be zero if all went well,
368       and  nonzero  if no devices were detected or some other problem was en‐
369       countered.


373       The syntax of the smartd.conf(5) file is discussed separately.


377       smartd will make log entries at loglevel  LOG_INFO  if  the  Normalized
378       SMART  Attribute values have changed, as reported using the '-t', '-p',
379       or '-u' Directives.  For example:
380       'Device: /dev/sda, SMART  Attribute:  194  Temperature_Celsius  changed
381       from 94 to 93'
382       Note  that in this message, the value given is the 'Normalized' not the
383       'Raw' Attribute value (the disk temperature in this case  is  about  22
384       Celsius).   The  '-R' and '-r' Directives modify this behavior, so that
385       the information is printed with the Raw values as well, for example:
386       'Device: /dev/sda, SMART  Attribute:  194  Temperature_Celsius  changed
387       from 94 [Raw 22] to 93 [Raw 23]'
388       Here  the  Raw values are the actual disk temperatures in Celsius.  The
389       way in which the Raw values are printed, and the names under which  the
390       Attributes  are  reported,  is governed by the various '-v Num,Descrip‐
391       tion' Directives described previously.
393       Please see the smartctl manual page for further explanation of the dif‐
394       ferences between Normalized and Raw Attribute values.
396       smartd  will make log entries at loglevel LOG_CRIT if a SMART Attribute
397       has failed, for example:
398       'Device: /dev/sdc, Failed SMART Attribute: 5 Reallocated_Sector_Ct'
399       This loglevel is used for reporting enabled by the '-H', -f', '-l self‐
400       test',  and  '-l error' Directives.  Entries reporting failure of SMART
401       Prefailure Attributes should not be ignored: they mean that the disk is
402       failing.  Use the smartctl utility to investigate.


406       When smartd makes log entries, these are time-stamped.  The time stamps
407       are in the computer's local time zone, which is generally set using ei‐
408       ther  the  environment  variable 'TZ' or using a time-zone file such as
409       /etc/localtime.  You may wish to change the timezone  while  smartd  is
410       running  (for  example,  if  you  carry a laptop to a new time-zone and
411       don't reboot it).  Due to a bug in the tzset(3) function of  many  unix
412       standard  C libraries, the time-zone stamps of smartd might not change.
413       For some systems, smartd will work around this problem if the time-zone
414       is set using /etc/localtime.  The work-around fails if the time-zone is
415       set using the 'TZ' variable (or a file that it points to).


419       The exit status (return value) of smartd can have the following values:
421       0:     Daemon startup successful, or smartd was killed by a SIGTERM (or
422              in debug mode, a SIGQUIT).
424       1:     Commandline did not parse.
426       2:     There was a syntax error in the config file.
428       3:     Forking the daemon failed.
430       4:     Couldn't create PID file.
432       5:     Config  file  does  not exist (only returned in conjunction with
433              the '-c' option).
435       6:     Config file exists, but cannot be read.
437       8:     smartd ran out of memory during startup.
439       10:    An inconsistency was found in smartd's internal data structures.
440              This  should never happen.  It must be due to either a coding or
441              compiler bug.  Please report such failures to smartmontools  de‐
442              velopers, see REPORTING BUGS below.
444       16:    A  device  explicitly  listed  in /etc/smartmontools/smartd.conf
445              can't be monitored.
447       17:    smartd didn't find any devices to monitor.
448              [NEW EXPERIMENTAL SMARTD 7.3 FEATURE] This could be changed to 0
449              (success) with one of the '-q *nodev0*' options, see above.
451       254:   When in daemon mode, smartd received a SIGINT or SIGQUIT.  (Note
452              that in debug mode, SIGINT has the same effect  as  SIGHUP,  and
453              makes  smartd  reload  its  configuration file.  SIGQUIT has the
454              same effect as SIGTERM and causes smartd to exit with zero  exit
455              status.
457       132 and above
458              smartd  was  killed  by  a  signal that is not explicitly listed
459              above.  The exit status is then 128 plus the signal number.  For
460              example  if smartd is killed by SIGKILL (signal 9) then the exit
461              status is 137.


465       /usr/sbin/smartd
466              full path of this executable.
468       /etc/smartmontools/smartd.conf
469              configuration file (see smartd.conf(5) man page).
471       /etc/smartmontools/smartd_warning.sh
472              script run on warnings (see '-w' option above and '-M exec'  di‐
473              rective on smartd.conf(5) man page).
475       /etc/smartmontools/smartd_warning.d/
476              plugin  directory  for smartd warning script (see '-m' directive
477              on smartd.conf(5) man page).
479       /usr/share/smartmontools/drivedb.h
480              drive database (see '-B' option).
482       /etc/smartmontools/smart_drivedb.h
483              optional local drive database (see '-B' option).


487       Bruce Allen (project initiator),
488       Christian Franke  (project  manager,  Windows  port  and  all  sort  of
489       things),
490       Douglas Gilbert (SCSI subsystem),
491       Volker Kuhlmann (moderator of support and database mailing list),
492       Gabriele Pohl (wiki & development team support),
493       Alex Samorukov (FreeBSD port and more, new Trac wiki).
495       Many other individuals have made contributions and corrections, see AU‐
496       THORS, ChangeLog and repository files.
498       The first smartmontools code was derived from the  smartsuite  package,
499       written by Michael Cornwell and Andre Hedrick.


503       To submit a bug report, create a ticket in smartmontools wiki:
504       <https://www.smartmontools.org/>.
505       Alternatively send the info to the smartmontools support mailing list:
506       <https://listi.jpberlin.de/mailman/listinfo/smartmontools-support>.


510       smartd.conf(5), smartctl(8).
511       update-smart-drivedb(8).
512       systemd.exec(5).


516       Please see the following web site for more info: <https://www.smartmon
517       tools.org/>
519       An introductory article about smartmontools is  Monitoring  Hard  Disks
520       with  SMART,  by Bruce Allen, Linux Journal, January 2004, pages 74–77.
521       See <https://www.linuxjournal.com/article/6983>.
523       If you would like to understand better how SMART  works,  and  what  it
524       does,  a good place to start is with Sections 4.8 and 6.54 of the first
525       volume of the 'AT Attachment  with  Packet  Interface-7'  (ATA/ATAPI-7)
526       specification  Revision  4b.   This  documents  the SMART functionality
527       which the smartmontools utilities provide access to.
529       The functioning of SMART was originally defined by the SFF-8035i  revi‐
530       sion 2 and the SFF-8055i revision 1.4 specifications.  These are publi‐
531       cations of the Small Form Factors (SFF) Committee.
533       Links to these and other documents may be found on the  Links  page  of
534       the smartmontools Wiki at <https://www.smartmontools.org/wiki/Links>.


538       smartmontools-7.4 2023-08-01 r5530
539       $Id: smartd.8.in 5521 2023-07-24 16:44:49Z chrfranke $
543smartmontools-7.4                 2023-08-01                         SMARTD(8)