Closed hk0O7 closed 2 years ago
Could you check what permissions and/or dates your registry.db has?
@Anachron sure:
-rw------- 1 root root 516K May 20 20:54 registry.tdb
This is from before the upgrade - I forgot about its /var/lib/samba directory.
I have now tried to clear it and let smbd
create the files in it again:
-rw------- 1 root root 412K Jul 21 19:14 account_policy.tdb
-rw------- 1 root root 696 Jul 21 19:14 group_mapping.tdb
-rw------- 1 root root 412K Jul 21 19:14 registry.tdb
-rw------- 1 root root 412K Jul 21 19:14 share_info.tdb
But it keeps failling with the same errors as above. Did you get to test this package on armv6l?
Sadly no, I have no such hardware.
Thanks for the detailed description. The issue is reproducible in an armv6l
chroot. Updating to 4.14.6 fixes it for me. PR #32300 submitted, feel free to test.
Samba is a known troublemaker for xbps-src. Building a package on a host that has samba-libs installed (even if a server isn't running!) can sometimes cause library dependencies to leak in, causing the resulting package to be totally broken. This kind of error seems to be symptomatic of these problems.
I'm not convinced the upgrade in #32300 isn't an accidental fix, but it would be good to test and that shouldn't block the update either way.
In the meantime, a couple of questions:
If you do build your own package or are keen to test the update PR, best practice is to stop any samba services, completely uninstall samba and samba-libs (including any dependants necessary to make this possible) before building the package.
Samba is a known troublemaker for xbps-src.
TIL! :astonished: Not sure I wanna know the details of that. The build host should be a container, no?
I'm not convinced the upgrade in #32300 isn't an accidental fix
Well, I am now. :smirk: Just rebuilding 4.14.5 locally also fixes it (cross). Question is now if the build server build will work this time...
I can reproduce with x86_64 btw, built manually on my machine... I'll try a rebuild.
And I do have samba installed on the build machine.
I can confirm this issue is reproducible as well when installing samba-4.14.5_1
from repo on armv6l
I compiled Samba locally (took about 24 hours on 700MHz RPi1!) and the issue is resolved
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
System
Expected behavior
Being able to start
smbd
with the default configuration.Actual behavior
It immediately ends with:
Steps to reproduce the behavior
After this, two (forked?)
smbd
processes for the given command will remain, and thus trying to start it from runit withsv start smbd
will end up filling up the system withsmbd -F -S -d1
processes.This looks like the same issue that was mentioned by wangp and Anachron in #27565 for samba-4.13.2_2.