similar to: Garbage collection of tombstones is failing due to missing objects

On Mon, 8 Apr 2019 22:32:04 +0100 miguel medalha via samba <samba at lists.samba.org> wrote: > On a particular DC, running 'samba-tool dbcheck' produces the > following: > >     NOTICE: found 2 expired tombstones, 'samba' will remove them > daily, 'samba-tool domain tombstones expunge' would do that > immediately. > > When I run

>> Did you think to run 'samba-tool domain tombstones expunge --help' ? No, I didn't, I just assumed that the message "'samba' will remove them daily, 'samba-tool domain tombstones expunge' would do that immediately" would mean exactly that :-). It worked now. Thank you!

On a particular DC, running 'samba-tool dbcheck' produces the following:     NOTICE: found 2 expired tombstones, 'samba' will remove them daily, 'samba-tool domain tombstones expunge' would do that immediately. When I run 'samba-tool domain tombstones expunge' the following is produced:     Removed 0 objects and 0 links successfully Running 'samba-tool

On Wed, 26 Oct 2016 11:41:23 -0400 lingpanda101 via samba <samba at lists.samba.org> wrote: > Hello, > > I receive the following when I attempt to expunge deleted tombstone > records. I'm attempting to fix several dbcheck 'Not removing dangling > forward link' errors. > > samba-tool domain tombstones expunge > ERROR(<type

On Wed, 26 Oct 2016 12:47:16 -0400 lingpanda101 via samba <samba at lists.samba.org> wrote: > On 10/26/2016 12:11 PM, Rowland Penny via samba wrote: > > On Wed, 26 Oct 2016 11:41:23 -0400 > > lingpanda101 via samba <samba at lists.samba.org> wrote: > > > >> Hello, > >> > >> I receive the following when I attempt to expunge deleted

Hello, I receive the following when I attempt to expunge deleted tombstone records. I'm attempting to fix several dbcheck 'Not removing dangling forward link' errors. samba-tool domain tombstones expunge ERROR(<type 'exceptions.AttributeError'>): uncaught exception - 'module' object has no attribute 'time' File

On 10/26/2016 12:11 PM, Rowland Penny via samba wrote: > On Wed, 26 Oct 2016 11:41:23 -0400 > lingpanda101 via samba <samba at lists.samba.org> wrote: > >> Hello, >> >> I receive the following when I attempt to expunge deleted tombstone >> records. I'm attempting to fix several dbcheck 'Not removing dangling >> forward link' errors. >>

This is almost certainly because of a build artifact. python/samba/netcmd/time.py was renamed to nettime.py but there is likely to be a time.pyc file floating around in your directories. The reason it was renamed was so that the samba tool time command wasn't confused with the python time module, but this necessarily causes issues with existing installs unfortunately. The fix is mostly

Dear list, Does anybody know how to lower the tombstone lifetime in samba 4.5 or later? There used to be a wiki entry, but this has been deleted as it is probably not adequate anymore: https://wiki.samba.org/index.php/Restoring_deleted_AD_objects#Changing_the_defaults_for_msDS-deletedObjectLifetime_and_tombstoneLifetime I used to change the attribute tombstoneLifetime in CN=Directory

Hi all, Seems we're in much more trouble now... Yesterday I lowered the dn stombstone lifetime from 180 to 60, to reduce the size of DC=DomainDnsZones, and ever since, things have become terrible... The situation now: I have separate fileserver, and three DC3's, all on the same subnet, kvm virtual machines, all running sernet-samba. (4.1.7 and 4.1.9) == on DC3 == DNS queries for my

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

>Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: > >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song < maskray at google.com > wrote: >> >> Thanks for the write-up! >> >> On 2020-07-16, David Blaikie wrote: >> >In short: Perhaps we should switch lld to the bfd-style tombstoning >> >behavior for a release or

>On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> > >> >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >>

Hi All, In general I think we should adopt Dave's plan here. The number of consumers that can (and have) been caught off guard by this change is just too high. At the very least I think we should move this to opt in to the new tombstoning behavior by default and at most migrate to bfd's behavior for both the current release and in the current tree. If we want to make this sort of change

On 2020-07-24, Hans Wennborg via llvm-dev wrote: >Sounds good to me from a release perspective. I think we need more input from the triage of https://chromium-review.googlesource.com/c/chromium/src/+/2291352 whether it is just .debug_line or .debug_* >On Fri, Jul 24, 2020 at 7:53 AM Eric Christopher via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hi All,

>On Mon, Jul 20, 2020 at 10:32 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> >> > >> >> >On Fri, Jul 17, 2020 at

On Wed, Aug 5, 2020 at 12:50 PM Fāng-ruì Sòng <maskray at google.com> wrote: > On Wed, Aug 5, 2020 at 12:32 PM Eric Christopher <echristo at gmail.com> > wrote: > > > > Honestly even though I do understand the debug information I'm with you > and one reason why I'm pushing for the same reset that you are. There are a > lot of threads, it's fairly

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b).

> I still think that we do bfd locs with a decent option to change for at least the current release and sources and then, once we're a little more certain we have everything that might want to parse dwarf (say by working with dwarf-discuss), we can change the default. Given what’s been found, I think Eric/Dave are correct, use bfd behavior by default with an option to do the new thing.

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote: