MINOR: config: allow no set-dumpable config option

in global config parsing, we currently expect to have a possible no
keyword (KWN_NO), but we never allow it in config parsing.
another patch could have been to simply remove the code handling a
possible KWN_NO.
take this opportunity to update documentation of set-dumpable.

Signed-off-by: William Dauchy <w.dauchy@criteo.com>
This commit is contained in:
William Dauchy 2019-10-27 20:08:10 +01:00 committed by Willy Tarreau
parent 0a8824f25d
commit ec73098171
2 changed files with 23 additions and 19 deletions

View File

@ -1141,22 +1141,23 @@ setenv <name> <value>
set-dumpable
This option is better left disabled by default and enabled only upon a
developer's request. It has no impact on performance nor stability but will
try hard to re-enable core dumps that were possibly disabled by file size
limitations (ulimit -f), core size limitations (ulimit -c), or "dumpability"
of a process after changing its UID/GID (such as /proc/sys/fs/suid_dumpable
on Linux). Core dumps might still be limited by the current directory's
permissions (check what directory the file is started from), the chroot
directory's permission (it may be needed to temporarily disable the chroot
directive or to move it to a dedicated writable location), or any other
system-specific constraint. For example, some Linux flavours are notorious
for replacing the default core file with a path to an executable not even
installed on the system (check /proc/sys/kernel/core_pattern). Often, simply
writing "core", "core.%p" or "/var/log/core/core.%p" addresses the issue.
When trying to enable this option waiting for a rare issue to re-appear, it's
often a good idea to first try to obtain such a dump by issuing, for example,
"kill -11" to the haproxy process and verify that it leaves a core where
expected when dying.
developer's request. If it has been enabled, it may still be forcibly
disabled by prefixing it with the "no" keyword. It has no impact on
performance nor stability but will try hard to re-enable core dumps that were
possibly disabled by file size limitations (ulimit -f), core size limitations
(ulimit -c), or "dumpability" of a process after changing its UID/GID (such
as /proc/sys/fs/suid_dumpable on Linux). Core dumps might still be limited by
the current directory's permissions (check what directory the file is started
from), the chroot directory's permission (it may be needed to temporarily
disable the chroot directive or to move it to a dedicated writable location),
or any other system-specific constraint. For example, some Linux flavours are
notorious for replacing the default core file with a path to an executable
not even installed on the system (check /proc/sys/kernel/core_pattern). Often,
simply writing "core", "core.%p" or "/var/log/core/core.%p" addresses the
issue. When trying to enable this option waiting for a rare issue to
re-appear, it's often a good idea to first try to obtain such a dump by
issuing, for example, "kill -11" to the haproxy process and verify that it
leaves a core where expected when dying.
ssl-default-bind-ciphers <ciphers>
This setting is only available when support for OpenSSL was built in. It sets

View File

@ -2147,9 +2147,12 @@ next_line:
args[arg] = args[arg+1]; // shift args after inversion
}
if (kwm != KWM_STD && strcmp(args[0], "option") != 0 && \
strcmp(args[0], "log") != 0 && strcmp(args[0], "busy-polling")) {
ha_alert("parsing [%s:%d]: negation/default currently supported only for options, log, and busy-polling.\n", file, linenum);
if (kwm != KWM_STD && strcmp(args[0], "option") != 0 &&
strcmp(args[0], "log") != 0 && strcmp(args[0], "busy-polling") != 0 &&
strcmp(args[0], "set-dumpable") != 0) {
ha_alert("parsing [%s:%d]: negation/default currently "
"supported only for options, log, busy-polling and "
"set-dumpable.\n", file, linenum);
err_code |= ERR_ALERT | ERR_FATAL;
}