LOG del sistema ¿ Puedo saber cuando se produjo ShutDown y porque ?

[elrosti]

Estimados:

Me gustaría saber si es posible saber que es lo que produjo que mi notebook se apague, es decir, quiero saber si por ejemplo fue porque alguien dejó presionado el botón de apagar, si fue porque se le acabo la batería o si se apago correctamente. ¿ hay algun lugar donde me pueda fijar esta información ?.

Saludos.

[ZeiterZ]

Fijate en

/var/log/syslog
y
/var/log/daemon.log

los mensajes en ellos te van a guiar.

Saludos.

[elrosti]

Buenisimo ZeiterZ, voy a vichar esos logs. Basicamente lo que yo quiero saber es si alguien apreto el boton de power de mi notebook a determinada hora (conozco la hora aproximada en que mi notebook se apago porque VUZE (Cliente BitTorrent) me dejo eso registrado en su LOG)

¿ Hay algo en particular que debería buscar ?

[ZeiterZ]

También fijate en

/var/log/messages
/var/log/pm-suspend
/var/log/user.log

Por ejemplo, un apagado "normal" deja un mensaje de este tipo en /var/log/daemon.log:

Código [Seleccionar] Expandir


Aug 11 00:16:33 m2 init: Switching to runlevel: 0
Aug 11 00:16:42 m2 mountd[2901]: Caught signal 15, un-registering and exiting.
Aug 11 00:16:43 m2 avahi-daemon[2374]: Got SIGTERM, quitting.
Aug 11 00:16:43 m2 avahi-daemon[2374]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::211:2fff:fe78:13cd.
Aug 11 00:16:43 m2 avahi-daemon[2374]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.202.
Aug 11 00:16:43 m2 NetworkManager: <WARN>  nm_signal_handler(): Caught signal 15, shutting down normally.
Aug 11 00:16:43 m2 NetworkManager: <info>  exiting (success)
Aug 11 00:16:44 m2 acpid: exiting
Aug 11 00:16:44 m2 nm-system-settings:    SCPlugin-Ifupdown: devices removed (udi: /org/freedesktop/Hal/devices/net_00_11_2f_78_13_cd)
Aug 11 00:16:44 m2 nm-system-settings:    Ifupdown: get unmanaged devices count: 0
Aug 11 00:16:44 m2 ntfs-3g[1876]: Unmounting /dev/hda1 ()


/var/log/messages mostrará para la misma hora:

Código [Seleccionar] Expandir

Aug 11 00:16:32 m2 shutdown[5553]: shutting down for system halt
Aug 11 00:16:42 m2 kernel: [18936.063356] nfsd: last server has exited
Aug 11 00:16:42 m2 kernel: [18936.063362] nfsd: unexporting all filesystems


Un evento "suspender" (al pulsar el botón Sleep) genera esto en /var/log/pm-suspend.log:

Código [Seleccionar] Expandir

/usr/lib/pm-utils/sleep.d/00powersave suspend suspend: success.


La idea es que revises los archivos de logs unos momentos antes del apagado. Ahí deberían aparecer indicios de lo que sucedió.

En este momento no encuentro ningún registro con la línea que aparece cuando se pulsa el botón de apagado de la máquina.

Saludos.

[elrosti]

ZeiterZ, no encontre ni daemon.log ni syslog. Tampoco encontre user.log ¿ será que están en otro lugar en openSuSE ?

Saludos.

PD: Igual messages.log me dijo lo que queria saber, alguien intentó sacar mi clave (Tengo la sesion con contraseña despues de unos minutos) y como no pudo apago la PC directamente  .

[elrosti]

Perdon por el doble post pero creo que la ocación lo amerita  .

Por las dudas y para que se entienda, les comento que en estos momentos por cuestiones laborales y de cambio de ciudad estoy viviendo en una residencia donde "alquilo" una habitación pero vivo con muchisimas personas más (30 aprox)

Esta noche me volvió a pasar lo mismo, al despertar e ir a buscar mi notebook la encuentro nuevamente apagada siendo que yo la había dejado prendida.

"/var/log/messages" me muestra que a las 5:35 hay una secuencia de booteo donde se inician todos los servicios, etc, hasta la pantalla de login (La cual queda en consola porque la opcion por defecto del grub no inicia x Server correctamente). Despues de eso me muestra una linea que dice algo como "/dev/tty0.....usuario no reconocido blah blah blah" lo que me da la censacion de que alguien escribio algo como lógin y le erro fiero y despues la apagó a prepo (repito que la encontré apagada completamente).

Para saber si lmis sospecas de que fue lo que había sucedido a las 5:35 era correcto:

1) Que la habían apagadao
2) Se había iniciado con la opcion por defecto del grub
3) habían intentado loguearse sin exito
4) La apagaron de prepo

Reproducí estos pasos y para mi satisfacción, el log generado luego de hacer estos pasos fue casi identico al que había quedado registrado a las 5:35.

Me gustaría saber que otras logs puedo revisar porque como dije en el mensaje anterior no encuentro los demas archivos que se indican aunque messages me brinda información interesante.

En estos momentos estoy acusando a una persona de tocar mi notebook cuando no tiene ningun derecho asíq ue me gustaría tener mejores herramientas para demostrarlo y para confirmar que mis sospechas son ciertas.

Desde ya les agradezco su ayuda.

Saludos.

[ZeiterZ]

En /var/log/auth.log  se registran los accesos de los usuarios.

Fijate que al presionar el botón de apagado se genera un evento y debería registrarse en syslog, en messages o en daemon.log.

Deberías revisar cada archivo de log en /var/log y directorios contenidos.

Saludos.

[elrosti]

ok, voy a revisar, en messages no quedó nada que me indique que se precionó el botón de apagado, tampoco quedo registro de que se apagó correctamente (que si queda registrado als demas veces).

¿ En "/var/log/auth.log" quedán regisrados tambien los intentos fallidos de acceso y que escribieron como nombre de usuario ?.

Lamentablemente no encuentro el daemon.log ni el syslog.log por ningun lado, voy a revisar los demas archivos a ver si encuentro algo interesante.

Saludos.

[ZeiterZ]

En auth.log se registran los intentos de acceso y los accesos. Y con el comando lastlog te muestra el último acceso válido de todos los usuarios.

Eso sí, los archivos que mencioné son los que se usan en Debian y derivados. Es de esperar que las otras distribuciones tengan registros equivalentes aunque puedan llamarse de otra manera o estar en algún subdirectorio.

Saludos.

[elrosti]

El comando lastlog funciona perfectamente, pero no encuentro ningun auth.log ni nada parecido.

Estaría bueno poder ver todo esta información ¿ no será que no estan habilitados los servicios/opciones necesarias para que estos archivos sean creados ? instalé el ksyslogwatch desde los repositorios de openSuSE y trata de abrir estos mismos archivos que tu me nombras, pero obviamente no los encuentra.

Saludos.

[ZeiterZ]

Perdón por responder todo tan desordenadamente.

Primero habría que ver qué daemon de logging está usando el sistema:

$ ps -e | grep log

Código [Seleccionar] Expandir

3239 ?        00:00:14 rsyslogd

en este caso, se usa rsyslog y la configuración del demonio está en /etc/rsyslog.conf

Ahí podrás ver a dónde va a escribir los mensajes correspondientes a eventos del sistema, por ejemplo, un

# grep  .log  /etc/syslog.conf   tira (parcialmente)

Código [Seleccionar] Expandir


auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslogdaemon.*                        -/var/log/daemon.logkern.*                          -/var/log/kern.loglpr.*                           -/var/log/lpr.logmail.*                          -/var/log/mail.loguser.*                          -/var/log/user.logmail.info                       -/var/log/mail.infomail.warn                       -/var/log/mail.warnmail.err                        /var/log/mail.errnews.crit                       /var/log/news/news.critnews.err                        /var/log/news/news.errnews.notice                     -/var/log/news/news.notice

en donde se ve claramente que los eventos "auth" se registran en /var/log/auth.log y, también, qué eventos se registran en /var/log/syslog y /var/log/daemon.log

Si el "logger" es syslogd/klogd, la configuración está en /etc/syslogd.conf

De última, un

# grep "/var/log/messages" /etc/*

te dará una pista de qué archivos hacen mención de "/var/log/messages"... y entre ellos estará el de configuración del logger.

Saludos.

[elrosti]

ZeiterZ, por los comandos que me hiciste tirar los 2 daemon que estan corriendo son klogd y syslog-ng.

No encontré el archivo de configuracion de klogd, si encontré en /etc/syslog-ng/syslog-ng.conf lo que parece ser el archivo de configuración de syslog-ng, lo miré un poco y revisé los archivos a los que hace mención pero no encontré la información que quería (Los intentos de loging por ejemplo)

¿ Puedo desinstalar klogd y syslog-ng para luego instalar rsyslogd ? ¿ Lo recomendarías ?

De todas maneras, los responsables del lugar donde vivo hablaron con el sospechoso de apagar mi notebook, esta mañana la misma apareció intacta y funcionando (Con VUZE al palo  ).

Saludos.

[ZeiterZ]

El par syslog y klogd han venido utilizándose en Linux desde hace bastante tiempo. syslog-ng es una versión mejorada de syslog.
De la misma manera, rsyslog es un syslog multihilo mejorado y enfocado en la seguridad.

syslog/klogd se ha usado Debian hasta la versión 4.0 (Etch). A partir de la versión 5.0 (Lenny) ya se usa rsyslogd.

En una estación de trabajo hogareña no creo que existan muchas diferencias en cuanto a prestaciones entre syslog y rsyslog. La brecha puede notarse en servidores cargados o en redes con varios servidores y estaciones monitoreadas centralmente, etc.

Más info:
http://www.rsyslog.com/
http://www.rsyslog.com/doc-rsyslog_ng_comparison.html
http://www.mmc.igeofcu.unam.mx/LuCAS/Manuales-LuCAS/doc-unixsec/unixsec-html/node86.html

Saludos.

[elrosti]

En castellano, es todo cuestion de configurar bien syslog-ng para que genere los archivos correspondientes no ?

Saludos.

[ZeiterZ]

O simplemente fijarse a dónde envía las anotaciones para cada tipo de evento.

Podrías postear

/etc/syslog-ng/syslog-ng.conf

o compararlo con este otro de Debian Etch:

Código [Seleccionar] Expandir

#  /etc/syslog.conf     Configuration file for syslogd.         
#                                                               
#                       For more information see syslog.conf(5) 
#                       manpage.                                 

#
# First some standard logfiles.  Log by facility.
#                                               

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log 
lpr.*                           -/var/log/lpr.log   
mail.*                          -/var/log/mail.log 
user.*                          -/var/log/user.log 
uucp.*                          /var/log/uucp.log   

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Logging for INN news system
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Some `catch-all' logfiles.
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg                         *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#       news.=crit;news.=err;news.=notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       /dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
        news.crit;news.err;news.notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole


Saludos.