En un sistema multiusuario es probable que no confíes en que el sistema no vaya a ser dañado por ningún usuario.
Las cuotas de disco permiten al administrador decirle al sistema de ficheros qué cantidad de espacio de disco puede utilizar un usuario; además, ofrecen una manera rápida de comprobar el uso de disco de un usuario sin tener que calcularlo cada vez. Las cuotas se estudian en el capítulo de quotas.
El resto de límites de recursos incluyen cantidad de CPU, memoria, y otros recursos que el usuario puede utilizar.
Las clases de login se definen en
/etc/login.conf. La semántica precisa está
fuera del alcance de esta sección, pero se describe con detalle en
la página de manual login.conf(5). Es suficiente decir que
cada usuario es asignado a una clase de login
(default por defecto), y que cada clase de
login tiene un conjunto de capacidades asociado. Una capacidad
de login es un par
nombre=valor,
donde nombre es un identificador
conocido y valor una cadena de texto
arbitraria que se procesa en función del nombre. Establecer
clases y capacidades de login es bastante sencillo y también se
describe en login.conf(5).
Los límites de recursos son diferentes de las capacidades de login en dos sentidos. En primer lugar, para cada límite existe un límite blando (actual) y uno duro. Un límite blando puede ser ajustado por el usuario o una aplicación, pero no puede ser más alto que el límite duro. Éste último puede ser disminuido por el usuario pero nunca aumentado. En segundo lugar, la mayoría de los límites de recursos aplican a un usuario concreto por proceso, no globalmente. Nótese, no obstante, que estas diferencias vienen impuestas por cómo se tratan los límites específicamente, no por la implementación del marco de capacidades de login (es decir, en realidad no constituyen un caso especial de capacidades de login).
Sin más, a continuación veremos los límites de recursos más comúnmente usados (el resto, junto con el resto de capacidades de login, puede encontrarse en login.conf(5)).
coredumpsizeEl tamaño de un fichero core generado por un programa
está, por razones obvias, subordinado a otros límites sobre
uso de disco (p. ej., filesize, o cuotas
de disco). Aun y así, se usa frecuentemente como un método
menos severo de controlar consumo de espacio de disco, dado
que los usuarios no generan ficheros core por ellos mismos,
y a menudo no los borran, activar este límite puede evitar
que agoten el espacio de disco de que disponen si algún
programa grande (p. ej., emacs)
deja de funcionar abruptamente.
cputimeÉsta es la máxima cantidad de tiempo de CPU que los procesos de un usuario pueden consumir.
Éste es un límite sobre el tiempo de CPU consumido, no el porcentaje de uso de CPU que se muestra en algunos campos de top(1) y ps(1). Un límite de ese tipo no es posible a día de hoy, y sería bastante inútil: un compilador —probablemente una tarea legítima— puede usar prácticamente el 100% de la CPU durante algún tiempo con facilidad.
filesizeÉste es el tamaño máximo que puede llegar a tener un fichero del usuario. A diferencia de las cuotas de disco, este límite se especifica para ficheros individuales, no para el conjunto de todos los archivos que posee.
maxprocÉste es el máximo número de procesos que un usuario
puede ejecutar a la vez, incluidos tanto los procesos en
primer plano como los procesos en segundo plano. Por
razones obvias, este límite no puede ser mayor que el límite
de sistema especificado por kern.maxproc
sysctl. Obsérvese también que si
asignamos un valor demasiado bajo a este límite podemos
mermar la productividad de un usuario: frecuentemente es
útil entrar múltiples veces en el sistema o ejecutar
pipelines. Algunas tareas, como compilar largos programas,
lanzan múltiples procesos (p. ej., make(1), cc(1),
y demás preprocesadores intermedios).
memorylockedÉsta es la máxima cantidad de memoria que un proceso puede haber solicitado tener bloqueada en memoria principal (p. ej., ver mlock(2)). Algunos programas críticos para el sistema, como amd(8), se quedan bloqueados en la memoria principal de manera que en caso de ser llevados a swap no contribuyan a la basura del sistema si hay algún problema.
memoryuseÉsta es la mayor cantidad de memoria que un proceso puede consumir en todo momento. Incluye tanto memoria normal como uso de swap. No se trata de un límite para restringir el consumo de memoria en general, pero es un buen comienzo.
openfilesÉsta es la máxima cantidad de archivos que un proceso
puede tener abiertos. En FreeBSD, los archivos se usan
tambien para representar sockets y canales IPC; así, cuida
de no poner este límite demasiado bajo. A nivel de sistema,
el límite para esto lo define
kern.maxfiles
sysctl.
sbsizeÉste es el límite de cantidad de memoria de red, y por lo tanto mbufs, que un usuario puede consumir. Se originó como respuesta a un viejo ataque DoS que creaba muchos sockets, pero puede ser usado en general para limitar las comunicaciones por red.
stacksizeÉste es el tamaño máximo que puede alcanzar la pila de un proceso. Por sí solo no es suficiente para limitar la cantidad de memoria que puede usar un programa; en consecuencia, debería ser usado junto con otros límites.
Hay unas pocas cosas más a recordar cuando establecemos límites de recursos. A continuación vienen algunas recomendaciones, sugerencias, y comentarios varios.
Los procesos que se ponen en marcha cuando arranca el
sistema por /etc/rc están asignados a la
clase de login daemon.
Aunque el /etc/login.conf que viene
con el sistema tiene valores razonables para la mayoría de los
límites, sólo tú, el administrador, puedes saber lo que es
apropiado para tu sistema.
A los usuarios del X Window System (X11) probablemente se les debería conceder más recursos que al resto. X11 de por sí consume muchos recursos, pero además contribuye a que los usuarios ejecuten más programas simultáneamente.
Recuerda que hay muchos límites que aplican a procesos
individuales, no al usuario en general. Por ejemplo, poner
openfiles a 50 significa que cada uno de
los procesos que ejecute un usuario puede abrir a lo máximo 50
ficheros. Así, la cantidad de ficheros que un usuario puede
abrir es el valor de openfiles multiplicado
por el valor de maxproc. Esto también
aplica al uso de memoria.
Para más información acerca de límites de recursos y clases y capacidades de login en general, consulta las páginas de manual relevantes: cap_mkdb(1), getrlimit(2), login.conf(5).
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.