Re: Problemas de dependencia(actualización emacs24 debian testingI

2015-09-27 Por tema Camaleón 
El Sat, 26 Sep 2015 20:22:43 -0500, Cesar Peña escribió:

(ese html...)

> Hola Buenas noches.
> Hace una semana esta intentando tener Debian(unstable), todo me
> funcionaba bien.

Pues es una suerte porque Sid es proclive a tener problemas, normal 
tratándose de una versión con cambios constantes.

> Pero hace dos días al actualizarlo, me genero errores de dependencias
> del programa emacs24.
> Por lo que lo abandone y reinstale mi SO y me quede con Debian testing.

Pero hombre... ¡qué radical! :-)

Si tienes Sid es que sabes lo que instalas y sabes cómo convivir con esos 
problemas de lo contrario no merece la pena instalarla.

> Hoy al querer actualizar, me apareció el mismo error :(
> No encuentro forma de resolverlo.
> No me deja desinstalar emacs24 por que se quiere actualizar y si recibo
> actualizaciones no se aplican por lo mismo. No me deja instalar nada.

En resumen, que estás atrapado en un bucle paquetil.

> Este es el error:
> ya utilice apt-get -f install (no hace nada)
> Se instalarán los siguientes paquetes extras:
>   emacs24 emacs24-bin-common emacs24-common
> Paquetes sugeridos:
>   emacs24-common-non-dfsg emacs24-el
> Se instalarán los siguientes paquetes NUEVOS:
>   emacs24-bin-common emacs24-common
> Se actualizarán los siguientes paquetes:
>   emacs24
> Y son mucho más lineas de error :(

A ver... pon el comando que quieres ejecutar y el error exacto que te 
aparece, no quites ni añadas nada, y si es muy extenso súbelo a 
www.pastebin.com.

> ya intente quitarlo desde synaptic y tampoco funciona aparece el mismo
> error.

(...)

Error que no sabemos cuál es.

Saludos,

-- 
Camaleón

Re: Problemas de memoria

2015-09-27 Por tema Manolo Díaz 
El domingo, 27 sep 2015 a las 14:00 UTC
Santiago Vila escribió:

> On Sun, Sep 27, 2015 at 01:46:14PM +0200, José Miguel (sio2) wrote:
> > Parece que hay memoria libre, pero si por:
> > 
> > vm.overcommit_memory = 2
> > 
> > no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es
> > plausible pensar que se llegó a ese límite cuando no podía acceder al
> > servidor.
> 
> Esto es lo que te decía antes. Si no dices nada más entonces la memoria
> que puede asignar es swap + 50% de la RAM.
> 
> Si tienes 2GB de swap y 8GB de RAM, te estás limitando a usar 6 GB de
> memoria en total. Pero tienes 8 GB así que estás desaprovechando
> completamente 2 GB de RAM de la forma más escandalosa.
> 
> Si de verdad no quieres que pida más de 8 Gigas, sube el SWAP a 4 Gigas
> manteniendo la regla de SWAP + 50% de RAM. Pero incluso así estarías
> desaprovechando la memoria disponible. Si las aplicaciones "piden" el
> doble de lo que realmente necesitan y decides darles 8 Gigas como
> máximo, entonces solamente llegarás a usar 4 GB de verdad.
> 
> Por supuesto que es una exageración, pero es para que te hagas una idea.
> 
> Otra posibilidad es dejarle que use *toda* la memoria disponible:
> 
> vm.overcommit_memory = 2
> vm.overcommit_ratio = 100
> 
> > @ManoloDiaz
> > > Sugiero que investigues el ajuste OOM score, se hace por procesos y
> > > creo que systemd lo gestiona sin dificultad. Así podrías establecer
> > > una jerarquía para ver cuáles son los últimos en ser aniquilados por
> > > el núcleo cuando empieza a faltar memoria.
> > 
> > Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH
> > tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el
> > oom-killer no se lo cargará, cosa que me interesa.
> 
> No te interesa que se cargue *ningún* proceso.
> 
> Esto del OOM killer en realidad es una aberración. Es como si unas
> líneas aéreas deciden que cuando un avión está bajo de combustible
> se elige un pasajero al azar y le dan al botón de "eject" para
> ese pasajero.

Al azar no. Los mantenedores de sshd parecen estar lo bastante lúcidos
como para hacer que esté disponible casi en cualquier contingencia.
En un caso como este en el que el servidor está en "El País de Muy, Muy
Lejano" eso es de lo más conveniente.
 
> Mejor lee el original de Andries Brouwer:
> 
> https://lwn.net/Articles/104185/
> 
> No pierdas el tiempo haciendo "ajustes" del OOM killer. Es como si te
> andaras rompiendo la cabeza afinando el algoritmo por el que se decide
> qué pasajero expulsas del avión...
 
No es muy elegante, pero no creo que los desarrolladores de Linux se
hayan levantado un día aburridos y decidieran programar una aberración.
Parece que las soluciones obvias al límite de la memoria son (aparte de
aumentarla) o eliminar procesos, o impedir que se lancen nuevos.
Y te ofrecen que elijas entre dos soluciones nada elegantes.

-- 
Manolo Díaz

Re: localhost sin acceso

2015-09-27 Por tema Camaleón 
El Sat, 26 Sep 2015 19:00:33 -0500, Ricardo Mendoza escribió:

> Perdon no habia tenido tiempo para volver al foro,He habilitado el texto
> plano, no se porque aparece en formato enriquecido,

Pues sigues enviando con formato html y haciendo top-posting. Lo corrijo.
 
> El 30 de agosto de 2015, 12:40, Camaleón  escribió:

(...)

>> >> En cualquier caso, revisa siempre los registros de Apache que te
>> >> dirán qué es lo que está pasando.
>>
>> > En los tres caso no carga nada, solo una pagina de error,
>>
>> Bien, entonces el registro que debes mirar es el" error_log", ahí
>> tendrás el 404 y podrás ver si la ruta al recurso es correcta o no.
>>
>> En cualquier caso, si dices que da error me parece que o has
>> configurado mal el sitio web o te falta algún parámetro, para lo cual
>> tendrás que revisar la configuración que hayas hecho del servidor web y
>> mandar los datos a la lista (omite datos sensibles en caso de
>> haberlos).
>>
>> Si has seguido alguna guía o manual para ponerlo en marcha, manda el
>> enlace para que le echemos un vistazo.
>>
>> Manda también la salida de estos comandos (omite datos sensibles en
>> caso de haberlos):
>>
>> cat /etc/hosts ls -la /var/www/*
>>
>> > quiero que se vea una pagina web que esta en /var/www, en los
>> > registros de apache aparece esto.
>>
>> (...)
>>
>> > [Sun Aug 30 09:49:29.127354 2015] [mpm_event:notice] [pid 1317:tid
>> > 3073488704] AH00493: SIGUSR1 received.  Doing graceful restart
>> > AH00558: apache2: Could not reliably determine the server's fully
>> > qualified domain name, using ::1. Set the 'ServerName' directive
>> > globally to suppress this message
>>
>> Lo que te dice el mensaje es que tienes que definir la directiva
>> "ServerName", que tendrás que añadir en el archivo que hayas usado para
>> configurar Apache (normalmente "/etc/apache2/conf.d/httpd.conf").
>>
>> En el archivo tendrías que añadir algo como:
>>
>> ServerName localhost
>>
>> Y recargar la configuración de Apache.
>>

> en var/log/apache2/less error.log

(...)

No, no me sirve ese registro :-)

Tienes que cargar una página web, que te dé error (manda un pantallazo 
del mismo) y entonces revisar el "error.log" para ver el origen de ese 
mensaje. Si te aparece nada nuevo en el registro entonces lo interesante 
es saber qué ves en la página que carga apache.
 
> con cat /etc/hosts
> 
> 127.0.0.1localhost miweb.net localhost 
> 192.168.0.1 miweb.net miweb 
> ::1localhost ip6-localhost ip6-loopback 
> fe00::0   ip6-localnet 
> ff00::0ip6-mcastprefix 
> ff02::1ip6-allnodes
> ff02::2ip6-allrouters

Bien, te falta otro comando (ls -la /var/www/*) y añadir la directiva que 
te decía en el mensaje anterior en el archivo de configuración de Apache2.

¿Qué sucede cuando intentas acceder con 192.168.0.1/misitio?

Saludos,

-- 
Camaleón

Re: Problemas de memoria

2015-09-27 Por tema Santiago Vila 
On Sun, Sep 27, 2015 at 01:46:14PM +0200, José Miguel (sio2) wrote:
> Parece que hay memoria libre, pero si por:
> 
> vm.overcommit_memory = 2
> 
> no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es
> plausible pensar que se llegó a ese límite cuando no podía acceder al
> servidor.

Esto es lo que te decía antes. Si no dices nada más entonces la memoria
que puede asignar es swap + 50% de la RAM.

Si tienes 2GB de swap y 8GB de RAM, te estás limitando a usar 6 GB de
memoria en total. Pero tienes 8 GB así que estás desaprovechando
completamente 2 GB de RAM de la forma más escandalosa.

Si de verdad no quieres que pida más de 8 Gigas, sube el SWAP a 4 Gigas
manteniendo la regla de SWAP + 50% de RAM. Pero incluso así estarías
desaprovechando la memoria disponible. Si las aplicaciones "piden" el
doble de lo que realmente necesitan y decides darles 8 Gigas como
máximo, entonces solamente llegarás a usar 4 GB de verdad.

Por supuesto que es una exageración, pero es para que te hagas una idea.

Otra posibilidad es dejarle que use *toda* la memoria disponible:

vm.overcommit_memory = 2
vm.overcommit_ratio = 100

> @ManoloDiaz
> > Sugiero que investigues el ajuste OOM score, se hace por procesos y
> > creo que systemd lo gestiona sin dificultad. Así podrías establecer
> > una jerarquía para ver cuáles son los últimos en ser aniquilados por
> > el núcleo cuando empieza a faltar memoria.
> 
> Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH
> tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el
> oom-killer no se lo cargará, cosa que me interesa.

No te interesa que se cargue *ningún* proceso.

Esto del OOM killer en realidad es una aberración. Es como si unas
líneas aéreas deciden que cuando un avión está bajo de combustible
se elige un pasajero al azar y le dan al botón de "eject" para
ese pasajero.

Mejor lee el original de Andries Brouwer:

https://lwn.net/Articles/104185/

No pierdas el tiempo haciendo "ajustes" del OOM killer. Es como si te
andaras rompiendo la cabeza afinando el algoritmo por el que se decide
qué pasajero expulsas del avión...

Re: Problemas de dependencia(actualización emacs24 debian testingI

2015-09-27 Por tema Camaleón 
El día 27 de septiembre de 2015, 19:14, Cesar  
escribió:

No sé por qué me llegan tus correos al privado pero no los veo en la 
lista salvo más tarde y deshilados :-?

> Hola.
> Camaleón seguí  tus instrucciones.
>
>>Mejor haz un "apt-get update && apt-get -V dist-upgrade".
>
> Aquí esta lo que muestra la terminal:
>
> http://pastebin.com/4sM54i0T

Caray O_o

Lo que me mosquea es este mensaje, es imposible que emacs24 dependa de un 
paquete antiguo salvo que como digo, lo esté tomando localmente del caché.

***
Los siguientes paquetes tienen dependencias incumplidas:
emacs24 : Depende: emacs24-bin-common (= 24.5+1-1) pero 24.5+1-2 está 
instalado
E: Dependencias incumplidas. Pruebe de nuevo utilizando -f.
***

Creo que antes de nada tendrías que poner en orden tu archivo "/etc/apt/
sources.list" y dejar habilitados sólo los repositorios de Debian 
(desactiva "#" TODO los demás). Cuando hagas este cambio manda a la lista 
el contenido del archivo:

cat /etc/apt/sources.list

Borra el caché de los .deb que tengas ("apt-get clean"), ejecuta de nuevo 
un "apt-get update && apt-get -V dist-upgrade" y manda la salida.

> Lo que no entendí ¿porque no debo de actualizar mi debian testing?; si
> tengo entendido que son mejoras, correciones de errores para su mejor
> funcionamiento.

Debes actualizar testing pero sólo con los paquetes de su rama para 
evitar conflictos.

> En Debian sid hay más errores de dependencias y hacen que el sistema se
> rompa en cualquier momento; se supone que debian testing tiene un poco 
> más de estabilidad que sid.

Testing es una sid con 1 mes de retraso, vamos, que se puede romper de la 
misma manera, aunque es verdad que eso sucede menos.

Saludos,

-- 
Camaleón

Re: Problemas de memoria

2015-09-27 Por tema fernando sainz 
El día 27 de septiembre de 2015, 15:51, Camaleón  escribió:
> El Sun, 27 Sep 2015 13:46:14 +0200, José Miguel (sio2) escribió:
>
>> Para no escribir varios correos contentos a todos aquí:
>>
>> Ya he logrado meterme en el servidor y no he visto ningún programa que
>> parezca consumir ingentes cantidades de memoria. El estado de la memoria
>> cuando logré entrar era este:
>>
>>  total used  freeshared   buffers   cached
>> Mem:   8072224  5397344   2674880223196 93108  3734372
>> -/+ buffers/cache:15698646502360
>> Swap:  209714832572   2064576
>>
>> Parece que hay memoria libre,
>
> (...)
>
> Un apunte sobre el uso de memoria.
>
> Con 8 GiB de RAM física el sistema de no debería tirar de la swap salvo
> en casos MUY puntuales. Mi equipo personal tiene esa misma configuración
> (8 GiB y 2 GiB de swap) y nunca, jamás lo he visto hacer uso de la swap.
> Ni un sólo byte.
>
> Por otro lado, tienes ~3,7 GiB cacheados, lo cual puede ser bueno (si
> esos datos se están usando para agilizar operaciones) o no, porque no
> siempre ese caché contiene información útil, pueden ser datos de un
> proceso que ya ha terminado pero que está reteniendo esa memoria¹ e
> impidiendo que el resto de servicios puedan solicitarla y el kernel no
> pueda asignarla (de ahí que tenga que tirar de la swap). Prueba a vaciar
> el caché.
>

La memoria cache la gestiona el núcleo y cuando se necesita más RAM se
desecha el cache y se usa.
En ningún momento deja de estar disponible.

S2.


> ¹Suele pasarme en un servidor con samba al hacer copia de los datos desde
> los clientes de la red, el sistema se pone en modo "traga-RAM" y cuando
> termina la copia siguen en caché unos 7 GiB. de los 8 GiB de RAM física
> que tiene el servidor.
>
> Saludos,
>
> --
> Camaleón
>

Fwd: Problemas de dependencia(actualización emacs24 debian testing

2015-09-27 Por tema Cesar Peña 
Hola.
Buen día.
Aquí molestándolos con mi problema.
Gracias Noel por tu respuesta y el tip de la página.
Como decía en el correo anterior  tengo debian testing no SId.
El problema radica en la actualización de emacs24.
Ayer hice un apt-get upgrade
Y me salio el siguiente error:
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Tal vez quiera ejecutar «apt-get -f install» para corregirlo.
Los siguientes paquetes tienen dependencias incumplidas:
 emacs24 : Depende: emacs24-bin-common (= 24.5+1-1) pero 24.5+1-2 está
instalado
E: Dependencias incumplidas. Pruebe de nuevo utilizando -f.
Veo que me esta requiriendo emacs24-bin-common (= 24.5+1-1), pero al
parecer tengo instalada una versión más actual.

Entonces intente con el comando apt-get -f install.
Y marco el siguiente error:

http://pastebin.com/QbSSjr7H

No me funciona ninguno de los dos comando apt-get upgrade,
apt-get -f install.

Quise quitar emacs24 desde synaptic pero marca el mismo error.

http://pastebin.com/QbSSjr7H

Gracias por su atención.☺

Saludos.

Re: Problemas de dependencia(actualización emacs24 debian testing

2015-09-27 Por tema Cesar 

Hola.
Camaleón seguí  tus instrucciones.


Mejor haz un "apt-get update && apt-get -V dist-upgrade".


Aquí esta lo que muestra la terminal:

http://pastebin.com/4sM54i0T

Lo que no entendí ¿porque no debo de actualizar mi debian testing?; si tengo 
entendido que son mejoras, correciones de errores para su mejor funcionamiento.
En Debian sid hay más errores de dependencias y hacen que el sistema se rompa 
en cualquier momento; se supone que debian testing tiene un poco más de 
estabilidad que sid.

Saludos!!!

Re: Problemas de memoria

2015-09-27 Por tema sio2 
Para no escribir varios correos contentos a todos aquí:

Ya he logrado meterme en el servidor y no he visto ningún programa que
parezca consumir ingentes cantidades de memoria. El estado de la memoria
cuando logré entrar era este:

 total used  freeshared   buffers   cached
Mem:   8072224  5397344   2674880223196 93108  3734372
-/+ buffers/cache:15698646502360
Swap:  209714832572   2064576

Parece que hay memoria libre, pero si por:

vm.overcommit_memory = 2

no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es
plausible pensar que se llegó a ese límite cuando no podía acceder al
servidor.

En cuanto a las aplicaciones, la que más ocupaba era squid con un 6,8%.
En su fichero de configuración tengo:

cache_mem 512

lo que representa el 6,25% (1/16) de la memoria RAM. Así que el dato
parece coherente.

El siguiente es bind con un 3.5%.  Esto sí me parece bastante, pero
quizás sea debido a que tengo varias vistas y adición dinámica de
nombres, de manera que unas vistas tienen que ser esclavas de otras.

El caso es que he puesto a 0 el parámetro del núcleo y a funcionar un
script que cada 10 minutos me comprueba las estadísticas de memoria y si
se ha producido algún oom. Así tendré un historial del consumo de
memoria y, si vuelve a fallar, más elementos de juicio.

A ver qué pasa.

> Si todos los programas piden más memoria de la que necesitan y le
> dices al núcleo que nunca conceda más memoria de la que tiene
> realmente, estás infrautilizando la memoria que tienes.

Tiene 2GB de swap. Había leído que superar esa cantidad de swap
no era muy recomendable. Aunque claro, a lo mejor es debido a que, si se
da el caso, lo que el sistema está pidiendo urgentemente es una
ampliación de la RAM.

El caso es que en la salida de free, no parece haver mucha SWAP en uso.
Me inclino a pensar que era por el valor de vm.overcommit_memory

Comprobaré el consumo de swap en el historial del script que he puesto a
funcionar.

@ManoloDiaz
> Sugiero que investigues el ajuste OOM score, se hace por procesos y
> creo que systemd lo gestiona sin dificultad. Así podrías establecer
> una jerarquía para ver cuáles son los últimos en ser aniquilados por
> el núcleo cuando empieza a faltar memoria.

Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH
tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el
oom-killer no se lo cargará, cosa que me interesa. Sin embargo, tengo un
servidor con wheezy más o menos como tenía antes configurado este y he
comprobado que ocurre lo mismo. Sin embargo, el año pasado cuando tuve
los problemas de oom, no podía acceder al servidor. Efectivamente sshd
corría, pero tras autenticarme, devolvía un error de
ssh_exchange_identification, creo recordar y me quedaba sin acceso. Así
que ese valor, simplemente, no me ayuda mucho. Supongo que al acceder
por SSH, es necesario abrir subprocesos que dada la situación no pueden
abrirse. No sé si eso tendrá alguna solución.

@Camaleon
> Ojo, que "2719744 bytes" son ~2,5 MiB ;-)
Sí, son MB, no GB... En fin, agradezco que me lo hayas dicho así como
disimulando para que no se entere el resto.

Gracias, de momento, a todos por las sugerencias.

-- 
   En la vida humana sólo unos pocos sueños se cumplen,
la mayoría se roncan.
  --- Enrique Jardiel Poncela ---

Re: (OT) Cámara de vídeo Canon MV900 con cintas MiniDV en Debian Stretch

2015-09-27 Por tema Camaleón 
El Fri, 25 Sep 2015 14:18:40 +, Camaleón escribió:

> El Fri, 25 Sep 2015 14:02:41 +0100, José Manuel (EB8CXW) escribió:

(...)

> Camaleón, gracias por contestar.
>
> Con respecto al enlace que me indicas, soy un neófito del ingles.

Hum... vale, pero el traductor de Google suele hacer un buen trabajo:

https://translate.google.com/translate?sl=en=es=y=_t=es=UTF-8=http%3A%2F%2Fsharpeespace.blogspot.com.es%2F2012%2F06%2Fcapturing-firewire-1394-camcorder.html=

Lo que indican en el artículo es que el nuevo driver del kernel de 
firewire no crea el dispositivo en bruto "raw1394" para poder 
capturar el contenido de los datos de la cámara y que además los 
permisos de "/dev/fw0" no permiten el acceso para todos del 
dispositivo.

Para solucionarlo sugiere:

1/ Crear un enlace al dispositivo antiguo desde el nuevo 
(como root):

ln /dev/fw0 /dev/raw1394

2/ Ejecutar la aplicación de captura (Kino) como súperusaurio (si 
esto funciona habría que ver la forma de configurar los permisos 
correctamente para el dispositivo).

gksu kino

> Realice lo que me indicas:
>
> eb8cxw@debian-PAPA:~$ lsmod | grep -i firewire
> firewire_ohci  45056  0
> firewire_core  57344  1 firewire_ohci
> crc_itu_t  16384  1 firewire_core
> eb8cxw@debian-PAPA:~$

Bien, los módulos del kernel están cargados, quiere decir que se ha 
detectado la controladora. A mí me dice lo mismo:

sm01@stt008:~$ lsmod | grep -i firewire
firewire_ohci  35772  0 
firewire_core  48449  1 firewire_ohci
crc_itu_t  12347  1 firewire_core

> Con Cámara encendida:
> eb8cxw@debian-PAPA:~$ dmesg | grep -i fire
> [0.609224] firewire_ohci :04:00.0: added OHCI v1.10 device as card 0, 
> 4 IR + 8 IT contexts, quirks 0x10
> [1.109654] firewire_core :04:00.0: created device fw0: GUID 
> 001106660009, S400
> eb8cxw@debian-PAPA:~$

Correcto, te ha creado el enlace al puerto en /dev/fw0, igual que a 
mí (en mi caso tengo dos tarjetas, una 400 fw1y otra 800 fw0):

sm01@stt008:~$ dmesg | grep -i fire
[4.757442] firewire_ohci :06:07.0: PCI IRQ 28 -> rerouted to legacy IRQ 
16
[4.812065] firewire_ohci: Added fw-ohci device :06:07.0, OHCI v1.10, 4 
IR + 8 IT contexts, quirks 0x2
[4.868042] firewire_ohci: Added fw-ohci device :11:03.0, OHCI v1.10, 4 
IR + 8 IT contexts, quirks 0x2
[5.312073] firewire_core: created device fw0: GUID 08002856039a, S800
[5.368067] firewire_core: created device fw1: GUID 0030482022ca, S400

> Con cámara apagada:
> eb8cxw@debian-PAPA:~$ dmesg | grep -i fire
> [0.609224] firewire_ohci :04:00.0: added OHCI v1.10 device as card 0, 
> 4 IR + 8 IT contexts, quirks 0x10
> [1.109654] firewire_core :04:00.0: created device fw0: GUID 
> 001106660009, S400
> [ 1677.074982] firewire_core :04:00.0: rediscovered device fw0
> eb8cxw@debian-PAPA:~$

Saludos,

-- 
Camaleón

Re: Problemas de dependencia(actualización emacs24 debian testingI

2015-09-27 Por tema Camaleón 
El 27 de septiembre de 2015, 17:22, Cesar Peña  
escribió:

(reenvío a la lista, me llegó al privado)

> Hola.
> Buen día.
> Aquí molestándolos con mi problema.
> Gracias Noel por tu respuesta y el tip de la página.

No me llamo Noel :-)

> Como decía en el correo anterior  tengo debian testing no SId.

Sí, eso has dicho, que has eliminado Sid porque te daba ese error y ahora 
en testing te pasa lo mismo con lo cual estás en la misma situación.

> El problema radica en la actualización de emacs24.

¿Actualizar? Estás en testing, no tienes que actualizar nada si no 
quieres romper cosas.

> Ayer hice un apt-get upgrade

Mejor haz un "apt-get update && apt-get -V dist-upgrade".

> Y me salio el siguiente error:

Acostúmbrate a enviar el comando que ejecutas *exacto*, tal cual, sin 
cambiar nada, copia/pega de lo ejecutas en una consola.

> Leyendo lista de paquetes... Hecho
> Creando árbol de dependencias  
> Leyendo la información de estado... Hecho
> Tal vez quiera ejecutar «apt-get -f install» para corregirlo.
> Los siguientes paquetes tienen dependencias incumplidas:
>  emacs24 : Depende: emacs24-bin-common (= 24.5+1-1) pero 24.5+1-2 está
> instalado
> E: Dependencias incumplidas. Pruebe de nuevo utilizando -f.

No puede depender de esa versión, seguramente tengas la base de datos 
local de los paquetes sin actualizar.

> Veo que me esta requiriendo emacs24-bin-common (= 24.5+1-1), pero al
> parecer tengo instalada una versión más actual.
>
> Entonces intente con el comando apt-get -f install.
> Y marco el siguiente error:
>
> http://pastebin.com/QbSSjr7H

Madre mía, menudo jaleo crea un único paquete :-O

> No me funciona ninguno de los dos comando apt-get upgrade,
> apt-get -f install.
>
> Quise quitar emacs24 desde synaptic pero marca el mismo error.
>
> http://pastebin.com/QbSSjr7H
>
> Gracias por su atención.
>
> Saludos.

Prueba con el comando que te he puesto antes y manda la salida.

Saludos,

-- 
Camaleón

Re: Re: Problemas de dependencia(actualización emacs24 debian testingI

2015-09-27 Por tema Cesar 

Hola Camaleón.
No se que pasa que yo tampoco veo los mensajes que envío y tardan en 
aparecer.


Acabo de comentar las lineas de mi archivo sources.list, y seguí las 
instrucciones.


http://pastebin.com/snuV1AT0

Saludo

Re: Problemas de memoria

2015-09-27 Por tema Santiago Vila 
On Sun, Sep 27, 2015 at 07:32:26PM +0200, Manolo Díaz wrote:

> No es muy elegante, pero no creo que los desarrolladores de Linux se
> hayan levantado un día aburridos y decidieran programar una aberración.
> Parece que las soluciones obvias al límite de la memoria son (aparte de
> aumentarla) o eliminar procesos, o impedir que se lancen nuevos.
> Y te ofrecen que elijas entre dos soluciones nada elegantes.

La verdad siempre es más elegante que la mentira.

Los procesos piden memoria y el núcleo les dice, "toma, aquí la tienes",
pero en realidad es mentira, si todos los procesos usaran la memoria
que han pedido y en teoría les ha sido concedida resulta que no hay
para todos.

"Ay, no, que te he dado una memoria que en realidad no tengo, ahora
por pretender usar la memoria que te he dado y para enmendar mi error,
vas a morir".

No sé qué harán los desarrolladores de Linux cuando estén aburridos,
pero esto del overcommit, y después de leer todo lo que he podido
sobre el tema, me parece una chapucilla.

Re: Problemas de memoria

2015-09-27 Por tema Manolo Díaz 
El domingo, 27 sep 2015 a las 21:05 UTC
Santiago Vila escribió:

> On Sun, Sep 27, 2015 at 07:32:26PM +0200, Manolo Díaz wrote:
> 
> > No es muy elegante, pero no creo que los desarrolladores de Linux se
> > hayan levantado un día aburridos y decidieran programar una aberración.
> > Parece que las soluciones obvias al límite de la memoria son (aparte de
> > aumentarla) o eliminar procesos, o impedir que se lancen nuevos.
> > Y te ofrecen que elijas entre dos soluciones nada elegantes.
> 
> La verdad siempre es más elegante que la mentira.
> 
> Los procesos piden memoria y el núcleo les dice, "toma, aquí la tienes",
> pero en realidad es mentira, si todos los procesos usaran la memoria
> que han pedido y en teoría les ha sido concedida resulta que no hay
> para todos.
> 
> "Ay, no, que te he dado una memoria que en realidad no tengo, ahora
> por pretender usar la memoria que te he dado y para enmendar mi error,
> vas a morir".
> 
> No sé qué harán los desarrolladores de Linux cuando estén aburridos,
> pero esto del overcommit, y después de leer todo lo que he podido
> sobre el tema, me parece una chapucilla.
> 

Pero es que no hay solución ideal. Al ajustar overcommit respondes una
pregunta sobre una situación límite: qué hago si me quedo sin memoria.
Porque si ponerse a aniquilar procesos para desalojar memoria es un
disparate, lo que le ha sucedido a José Miguel tampoco se queda atrás,
y dejar que las aplicaciones en curso vayan fallando estrepitosamente
no es la alegría de la huerta (¿vm.overcommit_memory = 1?).

-- 
Manolo Díaz

Re: sudo aptitude se bloquea (solucionado)

2015-09-27 Por tema Ricardo Delgado 
El 25/9/15, Manolo Díaz  escribió:
> El viernes, 25 sep 2015 a las 15:38 UTC
> AlexLikeRock escribió:
>
>> 1.-yo miro que estas corriendo como usuario normal y eso esta mal
>>
>> $./actualiza.sh
>> ^^
>> tienes que correrlo como root
>
> El objeto de sudo dentro del script es _precisamente_ evitar la
> necesidad de ejecutarlo como root. De hecho, como señala Adrià, el
> primer aptitude se ejecuta mientras que el segundo no. Y ambos
> necesitan privilegios de administrador.
>
> Yo intentaría [1]:
> sudo { aptitude update && aptitude full-upgrade -y; }
>
> Bueno, no. La verdad es que yo no intentaría 'full-upgrade -y' ni bajo
> los efectos de mi peor resaca. Pero esa es otra historia.
>

gracias por responder, solucione agregando sudo aptitude update &&
sudo aptitude full-upgrade -y

y eso que no tengo resaca

vamos que lo utilizo hace tiempo y hasta hoy no me dio problemas mas
alla de alguna dependencia incumplida en alguna ocasion. Pero para eso
es testing. antes utilizaba apt-get pero despues de haber leido (no
recuerdo si en esta lista) que era mas practico y que justamente
"resolvia" mejor problemas de dependencia es que decante por aptitude.

Saludos.


-- 
"Windows? Reboot
Debian?  beRoot "

Re: Problemas de memoria

2015-09-27 Por tema Camaleón 
El Sun, 27 Sep 2015 13:46:14 +0200, José Miguel (sio2) escribió:

> Para no escribir varios correos contentos a todos aquí:
> 
> Ya he logrado meterme en el servidor y no he visto ningún programa que
> parezca consumir ingentes cantidades de memoria. El estado de la memoria
> cuando logré entrar era este:
> 
>  total used  freeshared   buffers   cached
> Mem:   8072224  5397344   2674880223196 93108  3734372 
> -/+ buffers/cache:15698646502360 
> Swap:  209714832572   2064576
> 
> Parece que hay memoria libre, 

(...)

Un apunte sobre el uso de memoria. 

Con 8 GiB de RAM física el sistema de no debería tirar de la swap salvo 
en casos MUY puntuales. Mi equipo personal tiene esa misma configuración 
(8 GiB y 2 GiB de swap) y nunca, jamás lo he visto hacer uso de la swap. 
Ni un sólo byte.

Por otro lado, tienes ~3,7 GiB cacheados, lo cual puede ser bueno (si 
esos datos se están usando para agilizar operaciones) o no, porque no 
siempre ese caché contiene información útil, pueden ser datos de un 
proceso que ya ha terminado pero que está reteniendo esa memoria¹ e 
impidiendo que el resto de servicios puedan solicitarla y el kernel no 
pueda asignarla (de ahí que tenga que tirar de la swap). Prueba a vaciar 
el caché.

¹Suele pasarme en un servidor con samba al hacer copia de los datos desde 
los clientes de la red, el sistema se pone en modo "traga-RAM" y cuando 
termina la copia siguen en caché unos 7 GiB. de los 8 GiB de RAM física 
que tiene el servidor.

Saludos,

-- 
Camaleón

Re: Problemas de dependencia(actualización emacs24 debian testingI

2015-09-27 Por tema Manolo Díaz 
El domingo, 27 sep 2015 a las 17:46 UTC
Camaleón escribió:

> > En Debian sid hay más errores de dependencias y hacen que el sistema se
> > rompa en cualquier momento; se supone que debian testing tiene un poco 
> > más de estabilidad que sid.  
> 
> Testing es una sid con 1 mes de retraso, vamos, que se puede romper de la 
> misma manera, aunque es verdad que eso sucede menos.

No. En testing no debe haber problemas de dependencia. Las veces que
ocurre son contadas y se considera fuera de lo normal, al contrario que
en unstable.

https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-testing
-- 
Manolo Díaz

Re: Problemas de memoria

2015-09-27 Por tema Santiago Vila 
On Sat, Sep 26, 2015 at 09:56:58AM +0200, José Miguel (sio2) wrote:
> $ ssh yo@mlejanoservidor
> [...]
> Last login: Thu Sep 24 23:56:00 2015 from X.Y.Z.T
> -bash: fork: No se pudo asignar memoria   
>   
> -bash: xmalloc: no se pueden asignar 4112 bytes (2719744 bytes asignados) 
>   
> Connection to milejanoservidor closed.
>
> [...]
>
> La pregunta es, ¿qué me aconsejáis?

Ya que nadie te lo ha dicho, te lo digo yo: Pon más swap.

Si todos los programas piden más memoria de la que necesitan y le
dices al núcleo que nunca conceda más memoria de la que tiene
realmente, estás infrautilizando la memoria que tienes.