¿Cómo evito que se me informe "Se ha detectado un problema en un programa del sistema" en Ubuntu? Juan Perón explica las necedad del simple liberalismo económico, y explica también cómo evitar el cartel "se ha detectado un problema en un programa de sistema" en Ubuntu. (...) La libertad se defiende en el campo, en el taller, en la calle, en la casa y en todas partes, porque no se puede aceptar que uno sea libre en su casa mientras es esclavo en el taller, en la fábrica, en la calle o su software es esclavo. Es necesario que los obreros comprendan esto. Deben seguir adelante con su organización y defender su software libre. La libertad individual es la base de la libertad colectiva, y esta es base de la libertad del software. Nuestro Movimiento busca establecer la pureza de las instituciones democráticas, removiendo todas las causas que habían originado su innegable decadencia. Este movimiento innovador se esfuerza para lograr una total recuperación moral del pueblo de la República, que consiste en alcanzar una libertad política interna plena, la que para ser tal, exige la solución previa de los problemas sociales. Esto no es restringir la libertad, sino justamente imponerla y asegurarla para todos. Contra sofismas y dictaduras de quienes paradójicamente se proclaman liberales y propugnan el software privativo, decimos la verdad. El peor mal es liberalismo económico, que invocando una libertad, no deja ejercer las otras libertades. La sociedad para existir, exige que la libertad de unos subsista con la libertad de todos. En nombre de una libertad no pueden anularse vidas, vocaciones o espíritus. La Nación Argentina no puede cancelar su destino ni malograr sus fines, para que cierta libertad, liberticida, sobreviva. En toda conducción, en ocasiones se producen errores que deben ser subsanados con una combinación de conocimiento y acción. Algunos problemas pueden acarrear enormes dificultades y ser compuestos, pero si nuestro manejo es adecuado, la mayoría de los errores podrán subsanarse muy fácilmente. El sistema GNU con Linux está diseñado para ser un sistema de bajo mantenimiento. Sin embargo, el mismo requiere ciertos conocimientos, por ello que existen dos categorías de usuarios. El usuario común poco puede hacer por el bien del sistema más que disfrutarlo. El Conductor (también llamado "root"), , debe contar en tanto con gran expertise y su tarea fundamental es la de entender el manejo del sistema y administrarlo para el bien de sus usuarios. En ocasiones, ciertos errores de sistema son informados al usuario común. Normalmente esto también es informado al administrador de sistema, quien se encarga de resolverlos. Sin embargo, no es poco común - en vista que GNU cada vez es más popular y utilizado por usuarios únicos en sus propios sistemas - que los errores sean de notificación doble. En estos casos, pocas veces existe un "administrador" como tal, y se trata de un usuario que debe reunir condiciones de experto en su propio sistema. Para subsanar esto, ciertas distribuciones de GNU - Ubuntu entre ellas - cuentan con un reportador de errores especial. Por ejemplo, en Ubuntu contamos con el programa Apport, que toma inmediatamente el control tras el inicio del escritorio gráfico del sistema operativo, y si detecta un reporte error destinado para el administrador, le ofrece al usuario ofrece la posibilidad de informar al fabricante Canonical. De esta manera, si no tenemos Administrador de sistema capacitado, supuestamente los desarrolladores del sistema operativo podrían corregir ciertos errores recurrentes. La manifestación de Apport será obvia: recibiremos un alerta de error del tipo “System program problem detected“. Se trata de un reporte de error suele aparecer justo después de iniciar sesión en el sistema operativo. En algunos casos aparece en inglés “System program problem detected“, y otras veces en castellano, ”Se ha detectado un problema en un programa del sistema“. Cualquiera sea el caso, basta con hacer clic sobre el botón Cancelar y podremos seguir utilizando el sistema operativos sin contratiempo aparente. Si presionamos Informar del Problema... se enviará el volcado a Canonical. En cualquier caso, Apport no nos ofrece información alguna que podamos utilizar como referencia para saber qué es lo que esta causando el problema, y por lo tanto a prima facie no podremos resolverlo. En fin, termina siendo una molestia. Muchas veces el error surge cuando algún programa se "cuelga" y continúa produciendo estos reportes de error, o bien cuando el mismo sistema no puede eliminar los mensajes de error a tiempo (generalmente, por ser demasiado grandes). En este caso el problema será persistente, y toda vez que iniciemos el sistema se mostrará el cartel de error, tornándose en algo muy molesto. Si el problema persiste, tendremos dos caminos para seguir: uno es ver indirectamente qué está causando el o los reportes de error y borrar dichos reportes a mano. La otra opción menos deseable es seguir el viejo apotegma que reza "ojos que no ven, corazón que no siente", y directamente anular el sistema de reporte Apport. Vean señores, en mi caso el problema se produjo por una situación única y obvia: en un momento se aflojó físicamente una placa adaptadora PCI dentro de la computadora (una sintonizadora de TV conectada por medio de unos incómodos y duros cables coaxiales). Ello generó naturalmente una falla leve de hardware, pero que terminó colgando el sistema, con el consabido mensaje de error. Indudablemente que en otras ocasiones, puede hacerse muy difícil entender qué es lo que está provocando el error. Es importante conocer entonces que todo reporte de sistema se almacenará en la carpeta /var/crash/. Revisando la misma podremos obtener alguna pista para nuestro trabajo detectivesco, si es que así nos vemos obligados a proceder. En tal sentido, abrimos una terminal con Ctrl+Alt+T e ingresamos los siguientes comandos de organización: cd /var/crash/ ls * ...con estas órdenes el sistema debería de devolvernos una lista de reportes con extensión .crash, que indican qué archivos de programas o procesos tuvieron errores persistentes. Por ejemplo: _root_lib_journal_xxx.0.crash _usr_lib_chromiun_xxxx.1.crash (...etc) Estos archivos explican ciertos errores de acciones que se estaban llevando a cabo en el momento del cuelgue de sistema, y contienen un volcado de memoria del mismo. En ocasiones estas fallas persisten, o son muy grandes (por ejemplo, el archivo del navegador Chromiun). Si existen varias fallas y no sabemos cuál de todas es el error es el persistente, podríamos borrar todos los reportes de extensión .crash, y reiniciar el sistema. Si vuelve a aparecer un error o varios, ellos serán los principales sospechosos. Para borrar los reportes almacenados en el directorio /var/crash/ ingresamos en la terminal: cd /var/crash/ sudo rm * ...el sistema nos solicitará nuestra contraseña de usuario, y al ingresarla "a ciegas" seguida de Enter, eliminará los reportes de error almacenados. Acto seguido podremos reiniciar el sistema con: sudo reboot A la vuelta, ya debería dejar de aparecer el molesto cartel de error de programa de sistema. Si esto es así, significa que se trataba de un error de única vez, y ya estará solucionado el problema. En cambio, si el cartel continúa apareciendo, al menos ahora podremos identificar cual es la causa, pues se debería haber generado un nuevo reporte de error .crash. En tal caso abrimos una terminal con Ctrl+Alt+T y volvemos a listarlo para ver qué es lo que falla específicamente. cd /var/crash/ ls -lah Normalmente debería indicarse el directorio vacío, por ejemplo de la siguiente forma: drwxrwsrwt 2 root whoopsie 4,0K mar 15 10:51 ./ drwxr-xr-x 16 root root 4,0K ago 21 2018 ../ Si algún error se produce durante el arranque, además de estos dos instancias deberíamos tener al menos un reporte en este directorio. Este es el problema sobre el cual podremos buscar ayuda más avanzada. Por ejemplo, en nuestro caso se trataba de un Chromiun subiendo un archivo de muy grandes dimensiones, lo que dejó saturado el volcado de memoria del error. Tal problema fue fácil de remediar eliminando los archivos temporales de Chromiun y continuando su uso de manera normal. Pues bien, si el problema continúa, puede que queramos desactivar el servicio Apport definitivamente. Para conseguirlo, sólo debemos editar su archivo de configuración /etc/default/apport. Para ello abrimos una terminal e ingresamos: sudo nano /etc/default/apport Tras ingresar nuestra contraseña de administrador, se abrirá el editor de texto GNU Nano con el archivo de configuración. Al final del mismo encontraremos la linea "enabled=1". Debemos modificarla para que quede "enabled=0". Una vez cumplimentada esta simplísima modificación, guardamos el archivo presionando Ctrl+o (debemos confirmarlo presionando Enter). Conforme esté guardado el archivo, salimos del editor presionando Ctrl+x. Si anhelamos que la configuración se active de forma inmediata, es suficiente con reiniciar el servicio usando el siguiente comando sudo restart apport Con esto, el problema ha debido quedar resuelto.