Domotica y Software libre

Hace unos meses ya, hice el cambio de Debian (rama "testing") a Arch Linux. Uno de las distintas cosas a las que tuve que adaptarme en esa migración fue pasar de un sistema que  por ese entonces aún utilizaba SysVinit como gestor de servicios a uno que utiliza SystemD.  Para mí este era un punto importante, debido a las conocidas quejas que ha habido (y sigue habiendo) sobre SystemD. Hoy he querido compartir con vosotros mis impresiones sobre este sistema. La experiencia de usuario de un gestor de servicios no es algo que se constate de la misma forma que, por ejemplo, la de un entorno de escritorio o una aplicación en concreto.  El gestor de servicios es un elemento que, bajo funcionamiento normal, no se interpone en el funcionamiento del sistema: una vez que el sistema arranca el núcleo y este le pasa el relevo al proceso  init , si no hay problemas (y no debería haberlos si todo está configurado como debe), se iniciará la entrada de usuario (ya sea login en una c

En Java, hay varios parámetros para controlar el  tamaño inicial  y el  tamaño máximo  que puede tomar la máquina virtual. Además, hay que tener en cuenta el tipo de memoria sobre el que se quiere actuar:  heap ,  non-heap  ( PermGen ). Los valores por defecto que se dan corresponden a máquina virtuales de Sun, y son orientativos, porque pueden cambiar entre versiones de la máquina virtual. Los parámetros son los siguientes, fijándose a 128Mb. -Xms128m :  Tamaño de inicio  de la máquina virtual de Java a 128Mb. El valor por defecto son 64Mb. Si se aumenta este valor, se elimina el tiempo que se tardaría en aumentar el tamaño en memoria de la máquina virtual si se llegara el caso de que se necesitara más memoria, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria. -Xmx128m :  Tamaño máximo  de la máquina virtual de Java a 128Mb.  El valor por defecto son 128Mb. Si la aplicación supera el tamaño máximo de memoria que marca este pará

Kill: matar un proceso usando su PID La forma más complicada pero al mismo tiempo más precisa de matar un proceso es a través de su PID (siglas en inglés de “Identificador de Proceso”). Cualquiera de estas 3 variantes puede servir: kill -TERM pid kill -SIGTERM pid kill -15 pid Se puede usar el nombre de la señal (TERM o SIGTERM) que se desea mandar al proceso o su número de identificación (15). Para ver un listado completo de las posibles señales, sugiero verificar el manual de kill. Para ello, ejecutá: man kill Veamos un ejemplo de cómo matar Firefox: Primero, hay que averiguar el PID del programa: ps -ef | grep firefox Ese comando devolverá algo parecido a esto: 1986 ?        Sl     7:22 /usr/lib/firefox-3.5.3/firefox Usamos el PID devuelto por el comando anterior para aniquilar el proceso: kill -9 1986 killall: matar un proceso usando su nombre Este comando es bien fácil killall nombre_proceso Un dato a tener en cuenta al usar este método es que en caso de q

  En ocasiones nos podremos encontrar con la necesidad de monitorizar con Nagios un proceso (entendido como aplicación en ejecución) que se encuentra en ejecución en un sistema Windows.  Para ello se puede emplear  el plugin  check_winprocess  ( https://www.itefix.no/i2/check_winprocess  ) creado por la empresa Itefix.   Se trata de un plugin basado en NRPE, aplicación que permite ejecutar remotamente plugins de Nagios en otras máquinas, bajo Linux o bajo Windows.      Para hacer funcionar NRPE en el cliente se ha utilizado NSClient++, concretamente la versión 0.3.9 : http://sourceforge.net/projects/nscplus/files/nscplus/NSClient%2B%2B%200.3.9/ . La última versión de NSClient++ a fecha de creación de este artículo (0.4.1.73) no funciona correctamente    para nuestro propósito.    Una vez instalado NSClient++ (marcar como mínimo  check_nrpe  en el proceso de instalación) deberemos copiar el ejecutable  check_winprocess.exe  dentro del directorio  scripts de NSClien