[Opengnsys-users] Errores con ctorrent al acabar la descarga
Antonio J. Doblas Viso
adv en uma.es
Mie Jul 14 22:56:50 CEST 2021
¡Hola a todos!
Cuanta información relevante del torrent y cuando "Sánchez" hay por
aquí :-) Pep, me alegro mucho leerte.
Creo que en la última videoconferencia del grupo de desarrollo se comentó
que el paquete del bittornado para la ubuntu 20.04 no estaba disponible,
trataremos de cambiar de semillero en el servidor por el ctorrent. Además,
se intentaría que las imágenes se compartieran a demanda, ya que hay muchos
usuarios no usan torrent. Es bueno conocer la eficiencia de ctorrent
frente al bittornado y parece que es una buena alternativa. Además de los
datos que nos aporta Pep, en la UPC de Terrassa, Andrés Arco también está
con ctorrent en el servidor.
Pep, probaremos en un repositorio dedicado a parar el bittornado y usar el
ctorrent, porque desde que se actulizó este servidor, algunas descargas
fallaban. Ahora, gracias a vuestras explicaciones, caso resuelto.
Miguel, si nos das las instrucciones de descarga e instalación del ctorrent
con el parche, lo probamos para sustituir el actual en el ogLive.
Actualmente se instala el ofrecido por la distro ubuntu.
-
https://github.com/opengnsys/ogLive-Builder/blob/master/includes/usr/bin/boot-tools/listpackages/sw.networking
Pep, creo que debemos abrir un hilo con el tema de la alineación de las
particiones en discos SSD. Aquí un compañero me ha comentado que en las
versiones antiguas de OpenGnsys era necesario verificarlo, pero que en las
nuevas versiones del ogLive el particionado ya alinea correctamente las
particiones ¿Te las alinea correctamente con tu 1.2.0?
Saludos.
El lun, 12 jul 2021 a las 14:37, Miguel Sánchez Sánchez (<msanchez en fi.upm.es>)
escribió:
> Gracias, Pep. Más sencillo todavía que mi script y vale para todo pues
> para cada aula sólo servirás el pequeño número de imágenes que se utilicen
> en ella.
>
> Saludos.
>
> Pep Ciuraneta Sanchez escribió el 12/7/21 a las 14:20:
>
> Para lanzar el ctorrent como seeder hemos hecho un procedimiento que se
> compone de un único shell script, ahora modificado gracias a ti, muy
> similar al contenido del rc.local:
>
>
> Código script:
>
> * #!/bin/bash cd /opt/opengnsys/cache/opt/opengnsys/images/ for i in
> `/bin/ls /opt/opengnsys/cache/opt/opengnsys/images/*.torrent`; do
> /usr/bin/ctorrent -e -1 -f -d $i; done exit 0 *
> <https://147.83.79.251/opengnsys/varios/informacion_acciones.php?idtipoaccion=68&descripcionaccion=ACTIVAR%20TORRENT&tipoaccion=33#nodo>
>
> de manera que cuando necesito tener mas seeders los puedo ir añadiendo
> encendiendo equipos en modo OGClient y ejecutándoles el procedimiento. Así,
> como ejemplo de despliegue de una imagen nueva lo que podemos hacer es
> hacer el deploy en un aula pequeña pero rápida y una vez han acabado,
> ejecutar el procedimiento en ese ámbito, incrementando el número de seeders
> de forma sencilla para seguir haciendo el deploy en el resto de aulas.
>
> Sobre el segundo punto, tomo nota por si se nos reproduciera mucho el
> error para parchear el ctorrent. De momento desde el cambio del bittornado
> por el ctorrent creo que solo nos han petado 3 descargas de un total de
> varios centenares por lo que no nos preocupa en absoluto. Una cosa que creo
> que seria bastante positiva si no fuera costosa seria incorporar ese
> ctorrent parcheado a los OGLive del proyecto.
>
> Saludos y gracias,
> Pep.
>
> --
> O O O Universitat Politecnica de Catalunya
> O O O BarcelonaTECH
> O O O ------------------------------------
> U P C Facultat de Matematiques i Estadistica
> Pau Gargallo, 14 - 08028 Barcelona
>
> Pep Ciuraneta Sanchez
> Serveis TIC
> josep.ciuraneta en upc.edu
> Tel. 934015853
>
> AVIS DE CONFIDENCIALITAT:
> Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>
> Abans d'imprimir aquest correu, penseu si es necessari.
>
>
>
> Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es> del dia dl., 12
> de jul. 2021 a les 12:39:
>
>> Hola Pep. Comento entre líneas.
>>
>> Pep Ciuraneta Sanchez escribió el 12/7/21 a las 12:18:
>>
>> Hola Miguel,
>>
>> Gracias por indicarme la opcion -f del ctorrent. Lo acabo de añadir en
>> todos los scripts. :)
>>
>> No entiendo lo que comentas sobre el asistente de deploy de imagenes. Yo
>> lo he estado usando en las pruebas y funciona perfecto. Quiza no estamos
>> hablando de lo mismo.
>>
>> Me refería a lanzar el semillero desde un ogLive. Aunque ahora mismo
>> tampoco estoy seguro de que el engine de las librerías del ogLive no
>> detecte la imagen en caché adecuadamente y no tenga que volver a
>> descargarse la imagen en concreto cuando lanzas los semilleros desde el
>> asistente.
>>
>>
>> Sobre los errores del ctorrent por entrar en modo EndGame no nos ha
>> pasado en multiples pruebas de descarga. Unicamente se me han producido
>> algun error, minimo, al inicio de la descarga, que supongo debe ser el otro
>> que comentas, con parche existente.
>>
>> Sí, me refería a ese error inicial. Yo incorporé el parche y en las
>> pruebas no volvió a surgir el error de segmentation fault. En nuestro caso,
>> tampoco era desdeñable el porcentaje de equipos que fallaban con ese error.
>> Pero dependía mucho de la situación de inició de la descarga. Me explico,
>> el semillero de Bittornado o Bittorrent se conecta al tracker por defecto
>> cada 5 minutos (parámetro rerequest_interval) para anunciarse y volver a
>> aparecer en él. Si los clientes esperan varios minutos porque el semillero
>> no aparece en el tracker, inician la descarga al unísono cuando llega a
>> aparece y ante la llamada al modo endgame (o initial, no sé) inicial, un
>> porcentaje de ellos (hasta cerca de la mitad en algún caso) falla. Se puede
>> reducir la incidencia bajando el intervalo del parámetro.
>> En tu caso, que utilizas como semillero a ctorrent, supongo que no es tan
>> común.
>>
>>
>> Gracias de nuevo y si quieres que probemos algo solo tienes que decirlo.
>>
>> Igualmente, Pep.
>>
>>
>> Saludos,
>> Pep.
>>
>> --
>> O O O Universitat Politecnica de Catalunya
>> O O O BarcelonaTECH
>> O O O ------------------------------------
>> U P C Facultat de Matematiques i Estadistica
>> Pau Gargallo, 14 - 08028 Barcelona
>>
>> Pep Ciuraneta Sanchez
>> Serveis TIC
>> josep.ciuraneta en upc.edu
>> Tel. 934015853
>>
>> AVIS DE CONFIDENCIALITAT:
>> Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>>
>> Abans d'imprimir aquest correu, penseu si es necessari.
>>
>>
>>
>> Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es> del dia dl., 12
>> de jul. 2021 a les 10:26:
>>
>>> Hola Pep. Sí, la verdad es que los problemas de segmentation fault nos
>>> empezaron a surgir ya en la versión 1.0.6 y entonces optamos por la
>>> solución que tú comentas. Por cierto, la función ogTorrentStart lanza
>>> ctorrent con la opción -f. Creía que era para evitar el chequeo inicial de
>>> la imagen.
>>> La verdad es que optimiza el uso de la red al máximo, pero tiene la pega
>>> de no poder utilizar el asistente de deploy de imágenes.
>>> Aunque el despliegue de semilleros que utilizamos en su día era
>>> sencillo, utilizando algunos ogLIve como la imagen ya en la caché:
>>> IMG=<fichero de imagen>
>>> IMGDIR=$(ogGetParentPath CACHE /$IMG)
>>> ogCopyFile REPO $IMG.torrent $IMGDIR
>>> ogTorrentStart CACHE $IMG.torrent seeder:<tiempo en segundos>
>>>
>>> En cuanto a los problemas de segmentation fault y abortos de ctorrent,
>>> después de ponerlo en debug, he podido ver que en ambos casos están
>>> relacionados con la entrada en el modo EndGame de BitTorrent. Ese modo se
>>> utiliza sobre todo al finalizar las descargas, preguntando a todos los
>>> peers por las partes que le faltan a un cliente, y cancelando las
>>> respuestas a peticiones repetidas. Lamentablemente, ctorrent no gestiona
>>> bien esas cancelaciones y termina cometiendo errores como la creación de
>>> arrays de longitud negativa.
>>> Para el problema del segmentation fault, que se da al poco de comenzar
>>> las sesiones de descarga, creo que tienen un sencillo parche en
>>> https://sourceforge.net/p/dtorrent/patches/6/ que lo solventa.
>>> Pero solucionar el bug del error final std::bad_array_new_length creo
>>> que me supera, por lo que he optado por el camino de en medio, evitando que
>>> ctorrent entre en modo endgame. Tiene el inconveniente de que la
>>> localización de las partes finales de una descarga tardan algo más.
>>> Lo curioso de este último error es que sólo se da, como comentaba, si
>>> los clientes llegan parejos al final en las partes descargadas. Este sólo
>>> es el caso cuando la velocidad para servir disco del semillero es menor que
>>> la velocidad de la red, de tal manera que los clientes terminan
>>> convergiendo entre ellos aunque arranquen después de un tiempo aleatorio
>>>
>>> Tras regenerar el paquete deb de ctorrent luego sólo hay que instalarlo
>>> en el sistema de ficheros squashfs de ogclient.sqfs, para que luego lo
>>> cargue el ogLive.
>>>
>>> Bueno, al final creo me ha salido también otro ladrillo.
>>> Saludos.
>>>
>>> Pep Ciuraneta Sanchez escribió el 9/7/21 a las 18:21:
>>>
>>> Hola Miguel,
>>>
>>> Te explico, nosotros empezamos haciendo pruebas con 1.2.0 para ver si
>>> solucionabamos unos problemas con el torrent (no aprovechamiento del ancho
>>> de banda, falta de fiabilidad con muchos errores segmentation fault en
>>> clientes) y al ver que con 1.2.0 nos pasaba lo mismo hemos cambiado el
>>> programa que se encarga de hacer el seed. Seguimos con 1.1.0 de momento.
>>> Esto lo hemos hecho tras hacer pruebas esta misma semana.
>>>
>>> En lugar de usar el bittornado hemos optado por lanzar un ctorrent por
>>> cada fichero torrent. Esto tiene su inconveniente, pero desde entonces el
>>> ancho de banda se aprovecha algo mejor y los errores se han minimizado
>>> muchísimo. De momento lo vamos a dejar así. En concreto lo lanzamos así
>>> para cada fichero (simplificado)
>>>
>>> # cd /opt/opengnsys/images
>>> # ctorrent -e -1 -d nombre_fichero_img.torrent
>>>
>>> Yo creo que esto es extrapolable a la versión 1.2.0. El hecho de usar
>>> ctorrent en lugar de bittornado funciona bastante mejor, pero tiene la pega
>>> que cada vez que se inicia se comprueba el fichero a compartir y eso puede
>>> ser costoso en tiempo y depende de la velocidad acceso de disco.
>>>
>>> Hemos aprovechado este final de curso para hacer multiples pruebas y el
>>> poder aprovechar la red a 1Gbps da bastante alegria.
>>>
>>> Consejos para subir la velocidad en descarga por torrent:
>>>
>>> 1.- si es posible, tener los ficheros imagen en disco SSD
>>> 2.- tener algun seeder extra. No hace falta que sea un REPO, simplemente
>>> una máquina de backup donde tener los ficheros imagen y los torrent.
>>> 3.- si los equipos destino tienen disco SSD comprobar que las
>>> particiones esten alineadas. Esto es muy importante.
>>> 4.- Realizar un procedimiento para hacer que las aulas o equipos que
>>> tengan la imagen puedan hacer de seeders. Basicamente es lanzar un ctorrent
>>> y esperar al chequeo de cada imagen, pero esto ayuda mucho a subir la
>>> velocidad de descarga. Esto equivale a multiplicar el consejo 2 por el
>>> numero de máquinas en las que se ejecute el procedimiento. Por ejemplo, se
>>> puede descargar primero en el aula donde sea más rapido el despliegue y
>>> luego añadir sus equipos como seeders para acelerar al resto.
>>> 5.- Tener REPOS repartidos por diferentes tramos de la red. Esto depende
>>> de la infraestructura de cada uno.
>>>
>>> Miguel, Perdona el ladrillo, al final me ha salido algo largo. En
>>> resumen, prueba de cambiar el bittornado por un script que te lance los
>>> ctorrent (en el mismo rc.local) y a ver que tal.
>>>
>>> Saludos,
>>> Pep.
>>>
>>> --
>>> O O O Universitat Politecnica de Catalunya
>>> O O O BarcelonaTECH
>>> O O O ------------------------------------
>>> U P C Facultat de Matematiques i Estadistica
>>> Pau Gargallo, 14 - 08028 Barcelona
>>>
>>> Pep Ciuraneta Sanchez
>>> Serveis TIC
>>> josep.ciuraneta en upc.edu
>>> Tel. 934015853
>>>
>>> AVIS DE CONFIDENCIALITAT:
>>> Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
>>>
>>> Abans d'imprimir aquest correu, penseu si es necessari.
>>>
>>>
>>>
>>> Missatge de Miguel Sánchez Sánchez <msanchez en fi.upm.es> del dia dv., 9
>>> de jul. 2021 a les 12:39:
>>>
>>>> Buenas. Me estoy encontrando con que un porcentaje de ogLive, cuando
>>>> van
>>>> a acabar la descarga de una imagen, ctorrent aborta con error
>>>> std::bad_array_new_length.
>>>> Todos los clientes torrent van más o menos igual en la descarga, pues
>>>> acaban bien o fallan al alimón, pues el semillero en el servidor parece
>>>> que no supera los 50Mbit por conexión, y aunque empiezan la descarga
>>>> aleatoriamente van convergiendo. Abortan con un número pequeño de
>>>> partes
>>>> por completar, menos de 20.
>>>>
>>>> No estoy seguro si está relacionado con algún parámetro del semillero
>>>> en
>>>> el servidor, pues hasta ahora nuestro servidor de OpenGnsys estaba un
>>>> poco escaso de recursos y el problema parece que desaparecía cuando se
>>>> limitaban en el semillero el número de peers que se podían conectar.
>>>> Pero hemos cambiado a versión 1.2.0 en un nuevo servidor y el problema
>>>> persiste.
>>>> El semillero que estamos utilizando actualmente es
>>>> btlaunchmany.bittorrent, por aquello de que utiliza un thread por
>>>> imagen
>>>> servida. Pero creo recordar que con btlaunchmany.bittornado los errores
>>>> también se producían.
>>>>
>>>> ¿Os habéis encontrado alguno con este problema? ¿Cómo lo habéis
>>>> solventado?
>>>>
>>>> Saludos.
>>>> _______________________________________________
>>>> Opengnsys-users mailing list
>>>> Opengnsys-users en listas.unizar.es
>>>> https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>>> ----------
>>>> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>>>
>>>> Ud. recibe este correo por pertenecer a una lista de correo gestionada
>>>> por la Universidad de Zaragoza.
>>>> Puede encontrar toda la información sobre como tratamos sus datos en el
>>>> siguiente enlace:
>>>> https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>>> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de
>>>> baja desde la propia aplicación en el momento en que lo desee.
>>>> http://listas.unizar.es
>>>> ----------
>>>>
>>>
>>> _______________________________________________
>>> Opengnsys-users mailing listOpengnsys-users en listas.unizar.eshttps://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>> ----------
>>> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>>
>>> Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
>>> Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace: https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.http://listas.unizar.es
>>> ----------
>>>
>>>
>>> _______________________________________________
>>> Opengnsys-users mailing list
>>> Opengnsys-users en listas.unizar.es
>>> https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>>> ----------
>>> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>>
>>> Ud. recibe este correo por pertenecer a una lista de correo gestionada
>>> por la Universidad de Zaragoza.
>>> Puede encontrar toda la información sobre como tratamos sus datos en el
>>> siguiente enlace:
>>> https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>>> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de
>>> baja desde la propia aplicación en el momento en que lo desee.
>>> http://listas.unizar.es
>>> ----------
>>>
>>
>> _______________________________________________
>> Opengnsys-users mailing listOpengnsys-users en listas.unizar.eshttps://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
>> ----------
>> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>>
>> Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
>> Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace: https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
>> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.http://listas.unizar.es
>> ----------
>>
>>
>>
> _______________________________________________
> Opengnsys-users mailing listOpengnsys-users en listas.unizar.eshttps://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
> ----------
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>
> Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
> Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace: https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.http://listas.unizar.es
> ----------
>
>
> _______________________________________________
> Opengnsys-users mailing list
> Opengnsys-users en listas.unizar.es
> https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users
> ----------
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
>
> Ud. recibe este correo por pertenecer a una lista de correo gestionada por
> la Universidad de Zaragoza.
> Puede encontrar toda la información sobre como tratamos sus datos en el
> siguiente enlace:
> https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas
> Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de
> baja desde la propia aplicación en el momento en que lo desee.
> http://listas.unizar.es
> ----------
>
--
*Antonio J. Doblas Viso adv en uma.es <adv en uma.es>*
* Servicio de Enseñanza Virtual y Laboratorios Tecnológicos
<http://www.evlt.uma.es>*
* UNIVERSIDAD DE MÁLAGA <http://www.uma.es>*
- Aulario López Peñalver 951 95 3099
- E.T.S de Arquitectura 952 13 6576
- Facultad de Bellas Artes 952 13 7108
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.unizar.es/pipermail/opengnsys-users/attachments/20210714/1291a0dc/attachment-0001.html>
Más información sobre la lista de distribución Opengnsys-users