similar to: kcc_periodic output

hi, *EDIT*: Every 2 hours kcc_periodic.c is executed The error occurs on all 4 of my DCs: [2024/01/19 14:02:05.917120, 0] source4/dsdb/kcc/kcc_periodic.c:790(samba_kcc_done) source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT Today I enabled logging at level 5 and monitored DC1. There was no error, on the contrary, kcc_periodic.c ran correctly and the message was Ok.

hi, After an update to our DC4, I started to notice the error "Failed to store repsFrom - Indexed and full searches both failed!" in the logs. root at dc4:~# tail -f /var/log/samba/log.samba Copyright Andrew Tridgell and the Samba Team 1992-2023 [2023/12/05 14:09:06.191978, 0] ../../lib/util/become_daemon.c:150(daemon_status) daemon_status: daemon 'samba' : Starting

The two systems I'm referring to are on different domains, different locations. No connection whatsoever except me being the one administering both. According to oEMInformation the server was provisioned by 4.3.3. I just checked the Samba log file and it seems that version 4.7.4 was running before the update. I'm now looking at the logs right before the upgrade and indeed, there have

Hi samba list!!! Douglas, /usr/sbin/samba_kcc is made in python. Does it have a link to source4/dsdb/kcc/kcc_periodic.c which is made in C? The errors that appear in my DCs have their output in the C code. Correct me if I'm wrong, but I read in some old posts on the list that samba would have a new code for kcc (python code?), which would be closer to what M$ uses. Could this have anything

Any thoughts? :D On Tue, Dec 5, 2023 at 4:59?PM Elias Pereira <empbilly at gmail.com> wrote: > hi, > > After an update to our DC4, I started to notice the error "Failed to store > repsFrom - Indexed and full searches both failed!" in the logs. > > root at dc4:~# tail -f /var/log/samba/log.samba > Copyright Andrew Tridgell and the Samba Team 1992-2023 >

hi, The error is consistently occurring across all four of my DCs. [2024/01/19 14:02:05.917120, 0] source4/dsdb/kcc/kcc_periodic.c:790(samba_kcc_done) source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT I configured logging to level 5 and observed DC1. No errors were detected; instead, kcc_periodic.c executed smoothly, and the system reported a successful outcome.

"Indexed and full searches both failed" is not a good sign. Failed in this case doesn't just mean 'returned no results', it means 'database error'. It could be on any record, as the filtering for a full search has to happen across the whole DB and if any of those filter tests fail, it will do this. I think you have another working DC, if so I would demote this

I've been grappling with a recurring set of errors for quite some time now: - UpdateRefs failed with NT_STATUS_IO_TIMEOUT - Failed samba_kcc - NT_STATUS_IO_TIMEOUT - IRPC callback failed for DsReplicaSync - NT_STATUS_IO_TIMEOUT Despite cranking up the log level to 10, the returned information remains frustratingly cryptic and hard to decipher. This error, being overly generic, continues to

> > There is probably nothing wrong with your log, but Firefox doesn't > like it, it thinks it contains a virus. I just saw now that your response ended up in spam, probably because of the link with the log. O.o I still receive the error in the logs: source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT The strangest thing is that it occurs when the command

Either the local server is busy, or possibly (but it would not explain the samba_kcc) Samba's drepl process is stuck talking to a remote server. Is the drepl local processes very busy doing inbound replication? My instinct is either the server is very busy (and this should show up in CPU use) or a transaction is being held open excessively. Andrew Bartlett On Sat, 2024-03-09 at 19:11 -0300,

> > Is the drepl local processes very busy doing inbound replication? How can I check this? My instinct is either the server is very busy (and this should show up in > CPU use) or a transaction is being held open excessively. I use VMs on Proxmox. In DC1, I installed the Proxmox agent, and CPU usage via the dashboard is very low. However, when I checked using 'top,' the LDAP

Hello Andrew, 1. What is the explanation for the fact that when the log level is set to 5 or 7, the NT_STATUS_IO_TIMEOUT error does not appear, but when it is at the default log level, it does? Another point I've noticed before is that when I run the command "samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix --yes" (*Checked 15337 objects (0 errors)*), and in another

On Thu, 2024-04-11 at 14:21 -0300, Elias Pereira wrote: > Hello?Andrew, > > 1. What is the explanation for the fact that when the log level is > set to 5 or 7, the NT_STATUS_IO_TIMEOUT error does not appear, but > when it is at the default log level, it does? I don't have an explanation for this, sorry. ?Have you looked into the 1.5 second queries, what is sending them and

1.5 seconds is pretty long, I would look into what those queries are. I would also look into repeated queries, sometimes these things are clients stuck in a loop where they don't complete because they expect some termination condition. Andrew Bartlett On Tue, 2024-04-02 at 09:25 -0300, Elias Pereira via samba wrote: > The saga continues... > I've spent a whole day with log level 5

Thanks for getting back to me. It seems to me the LDAP process being busy would be the root cause here. Working out what is going on here shouldn't is a detective task - I always start with a wireshark trace. The client making all the noise/traffic will be the one causing the trouble. If it isn't clear from that, then look into the DB audit logging for perhaps busy writes

I was too quick to send my previous email. It can't really be a problem of the package since I have, as mentioned, another system with the exact same setup and the exact same package versions and it all works there... On Sun, 23 Dec 2018 at 11:18, Viktor Trojanovic <viktor at troja.ch> wrote: > Yes, I tried running dbcheck (see first email), it showed 0 errors from > the start, I

hi Andrew, thanks for the help!!! It seems to me the LDAP process being busy would be the root cause here. > Working out what is going on here shouldn't is a detective task - I always > start with a wireshark trace. The client making all the noise/traffic will > be the one causing the trouble. In the wireshark analysis, should I filter only by the ldap protocol or leave

Hello Andrew, What's the explanation for when the log level is set to 5, the error NT_STATUS_IO_TIMEOUT doesn't appear, but when it's at the default log level, it does? On Mon, Mar 18, 2024 at 10:33?AM Elias Pereira <empbilly at gmail.com> wrote: > hi Andrew, thanks for the help!!! > > It seems to me the LDAP process being busy would be the root cause here. >>

On 9/18/2016 6:23 PM, Garming Sam wrote: > Hi, > > For the unsorted attributeID values errors, can you first try: > > samba-tool dbcheck --cross-ncs --fix --yes 'fix_replmetadata_unsorted_attid' > > There's too much going on, and it does look like it might be bailing > out. Running it with 'fix_replmetadata_unsorted_attid' should fix those > first

The saga continues... I've spent a whole day with log level 5 and 7 and no error. All I have to do is return the log to the default and the error reappears. I monitored the "LDAP Query: Duration", but I didn't notice any crashes in the queries. I don't know if it's a long time, but some queries took 1.5s. Is there anything else I can do? On Mon, Mar 25, 2024 at