void-linux / void-packages

The Void source packages collection
https://voidlinux.org
Other
2.59k stars 2.16k forks source link

[samba-4.14.5_1] [armv6l] smbd failing to start #32079

Closed hk0O7 closed 2 years ago

hk0O7 commented 3 years ago

System

Expected behavior

Being able to start smbd with the default configuration.

Actual behavior

It immediately ends with:

exit_daemon: daemon failed to start: Samba cannot setup ep pipe, error code 13

Steps to reproduce the behavior

# xbps-install -Suy samba
# smbd -FS -d 10 --no-process-group
    ...
    regdb_open: registry db opened. refcount reset (1)
    make_internal_ncacn_conn: Create pipe requested winreg
    Created internal pipe winreg
    svcctl_init_winreg: Could not open SYSTEM\CurrentControlSet\Services - NT_STATUS_INVALID_HANDLE
    regdb_close: decrementing refcount (1->0)
    dcesrv_init_ep_server: Failed to init endpoint server 'svcctl': NT_STATUS_UNSUCCESSFUL
    dcesrv_init: Failed to init DCE/RPC endpoint servers: NT_STATUS_UNSUCCESSFUL
    main: Failed to setup RPC server: NT_STATUS_UNSUCCESSFUL
    exit_daemon: daemon failed to start: Samba cannot setup ep pipe, error code 13

After this, two (forked?) smbd processes for the given command will remain, and thus trying to start it from runit with sv start smbd will end up filling up the system with smbd -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.

Anachron commented 3 years ago

Could you check what permissions and/or dates your registry.db has?

hk0O7 commented 3 years ago

@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?

Anachron commented 3 years ago

Sadly no, I have no such hardware.

mvf commented 3 years ago

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.

ahesford commented 3 years ago

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:

  1. Is your samba package locally built?
  2. If so, is the package natively built or cross-compiled?

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.

mvf commented 3 years ago

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...

fosslinux commented 3 years ago

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.

KeepBotting commented 3 years ago

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

github-actions[bot] commented 2 years ago

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.