InforSupports

Categoría: Sistemas operativos

  • OneDrive vinculado sin querer: cómo desvincularlo sin perder archivos

    Un caso frecuente en soporte a PYMES: un usuario con cuenta local de Windows (no cuenta Microsoft) agrega un correo de Outlook/Hotmail compartido de la empresa en la app de Correo o en Outlook clásico — y sin que lo solicite, Windows vincula automáticamente ese correo a OneDrive. A partir de ahí, OneDrive empieza a sincronizar archivos de la máquina hacia la nube, hasta llenar el almacenamiento gratuito (5 GB) y disparar notificaciones persistentes que no desaparecen porque el problema de fondo nunca se resolvió.

    Por qué pasa esto

    Windows 10 y 11 integran el ecosistema Microsoft de forma agresiva: en cuanto se agrega cualquier cuenta de Outlook/Hotmail/Live a un cliente de correo del sistema, Windows la interpreta como una «cuenta Microsoft» utilizable, y ofrece (o directamente activa) la sincronización de OneDrive asociada — incluso si el usuario nunca tuvo intención de usar OneDrive en esa máquina.

    El riesgo real

    El problema no es solo el espacio lleno. Al tratarse de una cuenta de correo compartida entre varias personas (un patrón común en negocios pequeños, donde varios empleados usan el mismo buzón para atención al cliente o ventas), vincularla a OneDrive en una máquina local expone los archivos sincronizados de esa máquina a todos los que tienen acceso a ese correo compartido — no solo al usuario que lo configuró, lo que puede crear un problema de riesgo en la confidencialidad de la información.

    La solución recomendada: solo webmail, sin cliente instalado

    Para correos compartidos, la práctica más segura es no vincularlos nunca a ningún cliente de correo de escritorio ni a apps móviles con sincronización — acceder siempre vía navegador en outlook.live.com. Esto da cero sincronización, cero archivos descargados, y cero riesgo de que la máquina local quede «anclada» a esa cuenta compartida.

    Pasos de corrección (sin pérdida de datos)

    Paso 0 — Verificación previa

    Revisar el contenido de la carpeta local antes de tocar nada:

    C:\Users\[nombre de usuario]\OneDrive

    Si hay archivos importantes ahí, copiarlos manualmente a Documentos o al Escritorio antes de continuar.

    Paso 1 — Desvincular OneDrive (no desinstalar, no borra nada local)

    1. Clic en el ícono de OneDrive (bandeja del sistema)
    2. Ícono de engranaje → Configuración
    3. Pestaña «Cuenta»
    4. Clic en «Desvincular este equipo»
    5. Confirmar

    Paso 2 — Quitar la cuenta de correo del cliente de Windows

    App Correo de Windows:

    1. Abrir la app Correo
    2. Configuración (engranaje)
    3. Administrar cuentas
    4. Seleccionar la cuenta del correo compartido
    5. «Eliminar cuenta de este dispositivo»

    Outlook clásico (Office):

    1. Archivo → Configuración de cuenta → Configuración de cuenta
    2. Seleccionar la cuenta
    3. Quitar

    Paso 3 — Evitar que OneDrive inicie automáticamente

    1. Clic derecho en OneDrive (bandeja)
    2. Configuración → pestaña «Configuración» / «Sincronización y copia de seguridad»
    3. Desmarcar «Iniciar OneDrive automáticamente al iniciar sesión en Windows»

    Paso 4 — Limpiar archivos ya sincronizados en la nube

    1. Abrir Chrome
    2. Ir a onedrive.live.com
    3. Iniciar sesión con el correo compartido
    4. Eliminar los archivos subidos desde esa máquina
    5. Ir a la papelera de reciclaje de OneDrive y vaciarla

    Esto libera el espacio y elimina la advertencia de almacenamiento al 90%.

    Paso 5 — Dejar acceso directo al webmail

    1. Ir a outlook.live.com en Chrome
    2. Iniciar sesión con el correo compartido
    3. Menú (⋮) → Guardar y compartir → Crear acceso directo
    4. Colocar el acceso directo en el escritorio

    Resumen de impacto por acción

    Acción¿Borra datos locales?
    Desvincular OneDriveNo
    Quitar cuenta de Outlook/CorreoNo (solo quita el acceso vía app)
    Limpiar archivos en OneDrive webSolo afecta la nube
    Vaciar papelera de OneDriveSolo afecta la nube

    La máquina local queda completamente intacta durante todo el proceso — solo se eliminan archivos que nunca debieron sincronizarse a la nube en primer lugar.

    Recomendación para correos compartidos

    Cuando un correo se usa entre varias personas (ventas, soporte, atención al cliente), la política más segura es no volver a vincularlo a OneDrive ni a ningún cliente de Outlook en ningún equipo — usar siempre acceso vía navegador, sin excepción. Esto evita tanto el consumo innecesario de almacenamiento como la exposición accidental de archivos locales de cualquier equipo donde se haya configurado por error.

  • Dominando systemd: servicios, logs y herramientas ctl

    Systemd es el sistema de inicialización y gestor de servicios usado por la mayoría de distribuciones Linux modernas (Debian, Ubuntu, Fedora, RHEL, Arch). Además de arrancar el sistema, systemd centraliza el control de casi todos los aspectos de administración a través de un conjunto de herramientas con el sufijo ctl («control»):

    • Servicios (.service) — procesos que corren en segundo plano.
    • Timers (.timer) — el reemplazo moderno de cron.
    • Sockets (.socket) — activación de servicios bajo demanda al recibir conexiones.
    • Targets — agrupaciones de unidades, equivalentes a los «runlevels» de SysV.
    • Logs (journal) — el sistema centralizado de registro de eventos.
    • Sesiones (loginctl) — gestión de sesiones de usuario.
    • Fecha/hora (timedatectl), hostname (hostnamectl), locales (localectl), red (networkctl) y DNS (resolvectl).
    • Bootloader (bootctl) y contenedores (machinectl, systemd-nspawn).

    Crear servicios systemd

    Estructura de un servicio

    Un servicio personalizado se define en un archivo .service, típicamente dentro de /etc/systemd/system/:

    [Unit]
Description=Mi servicio de ejemplo
Documentation=https://example.com/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=usuario
Group=usuario
WorkingDirectory=/opt/app
ExecStart=/usr/bin/python3 /opt/app/app.py
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
Environment="ENV=produccion"
EnvironmentFile=/etc/default/app

[Install]
WantedBy=multi-user.target

    Cada sección cumple un propósito distinto:

    • [Unit] — metadatos y dependencias. After controla el orden de arranque (espera a que ocurra el evento indicado), mientras Wants expresa una dependencia flexible: si la red no está disponible, el servicio arranca igual, solo que después.
    • [Service] — cómo se ejecuta el proceso. Type=simple asume que el proceso principal no hace fork; ExecStart es el comando real; Restart=on-failure hace que systemd reinicie el servicio automáticamente si termina con un código de error (no en un cierre limpio); RestartSec es la pausa antes de reintentar.
    • [Install] — define en qué target se activa el servicio al hacer enable. multi-user.target es el equivalente al runlevel 3 clásico (sistema multiusuario, sin entorno gráfico).

    Procedimiento universal

    Flujo estándar para crear, activar y verificar cualquier servicio nuevo:

    sudo nano /etc/systemd/system/mi-servicio.service
sudo systemctl daemon-reload
sudo systemctl start mi-servicio
systemctl status mi-servicio
sudo systemctl enable mi-servicio

    daemon-reload es el paso que más se olvida: systemd cachea las definiciones de las unidades en memoria, así que cualquier cambio al archivo .service no se aplica hasta ejecutar este comando. enable crea el enlace simbólico que hace que el servicio arranque automáticamente en el próximo boot — start solo lo arranca ahora, una vez.

    Logs con journalctl

    El journal es el sistema de logs binario centralizado de systemd — reemplaza (o complementa) a los archivos de texto tradicionales en /var/log/.

    journalctl -u mi-servicio       # logs de un servicio específico
journalctl -u mi-servicio -f    # seguimiento en vivo (equivalente a tail -f)
journalctl -u mi-servicio -p err # solo mensajes de nivel error o más grave
journalctl -u mi-servicio -b    # logs desde el arranque actual del sistema
journalctl -xe                  # últimas líneas con contexto extendido, útil tras un fallo

    Comandos *ctl del ecosistema systemd

    systemctl — control de unidades

    La herramienta principal para gestionar el estado de servicios y otras unidades:

    systemctl start nombre       # arrancar ahora
systemctl stop nombre        # detener ahora
systemctl restart nombre     # detener y volver a arrancar
systemctl reload nombre      # recargar configuración sin reiniciar el proceso
systemctl enable nombre      # activar en el próximo boot
systemctl disable nombre     # desactivar en el próximo boot
systemctl status nombre      # ver estado actual y últimos logs
systemctl list-units         # listar unidades cargadas actualmente
systemctl list-unit-files    # listar todas las unidades instaladas (activas o no)
systemctl daemon-reload      # releer definiciones de unidades tras editarlas
systemctl isolate multi-user.target  # cambiar de target activo (similar a cambiar runlevel)
systemctl --failed           # listar únicamente las unidades que fallaron

    journalctl — consultas adicionales al journal

    journalctl                    # todo el log disponible
journalctl -f                 # seguimiento en vivo de todo el sistema
journalctl -xe                # contexto extendido de los eventos más recientes
journalctl -p err             # filtrar por severidad (err, warning, crit, etc.)
journalctl -u nombre          # logs de una unidad específica
journalctl -b                 # logs solo del arranque actual
journalctl -k                 # solo mensajes del kernel (equivalente a dmesg)
journalctl --since "2026-01-01"  # filtrar por fecha

    loginctl — sesiones de usuario

    Gestiona sesiones activas, útil en servidores multiusuario o para depurar sesiones colgadas:

    loginctl list-sessions           # ver todas las sesiones activas
loginctl session-status 3        # detalle de una sesión específica
loginctl terminate-session 3     # cerrar una sesión a la fuerza
loginctl list-users              # usuarios con sesión activa
loginctl user-status usuario     # detalle de sesiones de un usuario
loginctl enable-linger usuario   # permite que los servicios de usuario (systemd --user) sigan corriendo aunque cierre sesión

    timedatectl — fecha, hora y NTP

    timedatectl                                  # ver configuración actual
timedatectl set-time "2026-06-30 10:00:00"   # fijar hora manualmente
timedatectl set-timezone America/Guayaquil   # cambiar zona horaria
timedatectl set-ntp true                     # activar sincronización automática por NTP

    hostnamectl — nombre del equipo

    hostnamectl                      # ver hostname y datos del sistema (kernel, arquitectura, etc.)
hostnamectl set-hostname servidor  # cambiar el hostname de forma persistente

    localectl — idioma y teclado

    localectl                          # ver configuración de locale actual
localectl set-locale LANG=es_EC.UTF-8  # cambiar idioma del sistema
localectl set-keymap us            # cambiar distribución de teclado

    networkctl — estado de interfaces de red

    Solo aplica en sistemas que usan systemd-networkd como gestor de red (no todos — muchas distros usan NetworkManager o ifupdown en su lugar):

    networkctl              # listar interfaces y su estado
networkctl status eth0  # detalle de una interfaz específica
networkctl list         # listado resumido
networkctl reload       # releer configuración de red

    resolvectl — resolución DNS

    resolvectl status              # ver servidores DNS configurados por interfaz
resolvectl query google.com    # hacer una consulta DNS de prueba
resolvectl flush-caches        # limpiar la caché de resolución DNS
resolvectl dns eth0 8.8.8.8    # fijar un DNS específico para una interfaz

    machinectl — contenedores y máquinas virtuales ligeras

    Gestiona contenedores creados con systemd-nspawn:

    machinectl list          # ver contenedores registrados
machinectl start debian  # arrancar un contenedor
machinectl stop debian   # detenerlo
machinectl shell debian  # abrir una shell dentro del contenedor

    bootctl — gestor de arranque (systemd-boot)

    bootctl status   # ver estado del bootloader
bootctl install  # instalar systemd-boot en la partición EFI
bootctl update   # actualizar los binarios del bootloader

    systemd-analyze — rendimiento de arranque

    Herramienta de diagnóstico para entender qué tarda en el proceso de boot:

    systemd-analyze                  # tiempo total de arranque, desglosado por fase
systemd-analyze blame            # qué servicios tardaron más en iniciar
systemd-analyze critical-chain   # cadena de dependencias que determinó el tiempo total
systemd-analyze plot > boot.svg  # generar un gráfico visual del arranque

    systemd-run — ejecutar comandos como unidades temporales

    Permite lanzar cualquier comando como si fuera un servicio administrado por systemd, sin crear un archivo .service permanente — útil para pruebas o tareas puntuales que necesitan aislamiento de recursos:

    systemd-run --unit=mi-tarea echo "hola"
systemd-run --scope sleep 10

    systemd-cgls y systemd-cgtop — jerarquía de cgroups

    systemd-cgls    # árbol de cgroups activos (qué proceso pertenece a qué unidad)
systemd-cgtop   # uso de recursos en tiempo real, agrupado por cgroup

    systemd-escape — codificar nombres para unidades

    Convierte rutas o cadenas con caracteres especiales al formato seguro que systemd usa internamente para nombrar unidades:

    systemd-escape "ruta rara"
systemd-escape --path "/home/usuario/archivo"

    systemd-inhibit — evitar suspensión/apagado durante una tarea

    systemd-inhibit sleep 30
systemd-inhibit --why="Proceso crítico" comando

    systemd-notify — comunicación entre el proceso y systemd

    Usado dentro de scripts o servicios Type=notify para avisarle a systemd que el proceso ya está listo, o para reportar su estado actual:

    systemd-notify --ready
systemd-notify --status="Inicializando..."

    systemd-sysusers — creación declarativa de usuarios del sistema

    systemd-sysusers
systemd-sysusers /etc/sysusers.d/archivo.conf

    systemd-tmpfiles — gestión de archivos y directorios temporales

    systemd-tmpfiles --create   # crear archivos/directorios definidos en configuración
systemd-tmpfiles --clean    # limpiar archivos temporales expirados
systemd-tmpfiles --remove   # eliminar los definidos en configuración

    systemd-nspawn — contenedores ligeros

    systemd-nspawn -D /var/lib/machines/debian
systemd-nspawn -M mi-maquina

    Timers systemd

    Los timers son la alternativa moderna a cron, con la ventaja de integrarse con el journal (logs unificados) y con dependencias de otras unidades. Un timer siempre va acompañado de un servicio con el mismo nombre base.

    Timer (backup.timer):

    [Unit]
Description=Backup diario

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

    Persistent=true es clave: si el equipo estuvo apagado cuando debía ejecutarse el timer, lo corre en cuanto vuelve a encender, en vez de esperar al siguiente ciclo — evita perder ejecuciones por reinicios o cortes de energía.

    Servicio asociado (backup.service):

    [Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

    Type=oneshot le indica a systemd que el proceso termina por sí solo tras completar su tarea (no es un servicio de larga duración) — es el tipo correcto para scripts que corren, hacen su trabajo, y salen.

    Activación:

    systemctl enable --now backup.timer
systemctl list-timers

    Depuración avanzada

    Secuencia típica para diagnosticar un servicio que no arranca o falla:

    systemctl status mi-servicio                          # estado y últimas líneas de log
journalctl -u mi-servicio -p err -b                    # solo errores, desde el último boot
journalctl -u mi-servicio -n 20                        # últimas 20 líneas de log
journalctl _PID=$(pidof mi-servicio)                   # logs filtrados por PID específico
systemctl list-dependencies mi-servicio                # árbol de dependencias
systemd-analyze verify /etc/systemd/system/mi-servicio.service  # validar sintaxis del archivo
sudo -u usuario /usr/bin/python3 /opt/app/app.py        # ejecutar manualmente como el mismo usuario, para ver el error real
ls -l /opt/app/app.py                                   # confirmar que el archivo existe y tiene permisos correctos
ls -l /usr/bin/python3                                  # confirmar que el binario existe en la ruta esperada
cat /etc/default/app                                    # revisar variables de entorno cargadas
systemctl daemon-reload                                 # por si el problema es una definición desactualizada

    Interpretación completa de systemctl status

    Ejemplo de salida real:

    ○ rory-indexer.service - Rory Indexer RAG
     Loaded: loaded (/etc/systemd/system/rory-indexer.service; static)
     Active: inactive (dead) since Tue 2026-06-30 03:24:53 -05; 5h 29min ago
TriggeredBy: ● rory-indexer.timer
    Process: 2967487 ExecStart=/opt/rory-indexer/bin/python3 /opt/rory-indexer/scripts/indexer_v2.py (code=exited, status=0/SUCCESS)
   Main PID: 2967487 (code=exited, status=0/SUCCESS)
        CPU: 1min 18.622s

    Primera línea

    Muestra el símbolo de estado visual (● activo, ○ inactivo, ✗ falló, ▲ iniciando), el nombre técnico del servicio y su descripción legible.

    Loaded

    Indica si el archivo .service está cargado, su ruta completa, y el estado de instalación: enabled (arranca en boot), disabled (no arranca en boot pero se puede iniciar manualmente), static (no tiene sección [Install], solo se activa como dependencia de otra unidad), o masked (bloqueado explícitamente, no se puede iniciar ni siquiera manualmente).

    Active

    El estado real de ejecución: active (running), inactive (dead), failed, activating o deactivating (transiciones en curso), y reloading.

    TriggeredBy

    Indica qué otra unidad activó este servicio — típicamente un Timer, un Socket, o un Path (activación al detectar cambios en un archivo/directorio).

    Process

    Detalle del último proceso ejecutado: PID, comando exacto que se corrió, y el código de salida (exit code) — clave para saber si terminó bien (status=0/SUCCESS) o con error.

    Main PID

    El proceso principal identificado por el servicio, el que systemd supervisa para determinar si sigue vivo.

    CPU

    Tiempo total de CPU consumido por el servicio desde que arrancó.

    Logs

    Las últimas líneas del journal relacionadas con esta unidad, mostradas automáticamente al final del status.

    Buenas prácticas

    • Usar siempre rutas absolutas en ExecStart — systemd no hereda el $PATH de una shell de usuario.
    • Restart=on-failure como valor por defecto razonable, para que el servicio se recupere solo ante caídas inesperadas.
    • After=network-online.target si el servicio depende de conectividad de red al arrancar (evita condiciones de carrera con la red, como las que resuelven un resolv.conf vacío en contenedores Docker al bootear antes que la red).
    • EnvironmentFile= para mantener configuraciones y secretos fuera del archivo .service en sí, en un archivo separado con permisos restringidos.
    • Monitorear en vivo con journalctl -u servicio -f al depurar o al desplegar cambios.
    • Nunca olvidar systemctl daemon-reload después de editar cualquier archivo .service o .timer.