Can you please be more specific what the issue is?

All daemons log to stderr on startup till the log file has been set up. If we don't do that we would not see errors which happen before we can write to the logfile.

if you have a classic init script, that starts smbd/winbindd, you will get more or less log output on the console (with high log level it will be annoyingly much actually).

If you use systemd only you might not notice that because it suppresses any output. The previous behaviour was that the default -D start option will not output anything and we should keep that behaviour. Init scripts will otherwise have to redirect stdout/sterr to /dev/null, which will not be helpful either.

If you want to output something in case the log file is not writable, then the setting up of the logging should be done before something is printed to stdour/stderr. And then only print to stdout/stderr if the logging can't be set up for some reason.

Currently, this is a showstopper for Samba 4.15.0 scheduled for September 1st.

I tried it and agree that it might be annoying. On the other hand, it's working and seems to be difficult to setup logging earlier. So, is this a change we can agree on for a major release?

I don't think this is a severe regression that requieres delaying the release.

When we initialize everything, we start logging to stderr so we do not miss errors. If you set debug level to 10 you will get debug messeage from debug setup, config loading and cmdline parsing to stderr.

This all happens before you actually know that you want to run in daemon mode. We set the logging to a file as soon as the cmdline options have been parsed.

If you don't want to see what is going on before file logging is initialized.

It shouldn't be hard to change a n init script to send stderr to /dev/null if you don't want to see it.

IMHO it would be nice if it could be changed the way it was working before but if it is not easy to change, then we should add the new behaviour and the recommendation to redirect stderr/stdout to /dev/null for init scripts into the release notes.

The output of "systemctl status smbd" might also be different now, especially with higher log levels, I wasn't able to verify that systemd case yet though.

(In reply to Andreas Schneider from comment #5)
Afair file logging is somehow setup to use the process name, at least for the deamons. That's why this worked in 4.14 where in main.c the order of actions is:

1) parse cmdline with popt

2) setup logging to FILE backend unless stdout was requested on the cmdline

3) parse smb.conf

Now in 4.14, as smb.conf parsing was moved to the popt callback at step 1, we get the behaviour change.

https://git.samba.org/?p=slow/samba.git;a=commit;h=933d0e9df181c7c9d511fa00410fe4becdf9da77 is probably a step in the right direction to get the old behaviour back, but I guess it needs further tweaking to affect the daemons, as mentioned in the commit message.

May I propose we just keep this bug open to track the issue and hopefully find a way to restore the old behaviour with a subsequent 4.15.x bugfix release, but otherwise continue with the 4.15 release?

Andreas, can you provide a patch for WHATSNEW.txt? Thanks!

Created attachment 16759 [details]
WHATSNEW update for 4.15

The patch could fix this issue. As logging to stderr is always turned on and there could always be messages on stderr!

A bug could be opened that daemons should start logging to a file before loading the configuration.

Hm, the patch doesn't apply. Can you check? It's also missing your signed-of. Feel free to push with my +1.

(In reply to Ralph Böhme from comment #9)
D'oh! Sorry, too early in the morning... Tried to apply to master and push to autobuild master... Karolin, please apply and push to 4.15. :)

Created attachment 16770 [details]
WHATSNEW for 4.15

This bug was referenced in samba master:

aaa3c6a4132d2e739958e168e7dc3e78dfa4a72e
877183ac0b57f5b2902446e41bb6ab3191f84fa6
ae22442db437061aada6427adde205cd13f1d202
a20f63b384750d389aeafd4bd5e229aed72cb271
9d82454cdfc2b4b8007c7b54b3afd5686f49be19
28686f8713958726085bd38a0889aa7725c95371

Created attachment 16776 [details]
Patch for 4.15 cherry-picked from master

Reassigning to Jule for inclusion in 4.15.

Pushed to autobuild-v4-15-test.

This bug was referenced in samba v4-15-test:

29c895c6d8ab5360f7d6e2e536b7b3ddf9656f3b
476ed842726a77cd16a2dafd4dfbc987a12b6cfe
e1be4413c990f75f7efe9dc2c62a86646f2932d4
3eef217a9daba415774680b4f4c0bf1188909edd
c65fb0b0a0e2867c0656bb5a84606f70d02dbe65
defbbe7127fde7c73485b8dea18eb2543cda7973

Closing out bug report.

Thanks!

This bug was referenced in samba v4-15-stable (Release samba-4.15.0rc5):

29c895c6d8ab5360f7d6e2e536b7b3ddf9656f3b
476ed842726a77cd16a2dafd4dfbc987a12b6cfe
e1be4413c990f75f7efe9dc2c62a86646f2932d4
3eef217a9daba415774680b4f4c0bf1188909edd
c65fb0b0a0e2867c0656bb5a84606f70d02dbe65
defbbe7127fde7c73485b8dea18eb2543cda7973

I just updated samba on my test Gentoo system by using the official 4.15 build (https://gitweb.gentoo.org/repo/gentoo.git/tree/net-fs/samba/samba-4.15.0-r1.ebuild). First thing I noticed was the problem with logging *continuously* going to the console:

# /etc/init.d/samba restart
 * Caching service dependencies ...                                                                                                                                                     [ ok ]
 * samba -> stop: samba4 ...                                                                                                                                                            [ ok ]
 * samba -> start: samba4 ...
samba version 4.15.0 started.
Copyright Andrew Tridgell and the Samba Team 1992-2021                                                                                                                                  [ ok ]
# binary_smbd_main: samba: using 'prefork' process model
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[ad9<...>] name[gnom3]
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[_msdcs.ad9<...>] name[47<...>da]
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[ad9<...>] name[@]
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[_msdcs.ad9<...>] name[@]
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[ad9<...>] name[@]
/usr/sbin/samba_dnsupdate: ERROR: Record already exist; record could not be added. zone[ad9<...>] name[_ldap._tcp]
(...)
dnsupdate_nameupdate_done: Failed DNS update with exit code 29

Note that even 24h later, my console is still being flooded with the dnsupdate messages.

I think the current behavior may not only be non-intuitive but also should be considered a regression. It is also hard to justify why this would be a WAI, if no --foreground / --interactive flags are specified. I don't understand the reason for the change - why this is considered a positive thing and why this was never needed in Samba it its almost 20 years of development, until now?

In my opinion, the common practice in Unix-like systems is for daemons to close (and re-open to /dev/null) stdin/stdout/stderr and then either log to syslog or to specific files. If for some reason logging to files is not possible (it is unclear why however, i.e. we logging cannot be initialized early) I wonder why syslog would not be a better choice that stderr / stdout. I also wonder what would happen if I close the terminal immediately after (re-)starting samba, and then the deamon tries to write something?


Overall, updating "WHATSNEW" does not seem like the proper fix IMO, and the fact that Gentoo has this problem suggest this may be a common trap all non-systemd distributions may be dealing with, one after another.