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?
Hi,
We encounter a bug with remote tables as part of transactions:
sql>CREATE REMOTE TABLE rmt_tbl (id int, name varchar(20)) ON ‘mapi:monetdb://remote.host.url:50000/dbname/scm1/l_tbl <monetdb://remote.host.url:50000/dbname/scm1/l_tbl>’;
operation successful
sql>BEGIN TRANSACTION;
auto commit mode: off
sql>DROP TABLE rmt_tbl;
operation successful
sql>ROLLBACK;
auto commit mode: on
sql>DROP TABLE if exists rmt_tbl;
no such table: ‘sys.rmt_tbl’
sql>
It seems that after rollback the table exists in the catalogue but it does not actually exists so that drop table fails even if we have ‘if exists’
This happens only with remote tables.
Best,
Yannis
Hi,
I would appreciate some help interpreting the following memory-related
issues.
I've got a mserver5 instance running with cgroups v1 constraints
- memory.limit_in_bytes = 17179869184 (16g)
- memory.memsw.limit_in_bytes = 9223372036854771712
gdk_mem_maxsize is initialised as 0.815 * 17179869184 = 14001593384.
So I get:
sql>select * from env() where name in ('gdk_mem_maxsize', 'gdk_vm_maxsize');
+-----------------+---------------+
| name | value |
+=================+===============+
| gdk_vm_maxsize | 4398046511104 |
| gdk_mem_maxsize | 14001593384 |
+-----------------+---------------+
That looks good.
To my surprise, this instance gets frequently OOM-killed for reaching 16g
of RSS (no swap used):
memory: usage 16777216kB, limit 16777216kB, failcnt 244063804
memory+swap: usage 16777964kB, limit 9007199254740988kB, failcnt 0
kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Memory cgroup out of memory: Kill process 975803 (mserver5) score 1003 or
sacrifice child
Now, there are two different aspects: giving a process a memory cap and
making the process respect that cap without getting killed.
- if the process allocates more than defined with cgroups, then it gets
killed. That is fine, it doesn't surprise me
- the question is: why did monetDB surpass the 16g limit?
Even more surprising, given that it "prudently" initialises itself at 80%
of the available memory.
Perhaps I was under the wrong assumption that MonetDB would never allocate
more than gdk_mem_maxsize, but now I seem to realise that it simply uses
this value to optimise its memory management (e.g. to decide how early to
mmap).
So, am I correct that setting gdk_mem_maxsize (indirectly via gcroups or
directly via memmaxsize parameter) does not guarantee rss memory will stay
underthat value?
If that is true, I am back at square 1 in my quest for how to cap rss usage
(without getting the process killed).
Thanks for your help.
Roberto
Hi,
I am trying to understand the error messages and codes reported by MonetDB,
to be able to better handle error reporting, monitoring and logging.
What I understand so far about the structure of an error message,
it starts with error code placed between '!' and after the error message,
for ex: !42000! SELECT: identifier 'xyz' unknown. and sometimes a part of
the query is included.
I found the list of ODBCError in "clients/odbc/driver/ODBCError.c" file,
but I am not sure if this is the complete list and if it's aligned with the
error codes reported by MonetDB.
Is there any standard for the message error structure and where can I find
the list of errors with their descriptions?
Thanks.