ok, so no, it should not have any impact - the LDAP in rudder & auth are not the same "ldap" :)
ok; it looks like there is problems with your LDAP directory which are causing the different things you see. Not sure what the root cause is, though. Can you start to 1/ see if there is other error logs in your webapp log file ? and 2/
systemctl restart rudder-slapd ?
6 replies
hellooo, does anyone have this error ?
/opt/rudder/bin/run-inventory --local=/var/rudder/tmp/inventory/beatroot-6d655247-b2ba-419f-b3ec-6c0ea9504c89.ocs
[info] FusionInventory instance: builtin
Encode.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xce00080)ii rudder-agent 7.2.1-debian9 amd64 Configuration management and audit tool - agent
root@dns1:~# rudder agent inventory -i
Rudder agent 7.2.1
Node uuid: b0adee89-7e13-4589-ad25-ab8eeae9ea9b
rudder info: Using command line specified bundlesequence
M| State Technique Component Key Message
E| compliant Common Compute inventory splay Scheduling rudder_run_inventory was correct
rudder info: Executing 'no timeout' ... '/opt/rudder/bin/rudder-client -e /uuid -- --output "/var/rudder/cfengine-community/rudder-server-uuid.txt"'
rudder info: Completed execution of '/opt/rudder/bin/rudder-client -e /uuid -- --output "/var/rudder/cfengine-community/rudder-server-uuid.txt"'
rudder info: Executing 'no timeout' ... '/opt/rudder/bin/run-inventory --local=/var/rudder/tmp/inventory/dns1-b0adee89-7e13-4589-ad25-ab8eeae9ea9b.ocs'
notice: Q: "...-inventory --lo": [info] FusionInventory instance: builtin
Q: "...-inventory --lo": [info] running task Inventory
Q: "...-inventory --lo": [info] Inventory saved in /var/rudder/tmp/inventory/dns1-b0adee89-7e13-4589-ad25-ab8eeae9ea9b.ocs
rudder info: Last 3 quoted lines were generated by promiser '/opt/rudder/bin/run-inventory --local=/var/rudder/tmp/inventory/dns1-b0adee89-7e13-4589-ad25-ab8eeae9ea9b.ocs'
rudder info: Completed execution of '/opt/rudder/bin/run-inventory --local=/var/rudder/tmp/inventory/dns1-b0adee89-7e13-4589-ad25-ab8eeae9ea9b.ocs'
info Inventory Inventory Running inventory
Inventory ERROR: No RUDDER/HOSTNAME or OPERATINGSYSTEM/FQDN, set a hostname other than 'localhost' and add its name in /etc/hosts
E| error Inventory Inventory Generated inventory has been detected as invalid cat /etc/hosts
127.0.0.1 hostme-dns1 localhost
(it's approximately what is used by the inventory process)
hostname --fqdn
hostname: Name or service not known
ok let's go
And it appear there is no table named "rudder"
Maybe the right name is ruddersysevents ?
```
udder=# \dt
Liste des relations
Schéma | Nom | Type | Propriétaire
--------+----------------------------+-------+--------------
public | archivednodecompliance | table | rudder
public | archivednodeconfigurations | table | rudder
public | archivedruddersysevents | table | rudder
public | campaignevents | table | rudder
public | changerequest | table | rudder
public | eventlog | table | rudder
public | gitcommit | table | rudder
public | migrationeventlog | table | rudder
public | nodecompliance | table | rudder
public | nodecompliancelevels | table | rudder
public | nodeconfigurations | table | rudder
public | nodes_info | table | rudder
public | reportsexecution | table | rudder
public | rudderproperties | table | rudder
public | ruddersysevents | table | rudder
public | statusupdate | table | rudder
public | workflow | table | rudderrudder=# select relname, pg_size_pretty(pg_total_relation_size(relname::regclass)) as full_size, pg_size_pretty(pg_relation_size(relname::regclass)) as table_size, pg_size_pretty(pg_total_relation_size(relname::regclass) - pg_relation_size(relname::regclass)) as index_size from pg_stat_user_tables order by pg_total_relation_size(relname::regclass) desc limit 10;
relname | full_size | table_size | index_size
----------------------+-----------+------------+------------
ruddersysevents | 12 GB | 9525 MB | 2734 MB
nodecompliancelevels | 1873 MB | 1000 MB | 873 MB
reportsexecution | 120 MB | 51 MB | 69 MB
eventlog | 53 MB | 32 MB | 21 MB
nodeconfigurations | 19 MB | 864 kB | 18 MB
gitcommit | 952 kB | 496 kB | 456 kB
nodes_info | 640 kB | 544 kB | 96 kB
rudderproperties | 64 kB | 8192 bytes | 56 kB
statusupdate | 64 kB | 8192 bytes | 56 kB
nodecompliance | 40 kB | 0 bytes | 40 kB
We suppose it's ruddersysevents since it's the biggest one
@astropat73_gitlab: ok, so likely, what is happening:
- for some reason, the performance of your LDAP server are degraded. So typically, when it tries to "delete" a node, what happens is - don't forget that by default, nodes are moved to "deleted" branch, not really erase -: start of deletion process, node entries are moved to deleted branchs ; that stalls; the next node deletion tasks are started, like changing the node certificate status - but the node entry is not yet commited ; that fails.
What you can do: - change the property "rudder.nodes.delete.defaultMode" to "erase" so that nodes are really deleted ;
- try to understand why that LDAP is so slow. There is no standard process for that unfortunatly
9 replies
to fix the doc ?
@ellenui_twitter: yes.
We identified a pb with a new feature that cause bad postgresql performances. The request
A first workaround seems to be adding an index, and we are looking for a definitive solution:
We identified a pb with a new feature that cause bad postgresql performances. The request
select id, executiondate, ruleid, directiveid, nodeid, reportid, component, keyvalue, executiontimestamp, eventtype, msg from ruddersysevents where 1=1 and id >= '0' and (eventtype='report_json') order by id asc limit 1000;.A first workaround seems to be adding an index, and we are looking for a definitive solution:
"event_report_json_idx" btree (id) WHERE eventtype = 'report_json'::text
as always ^ ^
Cause we get almost 1Go/s Read on our rudder XD
thanks VSAN
hello @sr57 , I'm not sure I understand. You have two directives derived from the same "file content" technique, and you would like to ? Move a definition block for check on file from one directive to the other ?