Re: Desconexiones del USB con el kernel 4.2
El día 16 de noviembre de 2015, 18:32, Camaleón escribió: > El Mon, 16 Nov 2015 17:58:45 +0100, Josu Lazkano escribió: > >> Hace poco que actualice el kernel de mi servidor al de los backports de >> Jessie: >> >> # uname -a Linux mitxelena 4.2.0-0.bpo.1-amd64 #1 SMP Debian >> 4.2.5-1~bpo8+1 (2015-11-02) x86_64 GNU/Linux >> >> El problema que tengo es que el USB del SAI se me desconecta >> constantemente: >> >> # tail -n 20 /var/log/syslog >> Nov 16 17:52:21 servidor kernel: [378450.893207] usb 4-5: new low-speed USB >> device number 119 using ohci-pci >> Nov 16 17:52:21 servidor kernel: [378451.062333] usb 4-5: New USB device >> found, idVendor=0665, idProduct=5161 >> Nov 16 17:52:21 servidor kernel: [378451.062345] usb 4-5: New USB device >> strings: Mfr=1, Product=2, SerialNumber=0 >> Nov 16 17:52:21 servidor kernel: [378451.062352] usb 4-5: Product: USB to >> Serial >> Nov 16 17:52:21 servidor kernel: [378451.062358] usb 4-5: Manufacturer: INNO >> TECH >> Nov 16 17:52:21 servidor kernel: [378451.077138] hid-generic >> 0003:0665:5161.82E4: hiddev0,hidraw0: USB HID v1.00 Device [INNO TECH USB to >> Serial] on usb-:00:12.0-5/input0 >> Nov 16 17:52:31 servidor kernel: [378460.445921] usb 4-5: USB disconnect, >> device number 119 > > (...) > >> Antes de la actualizacion no me pasa, ¿que puede ser? >> >> La verdad que es un poco raro, hasta ahora a funciona bien. > > ¿Estás usando algún programa de monitorización para el SAI (NUT)? Si es > así, comprueba que hayas iniciado el servicio y los drivers asociados > a tu unidad correctamente. > > También podrías probar a conectar el SAI en otro puerto USB o usar un > cable distinto (que sea para el SAI, eso sí, ya que dependiendo del > fabricante suelen usar una configuración de los pines distinta de los > cable USB estándar). > > Saludos, > > -- > Camaleón > Gracias, he probado a cambiar el cable y poner en el mismo puerto, pero nada. Puede que este afectado por este bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805168 Saludos. -- Josu Lazkano
Re: [OT] Evitar deadlock en mysql
El día 18 de noviembre de 2015, 17:29, Camaleón escribió: > El Wed, 18 Nov 2015 17:07:35 +0100, Maykel Franco escribió: > >> Buenas, he estado revisando las estadísticas de innodb de alguno de >> nuestros servidores y me he encontrado con deadlocks en uno de ellos... >> >> ATEST DETECTED DEADLOCK >> 2015-11-06 16:00:00 7f61c5aa5700 *** (1) TRANSACTION: >> TRANSACTION 1422060913, ACTIVE 0 sec inserting mysql tables in use 1, >> locked 1 LOCK WAIT 9 lock struct(s), heap size 1184, 5 row lock(s), undo >> log entries 3 MySQL thread id 6495594, OS thread handle 0x7f61c526a700, >> query id 110695361 10.100.107.6 stats update INSERT INTO `test`.`test` >> (`test`,`test`,`test`,`test`,`test`,`test`) >> VALUES (2015,11,6,16,'iOS',1) >> *** (1) WAITING FOR THIS LOCK TO BE GRANTED: >> RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of >> table `test`.`test` trx id 1422060913 lock_mode X insert intention >> waiting *** > > (...) > >> test son los datos de mi bbdd. >> >> Mi pregunta es, de la parte de sistemas hay alguna forma de poder >> evitarlo? Creo que la solución pasa por arreglarlo prográmaticamente, >> si detecta el error del deadlock, reintentarlo otra vez. >> >> Deadlock se produce cuando una transaccion espera por los recursos >> utilizados por otra transacción que a su vez espera por los recursos de >> otra. >> >> Consejos? > > Pregunta a Google :-) > > How to debug InnoDB lock waits > http://www.xaprb.com/blog/2007/09/18/how-to-debug-innodb-lock-waits/ Lo estoy monitorizando con pt-deadlock-logger, guardo los deadlock en bbdd, también se pueden guardar en log. Necesito primero saber por qué es para poder solucionarlo. > > How to deal with MySQL deadlocks > https://www.percona.com/blog/2014/10/28/how-to-deal-with-mysql-deadlocks/ Este enlace lo había visto, se puede controlar programáticamente. > > Saludos, > > -- > Camaleón >
Re: [OT] Evitar deadlock en mysql
El día 18 de noviembre de 2015, 17:19, TheFox escribió: > Parece ser que el error te lo da en la tabla «test», que al parecer está > inactiva; razón por la cual no te deja actualizar los datos. Lo que debes de > hacer es averiguar por qué esa tabla está inactiva. Ok, gracias. > > Santiago. > > El 18/11/2015 17:07, "Maykel Franco" escribió: >> >> Buenas, he estado revisando las estadísticas de innodb de alguno de >> nuestros servidores y me he encontrado con deadlocks en uno de >> ellos... >> >> ATEST DETECTED DEADLOCK >> >> 2015-11-06 16:00:00 7f61c5aa5700 >> *** (1) TRANSACTION: >> TRANSACTION 1422060913, ACTIVE 0 sec inserting >> mysql tables in use 1, locked 1 >> LOCK WAIT 9 lock struct(s), heap size 1184, 5 row lock(s), undo log >> entries 3 >> MySQL thread id 6495594, OS thread handle 0x7f61c526a700, query id >> 110695361 10.100.107.6 stats update >> INSERT INTO `test`.`test` (`test`,`test`,`test`,`test`,`test`,`test`) >> VALUES (2015,11,6,16,'iOS',1) >> *** (1) WAITING FOR THIS LOCK TO BE GRANTED: >> RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of >> table `test`.`test` trx id 1422060913 lock_mode X insert intention >> waiting >> *** (2) TRANSACTION: >> TRANSACTION 1422060914, ACTIVE 0 sec inserting >> mysql tables in use 1, locked 1 >> 9 lock struct(s), heap size 1184, 5 row lock(s), undo log entries 3 >> MySQL thread id 6495593, OS thread handle 0x7f61c5aa5700, query id >> 110695362 10.100.107.6 stats update >> INSERT INTO `test`.`test` (``,`test`,`test`,`test`,`test`,`test`) >> VALUES (2015,11,6,16,'Android',1) >> *** (2) HOLDS THE LOCK(S): >> RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of >> table `test`.`test` trx id 1422060914 lock_mode X >> *** (2) WAITING FOR THIS LOCK TO BE GRANTED: >> RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of >> table `test`.`test` trx id 1422060914 lock_mode X insert intention >> waiting >> *** WE ROLL BACK TRANSACTION (2) >> >> >> test son los datos de mi bbdd. >> >> Mi pregunta es, de la parte de sistemas hay alguna forma de poder >> evitarlo? Creo que la solución pasa por arreglarlo prográmaticamente, >> si detecta el error del deadlock, reintentarlo otra vez. >> >> Deadlock se produce cuando una transaccion espera por los recursos >> utilizados por otra transacción que a su vez espera por los recursos >> de otra. >> >> Consejos? >> >
Re: Modificando variables de php.ini desde VirtualHost
El Wed, 18 Nov 2015 17:37:25 +0100, Alfonso escribió: > Saludos: Corrijo el top-posting. > El 16/11/15 a las 15:35, Camaleón escribió: (...) >>> fastcgi_param PHP_ADMIN_VALUE >>> open_basedir=/home/ftp/user1/httpdocs/:/tmp/ >>> >>> Existe alguna forma de hacer esto mismo en Apache? O preguntado de una >>> manera más amplia, es posible reescribir variables de un PHP CGI desde >>> un Vhost en Apache? >>> >>> Agradezco cualquier orientación. >> >> Pues ni idea :-? pero echa un ojo a esta documentación: >> >> https://wiki.apache.org/httpd/SecuringPHP > Esa docuentación hace uso de los parámetros de PHP para sobreescribir > las variables de php.ini desde el VirtualHost, lo cual solo sirve para > un PHP como módulo de Apache. > > Para PHP's que se invocan mediante CGI (fastCGI) esto no sirve, de hecho > ni tan solo funcionan los .htaccess a no ser que se compile la extensión > htscanner (para mi no es una buena opción definir estas variables PHP en > el .htaccess). > > Lo único que he podido hacer es añadir scripts CGI para cada VirtualHost > de tal manera que cada VirtualHost tenga su propio php.ini. Aummm... pues entonces habrá que preguntar al revés a Google, a ver si esto te da alguna idea: Nginx variables similar to SetEnv in Apache? http://stackoverflow.com/questions/8098927/nginx-variables-similar-to-setenv-in-apache Saludos, -- Camaleón
Re: Modificando variables de php.ini desde VirtualHost
Saludos: Esa docuentación hace uso de los parámetros de PHP para sobreescribir las variables de php.ini desde el VirtualHost, lo cual solo sirve para un PHP como módulo de Apache. Para PHP's que se invocan mediante CGI (fastCGI) esto no sirve, de hecho ni tan solo funcionan los .htaccess a no ser que se compile la extensión htscanner (para mi no es una buena opción definir estas variables PHP en el .htaccess). Lo único que he podido hacer es añadir scripts CGI para cada VirtualHost de tal manera que cada VirtualHost tenga su propio php.ini. El 16/11/15 a las 15:35, Camaleón escribió: > El Sun, 15 Nov 2015 23:53:08 +0100, Alfonso escribió: > > (...) > >> He visto que para Nginx se pueden aplicar estos cambios con >> 'fastcgi_param': >> >> fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/ftp/user1/httpdocs/:/tmp/ >> >> Existe alguna forma de hacer esto mismo en Apache? O preguntado de una >> manera más amplia, es posible reescribir variables de un PHP CGI desde >> un Vhost en Apache? >> >> Agradezco cualquier orientación. > > Pues ni idea :-? pero echa un ojo a esta documentación: > > https://wiki.apache.org/httpd/SecuringPHP > > Saludos, > -- Alfonso signature.asc Description: OpenPGP digital signature
Re: [OT] Evitar deadlock en mysql
El Wed, 18 Nov 2015 17:07:35 +0100, Maykel Franco escribió: > Buenas, he estado revisando las estadísticas de innodb de alguno de > nuestros servidores y me he encontrado con deadlocks en uno de ellos... > > ATEST DETECTED DEADLOCK > 2015-11-06 16:00:00 7f61c5aa5700 *** (1) TRANSACTION: > TRANSACTION 1422060913, ACTIVE 0 sec inserting mysql tables in use 1, > locked 1 LOCK WAIT 9 lock struct(s), heap size 1184, 5 row lock(s), undo > log entries 3 MySQL thread id 6495594, OS thread handle 0x7f61c526a700, > query id 110695361 10.100.107.6 stats update INSERT INTO `test`.`test` > (`test`,`test`,`test`,`test`,`test`,`test`) > VALUES (2015,11,6,16,'iOS',1) > *** (1) WAITING FOR THIS LOCK TO BE GRANTED: > RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of > table `test`.`test` trx id 1422060913 lock_mode X insert intention > waiting *** (...) > test son los datos de mi bbdd. > > Mi pregunta es, de la parte de sistemas hay alguna forma de poder > evitarlo? Creo que la solución pasa por arreglarlo prográmaticamente, > si detecta el error del deadlock, reintentarlo otra vez. > > Deadlock se produce cuando una transaccion espera por los recursos > utilizados por otra transacción que a su vez espera por los recursos de > otra. > > Consejos? Pregunta a Google :-) How to debug InnoDB lock waits http://www.xaprb.com/blog/2007/09/18/how-to-debug-innodb-lock-waits/ How to deal with MySQL deadlocks https://www.percona.com/blog/2014/10/28/how-to-deal-with-mysql-deadlocks/ Saludos, -- Camaleón
Re: [OT] Evitar deadlock en mysql
Parece ser que el error te lo da en la tabla «test», que al parecer está inactiva; razón por la cual no te deja actualizar los datos. Lo que debes de hacer es averiguar por qué esa tabla está inactiva. Santiago. El 18/11/2015 17:07, "Maykel Franco" escribió: > Buenas, he estado revisando las estadísticas de innodb de alguno de > nuestros servidores y me he encontrado con deadlocks en uno de > ellos... > > ATEST DETECTED DEADLOCK > > 2015-11-06 16:00:00 7f61c5aa5700 > *** (1) TRANSACTION: > TRANSACTION 1422060913, ACTIVE 0 sec inserting > mysql tables in use 1, locked 1 > LOCK WAIT 9 lock struct(s), heap size 1184, 5 row lock(s), undo log > entries 3 > MySQL thread id 6495594, OS thread handle 0x7f61c526a700, query id > 110695361 10.100.107.6 stats update > INSERT INTO `test`.`test` (`test`,`test`,`test`,`test`,`test`,`test`) > VALUES (2015,11,6,16,'iOS',1) > *** (1) WAITING FOR THIS LOCK TO BE GRANTED: > RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of > table `test`.`test` trx id 1422060913 lock_mode X insert intention > waiting > *** (2) TRANSACTION: > TRANSACTION 1422060914, ACTIVE 0 sec inserting > mysql tables in use 1, locked 1 > 9 lock struct(s), heap size 1184, 5 row lock(s), undo log entries 3 > MySQL thread id 6495593, OS thread handle 0x7f61c5aa5700, query id > 110695362 10.100.107.6 stats update > INSERT INTO `test`.`test` (``,`test`,`test`,`test`,`test`,`test`) > VALUES (2015,11,6,16,'Android',1) > *** (2) HOLDS THE LOCK(S): > RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of > table `test`.`test` trx id 1422060914 lock_mode X > *** (2) WAITING FOR THIS LOCK TO BE GRANTED: > RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of > table `test`.`test` trx id 1422060914 lock_mode X insert intention > waiting > *** WE ROLL BACK TRANSACTION (2) > > > test son los datos de mi bbdd. > > Mi pregunta es, de la parte de sistemas hay alguna forma de poder > evitarlo? Creo que la solución pasa por arreglarlo prográmaticamente, > si detecta el error del deadlock, reintentarlo otra vez. > > Deadlock se produce cuando una transaccion espera por los recursos > utilizados por otra transacción que a su vez espera por los recursos > de otra. > > Consejos? > >
[OT] Evitar deadlock en mysql
Buenas, he estado revisando las estadísticas de innodb de alguno de nuestros servidores y me he encontrado con deadlocks en uno de ellos... ATEST DETECTED DEADLOCK 2015-11-06 16:00:00 7f61c5aa5700 *** (1) TRANSACTION: TRANSACTION 1422060913, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 9 lock struct(s), heap size 1184, 5 row lock(s), undo log entries 3 MySQL thread id 6495594, OS thread handle 0x7f61c526a700, query id 110695361 10.100.107.6 stats update INSERT INTO `test`.`test` (`test`,`test`,`test`,`test`,`test`,`test`) VALUES (2015,11,6,16,'iOS',1) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of table `test`.`test` trx id 1422060913 lock_mode X insert intention waiting *** (2) TRANSACTION: TRANSACTION 1422060914, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 9 lock struct(s), heap size 1184, 5 row lock(s), undo log entries 3 MySQL thread id 6495593, OS thread handle 0x7f61c5aa5700, query id 110695362 10.100.107.6 stats update INSERT INTO `test`.`test` (``,`test`,`test`,`test`,`test`,`test`) VALUES (2015,11,6,16,'Android',1) *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of table `test`.`test` trx id 1422060914 lock_mode X *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 17528 page no 219 n bits 368 index `PRIMARY` of table `test`.`test` trx id 1422060914 lock_mode X insert intention waiting *** WE ROLL BACK TRANSACTION (2) test son los datos de mi bbdd. Mi pregunta es, de la parte de sistemas hay alguna forma de poder evitarlo? Creo que la solución pasa por arreglarlo prográmaticamente, si detecta el error del deadlock, reintentarlo otra vez. Deadlock se produce cuando una transaccion espera por los recursos utilizados por otra transacción que a su vez espera por los recursos de otra. Consejos?
