df muestra el doble del tamaño real en FreeBSD cuando se ejecuta a través de cron

3 minutos de lectura

avatar de usuario
Félix

Escribí un script bash que recopila datos de un servidor y los envía a un archivo de registro que está siendo monitoreado por un splunkforwarder. El servidor ejecuta FreeBSD y tiene un ZPool que se comparte a través de Samba. Entonces, por supuesto, una de las cosas que me gustaría que Splunk controlara es cuánto espacio se usa en dicho recurso compartido.

Para mantener las cosas legibles, extraje las líneas de mi script que logran esto:

#!/usr/bin/env bash
while read disk used avail ; do
        # In reality I pass these values to a function
        # that adds some formatting, but let's keep it
        # simple for the moment
        echo $disk " " $used " " $avail
done < <(df | awk '/datapool\// {print $1, $3, $4}')

Cuando ejecuto estas líneas desde la línea de comando, obtengo los números correctos (he comparado la salida con zfs list). Pero cuando ejecuto este script a través de cron, los números que obtengo se duplican.

Veamos la salida exacta en mi máquina:

# Manually
datapool/myshare   4842023944   24758292883

# Via cron
datapool/myshare   9684047889   49516585766

Esto solo sucede en FreeBSD. Tengo otro servidor de almacenamiento ZFS que se ejecuta en Debian y cuando ejecuto exactamente el mismo script allí, obtengo números correctos todo el tiempo.

Intenté ejecutar el trabajo cron como diferentes usuarios (incluido el root), pero siempre es el mismo resultado. También configuré la variable de entorno PATH en el mismo valor que tengo cuando ejecuto este script manualmente (en lugar de la versión abreviada que suele usar cron).

No tengo absolutamente ninguna idea sobre la causa de este problema y realmente no sé cómo solucionarlo. Además, no pude encontrar ninguna información en Internet que esté ni remotamente relacionada con este problema.

Realmente espero que me puedan ayudar aquí y CUALQUIER sugerencia es muy apreciada 🙂

  • df utiliza BLOCKSIZE para determinar qué unidades se informan. Puede que lo tengas configurado para k para usted (es decir, 1024), pero no para root (predeterminado: 512).

    – Ricardo Smith

    23 de enero de 2018 a las 14:31

  • Puede que esté tramando algo 🙂 Ejecuté el trabajo cron con mi propia cuenta de usuario (utilizo /etc/crontab para eso) pero obtuve los mismos resultados. ¿Tu sugerencia también se aplica en esa situación? Tendré la oportunidad de probar esto el viernes, te responderé una vez que lo haya probado 🙂

    – Félix

    23 de enero de 2018 a las 16:08


  • Sí. cron probablemente se ejecuta en un entorno donde BLOCKSIZE no está configurado, en cuyo caso df por defecto informa los tamaños de disco como múltiplos de 512, lo que producirá la discrepancia que está viendo.

    – Ricardo Smith

    23 de enero de 2018 a las 16:48

  • Tu sugerencia fue absolutamente acertada. Agregué BLOCKSIZE=1024 a mi crontab y ahora obtengo los números escalados correctamente. ¿Te importaría escribir tu comentario como respuesta para que pueda marcarlo como correcto? 🙂

    – Félix

    26 de enero de 2018 a las 15:26

df(1) utiliza la variable de entorno BLOCKSIZE para determinar qué unidades se utilizan al informar sobre el espacio en disco.

Por defecto, por razones históricas, se utiliza un tamaño de bloque de 512. Es habitual configurar esta variable dentro del entorno del shell de inicio de sesión de uno a un valor más conveniente. Por ejemplo:

setenv  BLOCKSIZE  "K"

cron(8) se ejecuta con un entorno diferente al shell de inicio de sesión. Los síntomas que está viendo son consistentes con BLOCKSIZE siendo indefinido para cronentorno de , y se establece en un valor de k o 1024 para el entorno del shell de inicio de sesión.

  • También puede dar a df el compatible con POSIX -k opción para que use bloques de 1024 bytes.

    –Mark Plotnick

    10 de febrero de 2018 a las 17:15

¿Ha sido útil esta solución?