Mostrando entradas con la etiqueta systemd. Mostrar todas las entradas
Mostrando entradas con la etiqueta systemd. Mostrar todas las entradas

jueves, 5 de noviembre de 2020

Onedrive actualizado en Linux

A pesar de ser un usuario de Dropbox desde que esta aplicación nació, y que además tengo contratada una licencia plus de 2TB, por razones profesionales —los documentos oficiales de mi Universidad tienen que localizarse solo en el software y en el servicio de alojamiento contratado por ella— no me ha quedado más remedio que usar también OneDrive. El problema para lograr un trabajo fluido por alguien que usa software libre para todo está en que no existe un demonio cliente oficial que permita sincronizar OneDrive con el disco duro de trabajo en un sistema operativo Linux. He mirado las posibilidades no oficiales. La que parece más sencilla, Insync, no es GPL y además es de pago. La siguiente posibilidad, Rclone (página propia aquí), sí es GPL y gratuita, y que además permite sincronizar Google Drive, la veo complicada en su configuración (véase aquí y aquí, para el que quiera). Lo que he visto más sencillo y rápido es onedrive, el cliente gratuito y libre de OneDrive de MS.

La instalación y preparación es sencilla. Una buena página que indica lo más importante es ésta. Por pasos:

1. Instalamos

su -c 'dnf install onedrive'


2. Ejecutamos:

$ onedrive

y en el terminal aparece una URL muy grande que nos conecta al sistema Microsoft. Hay que abrir la cuenta y luego (o si ya la tienes abierta también) queda una página en blanco. Copiamos la URL de esa página en el terminal donde decía Enter the response uri:

y con ello permitimos la conexión y sincronización de onedrive con nuestro disco duro.


 

3. Sincronizamos

$ onedrive --synchronize

y aparece en nuestro nautilus —ahora llamado Archivos—. Esta orden actualiza en ambas direcciones TODO el contenido de OneDrive. Si queremos sincronizar solo parte de los directorios o ficheros de nuestro OneDrive, generamos un fichero sync_list en el directorio /home/usuario/.config/onedrive. Ese fichero podría líneas similares a: 

Apuntes
Imagenes
Documenots/fichero1.odt

Siendo los primeros directorios y el último un fichero en concreto que queremos que se sincronice. 

Hasta ahora estoy sincronizándolo todo.

Después de cada cambio, se resincroniza mediante

$ onedrive --synchronize --resync

4. Si queremos evitar la resincronización continua, podemos incluir el cliente onedrive en systemd. De este modo se sincroniza de manera continua desde el inicio y nos olvidamos de resincronizar

$ systemctl --user enable onedrive # permiso
$ systemctl --user start onedrive # inicio servicio

Si queremos comprobar que onedrive está monitorizando los cambios:

$ systemctl status --user onedrive

Si tenemos la monitorización activada y aparece un problema al ejecutar una sincronización al ejecutar onedrive --synchronize --resync—que no es necesario hacer, ya que el sistema se monitoriza automáticamente—, podemos apagar el servicio onedrive en systemd

$ systemctl --user stop onedrive

luego resincronizar OneDrive

$ onedrive --synchronize --resync 

y luego reiniciar el servicio
 
$ systemctl --user start onedrive

Sencillo.


# ACTUALIZACIÓN

He tenido algunos problemas de corte de sincronización y pérdida de identificación. La única forma de solucionarlo ha sido ejecutar

$ onedrive --logout

y luego repetir el proceso de identificación (onedrive, copia del url, acceder a el y copiar la respuesta en el terminal, para luego sincronizar de nuevo onedrive --synchronize).

miércoles, 27 de noviembre de 2019

90 segundos de retraso en el arranque mientras el sistema busca un UUID inexistente

En las últimas semanas he tenido dos problemas en el ordenador y una curiosidad. La curiosidad la dejamos para después y los problemas los he solucionado ayer. ¿Dos problemas?, si el título solo habla de uno. Al solucionar uno ha desaparecido el otro. Los problemas eran, primero, que el ordenador mostraba ciertos momentos de congelación en fases cada determinado tiempo —20-30 segundos—; el segundo, que solo lo notaba al reiniciar el ordenador, lo que pasa solo por actualización de kernel, era que el sistema se paraba 1 minuto y 30 segundos buscando un dispositivo con un UUID —Identificador Único Universal— inexistente en mi sistema. Al arrancar notaba un tiempo en vacío; si le damos a ESC, en vez de verse el logo de Fedora aparece el protocolo de arranque y ahí se podía leer:

A start job is running for /dev/disk/by-uuid/9013.... (34s / 1 min 30s)

y tenía 90 segundos para leer el mensaje hasta que seguía el arranque, que si no fuera por esto tarda unos 30s. Al apagar también tardaba y aparecía el mensaje

A stop job is running for Disk Manager (7s / 1 min 30s)

Lo primero que hice fue comprobar los UUID de los dispositivos del equipo, así que edité fstab

su -c 'nano -$ /etc/fstab'

y ninguna de las particiones del disco del sistema (/, /boot, /boot/efi) ni los otros 4 discos duros tienen ese UUID.
Ademas, lo comprobé de nuevo con blkid, que muestra los atributos de los dispositivos:


su -c 'blkid'

así como

su -c 'lsblk -ff'

que lo deja más claro, ya que dibuja un árbol mejor distribuido. Y, como debería ser, tampoco coincide ningún dispositivo con ese UUID. Revisando la red en muchos sitios se achaca este problema a un cambio de swap y que el UUID nuevo no haya sustituido al antiguo. Sin embargo mi partición swap muestra el UUID que se le asigna por fstab y la swap funciona como podemos ver


Entonces, si no estaba en fstab, y no era un problema de swap, ¿de dónde venía la orden de buscar ese dispositivo? Me puse a buscar parte de la cadena en los ficheros del sistema

su -c 'grep -lir "9013ddb2" /'

y el resultado fue nulo. Luego revisé los logs, y tampoco apareció nada. Miré todo lo que pude sobre systemd, y nada. Así que finalmente acabé en /boot/efi/EFI/fedora/grub.cfg y ahí estaba:

... resume=UUID=9013ddb2-...

Primero, ¿por qué el sistema no me lo había mostrado al pedírselo?; será que el administrador no puede entrar en EFI...
Segundo, el grub.cfg no se debe editar directamente, como dice el mismo,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

así que revisamos el fichero /etc/default/grub y los del directorio /etc/grub.d. Ninguno contenía ese UUID, así que ejecutamos

su -c 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg'

y reiniciamos y arrancó en un suspiro.

El segundo problema era la congelación temporal del sistema. En algunos sitios había observado que se podía deber a mutter, y que ere error se había corregido para la versión 3.34.1.11, pero era la que tenía y seguía congelándose. Sin embargo, al reiniciar después de haber cambiado grub.cfg el sistema dejo de estar congelado, asi que asumo que cada 20 o 30 segundos el sistema seguía buscando un dispositivo inexistente.

Queda por satisfacer la curiosidad, que es sobre sudo. Si me pongo a ello, lo pondré en otra entrada.