Hi all,
Not really a bug report because I did not manage to figure out the cause.
However, after upgrading from FC31 to FC32 I could not login any more, due
to SELinux problems. Auto-relabeling did not work, nothing really...
... until I did dnf uninstall MonetDB-selinux.
I came to this point because trying to give systemd services the correct
labels with restorecon failed with an error referencing a monetdb specific
file.
I do not have the details unfortunately, but if you get problems, beware
that MonetDB SELinux package and systemd may interfere in some way beyond
my knowledge of these services.
Best regards,
Arjen
PS: Some output from logs:
sudo ausearch -c monetdb -m AVC,SELINUX_ERR
[..]
----
time->Sat May 2 20:57:01 2020
type=AVC msg=audit(1588445821.693:203): avc: denied { open } for
pid=1232 comm="monetdbd" path="/etc/resolv.conf" dev="dm-0" ino=3409775
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.043:1194): avc: denied { execute } for
pid=2861 comm="(monetdbd)" name="monetdbd" dev="dm-0" ino=2147256
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.043:1195): avc: denied { execute_no_trans }
for pid=2861 comm="(monetdbd)" path="/usr/bin/monetdbd" dev="dm-0"
ino=2147256 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.044:1196): avc: denied { map } for
pid=2861 comm="monetdbd" path="/usr/bin/monetdbd" dev="dm-0" ino=2147256
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="unconfined_u:object_r:monetdbd_exec_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1197): avc: denied { remove_name } for
pid=1232 comm="monetdbd" name="merovingian.pid" dev="tmpfs" ino=34369
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
trawcon="system_u:object_r:monetdbd_var_run_t:s0"
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1198): avc: denied { unlink } for
pid=1232 comm="monetdbd" name="merovingian.pid" dev="tmpfs" ino=34369
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:12:56 2020
type=AVC msg=audit(1588446776.714:1199): avc: denied { write } for
pid=1232 comm="monetdbd" name=".merovingian_lock" dev="dm-0" ino=5899443
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
trawcon="system_u:object_r:monetdbd_lock_t:s0"
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1209): avc: denied { read } for
pid=2925 comm="(monetdbd)" name="passwd" dev="dm-0" ino=524514
scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0
tclass=file permissive=1
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1210): avc: denied { open } for
pid=2925 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:13:15 2020
type=AVC msg=audit(1588446795.214:1211): avc: denied { map } for
pid=2925 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1281): avc: denied { read } for
pid=3072 comm="(monetdbd)" name="passwd" dev="dm-0" ino=524514
scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0
tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1282): avc: denied { open } for
pid=3072 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
----
time->Sat May 2 21:14:24 2020
type=AVC msg=audit(1588446864.487:1283): avc: denied { map } for
pid=3072 comm="(monetdbd)" path="/var/lib/sss/mc/passwd" dev="dm-0"
ino=524514 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=file permissive=1
--
====================================================================
ICIS, office M1.00.05 Radboud University
Mercator 1 Faculty of Science
Toernooiveld 212 arjen(a)cs.ru.nl
NL-6525 EC Nijmegen, The Netherlands +31-(0)24-365 2354
===================== http://www.informagus.nl/ ====================
--
====================================================================
ICIS, office M1.00.05 Radboud University
Mercator 1 Faculty of Science
Toernooiveld 212 arjen(a)cs.ru.nl
NL-6525 EC Nijmegen, The Netherlands +31-(0)24-365 2354
===================== http://www.informagus.nl/ ====================
Hi there,
I looked around but couldn't find any recommendation about kernel vm
settings in Linux for MonetDB.
In particular:
- vm.overcommit_memory:
0 (default) : a heuristics decides whether overcommitting is allowed
1: no check, overcommit is always allowed
2: overcommitting is regulated by vm.overcommit_ratio (default = 50%)
Do I understand correctly that using vm.overcommit_memory=1 will only make
the OOM kill mserver5 when the total VM available is exhausted?
If that is true, should it be reasonably safe to use on a server that is
mainly intended for MonetDB, as long as sufficient disk space is available?
- vm.swappiness
Generic recommendations are usually 60 for a desktop and 30 for a server.
Oracle recommends 10.
Redis recommends 1.
Are there studies / recommendations for MonetDB?
The MonetDB team at MonetDB BV is pleased to announce the
Oct2020-SP4 bugfix release of the MonetDB suite of programs.
More information about MonetDB can be found on our website at
<https://www.monetdb.org/>.
For details on this release, please see the release notes at
<https://www.monetdb.org/Downloads/ReleaseNotes>.
As usual, the download location is <https://www.monetdb.org/downloads/>.
Oct2020-SP4 Bugfix Release (11.39.15)
ODBC Driver
* When connecting using a DSN (Data Source Name), information about
the data source is retrieved from the ODBC.INI file. Now we also
get the location of the LOGFILE from this file. The logfile can be
used to log all calls to the MonetDB ODBC driver to a file which
can be used for debugging.
* The ODBC driver now only passes on information about HUGEINT
columns as HUGEINT when the application has indicated interest by
querying about the SQL_HUGEINT extension type using the
SQLGetTypeInfo function or by specifying the type in a call to
SQLSetDescField. Otherwise the driver silently translates the
HUGEINT type to BIGINT. This means that most application will see
BIGINT columns when the server produced a HUGEINT column and only
give an error if the value in the HUGEINT column didn't fit into a
BIGINT.
Bug Fixes
* 6786: function json.isvalid(js json) is not useful, could be
removed
* 7016: Database crashes when use similarity function on a table with
more than 200k records
* 7037: Clearer err msg for ALTER USER with insufficient privileges
* 7042: AddressSanitizer:DEADLYSIGNAL in Oct2020/gdk/gdk_tracer.c:494
* 7050: file descriptor leak when forward=redirect
* 7057: ODBC driver installer on Windows is missing some DLLs
* 7058: MonetDBe: COPY INTO csv file does not produce any output
* 7059: MonetDBe: 'reverse' C UDF crashes
* 7061: Have bulk load support combined gzip files
* 7064: Temporary hashes created in hash and unique logic should try
to use transient data farm first
* 7066: percent_rank function with wrong results
* 7070: double free error when running MonetDBe Example
* 7076: mserver5 ignores memory.low from cgroups v2
* 7077: Oct2020: new default privileges not effectively communicated
* 7083: MonetDBe C++ Compiling Error
* 7085: Mitosis and filter functions
* 7087: SIGSEGV caused by error in subquery's function being ignored
by top-level query
* 7089: Data consistency problem of query results in the latest
release of Monetdb (Remote Table)
Hi All,
I am new to MonetDB and this is my first email to this group.
I came across the option --in-memory for mserver5. I understood that if
this option is set, then MonetDB operates out of memory and data is not
persisted.
I wanted to know more details about the working of MonetDB if this option
is set:
1. If this option is set, what is the maximum data size that MonetDB can
operate with?
2. If this option is set, will MonetDB use mmap only for reading purposes
or not use mmap at all?
Any other information is really welcome.
Thanks in advance.
Lakshmi Pathy S N