From bf383cf4ceda2d47e8b2d960fd866792fe5b8940 Mon Sep 17 00:00:00 2001 From: Johanna England Date: Fri, 1 Mar 2024 14:01:35 +0100 Subject: [PATCH] Remove unknown option --- NOTES.rst | 4 ++-- doc/reference/ipdevpoll.rst | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/NOTES.rst b/NOTES.rst index 62223935e9..c356b9d6cd 100644 --- a/NOTES.rst +++ b/NOTES.rst @@ -562,7 +562,7 @@ Daemon startup privileges By accident, some of NAV's daemons have been running as the privileged ``root`` user since NAV 4.9.0, due to changes in the process control system. NAV 5.0.4 -introduces the :option:`privileged` option in the :file:`daemons.yml` configuration +introduces the ``privileged`` option in the :file:`daemons.yml` configuration file, to signal which daemons actually need to be started with root privileges. Only :program:`snmptrapd` and :program:`pping` need root privileges on startup, @@ -573,7 +573,7 @@ Please ensure your :file:`daemon.yml` configuration file is updated. Also, be aware that after upgrading to NAV 5.0.4 from any version from 4.9.0 and up, you may have some NAV log files that are owned by ``root``, which will cause some of the daemons to fail on startup. Please ensure all NAV log files are writable -for the user defined as :option:`NAV_USER` in :file:`nav.conf`. +for the user defined as ``NAV_USER`` in :file:`nav.conf`. New features diff --git a/doc/reference/ipdevpoll.rst b/doc/reference/ipdevpoll.rst index 64f20d5a12..4b36aa9d85 100644 --- a/doc/reference/ipdevpoll.rst +++ b/doc/reference/ipdevpoll.rst @@ -135,7 +135,7 @@ are reserved for synchronous communication with the PostgreSQL database backend. Even on a multi-core server, this means all of ipdevpoll's work is limited to a single core. Once ipdevpoll's workload grows beyond what a single core can handle, ipdevpoll can optionally run in a *multiprocess mode*, using -the :option:`--multiprocess` option. +the ``--multiprocess`` option. In multiprocess mode, ipdevpoll spawns a number of worker processes, while the master process becomes a simple job scheduler, distributing the actual jobs to @@ -145,7 +145,7 @@ the individual workers. ipdevpoll's default number of workers processes and threads aren't necessarily sane for multiprocess usage. Unless a number of workers is - supplied to the :option:`--multiprocess` option, it will spawn a number of + supplied to the ``--multiprocess`` option, it will spawn a number of workers corresponding to the number of cores it detects on your system. The default number of database threads in ipdevpoll's threadpool is **10** per process, which means each worker process will create **10 individual connections to @@ -155,13 +155,13 @@ the individual workers. default pool of 100 available connections, causing other NAV processes to be unable to connect to the database. When enabling multiprocess mode, you should really tune down the threadpool size by adding the - :option:`--threadpoolsize` option. + ``--threadpoolsize`` option. Another good thing about the multiprocess mode is that you can limit the number of jobs any worker process will run before it is killed and respawned. This may provide additional protection against unintended resource leaks. See -the :option:`--max-jobs-per-worker` option. +the ``--max-jobs-per-worker`` option. You can make sure ipdevpoll always runs in multiprocess mode by altering the ``command`` option in the ``ipdevpoll`` entry of the configuration file