wsdd.service shouldn't pull in samba.service

[jonesmz]

See log output from samba:

[2022/01/26 00:39:46,  0] ../../source4/samba/server.c:874(binary_smbd_main)
  At this time the 'samba' binary should only be used for either:
  'server role = active directory domain controller' or to access the ntvfs file server with 'server services = +smb' or the rpc proxy with 'dcerpc endpoint servers = remote'
  You should start smbd/nmbd/winbindd instead for domain member and standalone file server tasks
[2022/01/26 00:39:46,  0] ../../lib/util/become_daemon.c:121(exit_daemon)

In a samba4 environment, using the "samba" binary to run a file server is discouraged, and instead users should use the smbd.service instead.

The systemd unit file has

; It makes sense to have Samba running when wsdd starts, but is not required
Wants=samba.service

I think there's a way to make a service depend on "one out of two" services, so that if smbd is enabled, that prevents it from trying to pull in samba.service as well.

But I'd be just as satisfied with the Wants=samba.service line omitted.

[JedMeister]

(FWIW I have no official affiliation with this software - just throwing my 2c in the ring...)

Where are you getting your wsdd.service file from? The default service file in this repo doesn't have the lines you note. It currently has (lines 6 & 7):

; It makes sense to have Samba running when wsdd starts, but is not required
;Wants=smb.service

So it (soft) depends on smb.service (not samba.service) and is commented out by default anyway?!

---

Regardless, that Samba log output you show is only info, so it shouldn't really be an issue. Wants= is a soft dependency so that should be ok. Although (as you note) probably it would be better to soft depend on either samba.service or smbd.service. I had a bit of a read of the systemd docs and I couldn't find any mention of how to depend on one service OR another service!? I also found an unanswered, 3 year old nix stack exchange question. Having said that, it could soft depend on both, i.e.:

; It makes sense to have Samba running when wsdd starts, but is not required
Wants=samba.service
Wants=smbd.service

Obviously that wouldn't solve your desire to have clean logs and would in fact probably make it worse, but it would allow it to (soft) depend on either samba.service or smbd.service.

In your case, to remove that Wants=samba.service on your system (without changing the default service file - which should be /lib/systemd/system/wsdd.service) you could just create an overlay. First create the required dir (sudo mkdir -p /etc/systemd/system/wsdd.service.d), then (assuming you want to keep the Wants=network-online.target) in a file named /etc/systemd/system/wsdd.service.d/override.conf, put:

[Unit]
; blank 'Wants=' clears all current settings
Wants=
Wants=network-online.target

[jonesmz]

Ahh, i found the culprit: https://github.com/christgau/wsdd-gentoo/blob/1156bfeeee76150f811af9d8049d0edfb4277851/net-misc/wsdd/wsdd-0.7.0.ebuild#L30

The .service file is being modified on install by the installation script for Gentoo if the "samba" flag is active.

That flag's active for all packages, since the machine in question is a samba host.

The meaning of the flag is... not accurate, though.

• • samba : Add support for SAMBA (Windows File and Printer sharing)

Which is what I wanted, but not what I got :-P

I had a bit of a read of the systemd docs and I couldn't find any mention of how to depend on one service OR another service!?

I think a common way of doing this is to have a "target" that can be pulled in, and whatever services have been set for that target get activated in a system specific configuration.

Sounds like it's not as possible as I assumed. Bummer.

[jonesmz]

Since really this issue is for the wsdd-gentoo repository, can the issue be moved? I'm not actually sure if that's possible to do in github ?

[jonesmz]

Honestly, I kind of feel like the Wants line should be removed from wsdd entirely.

Obviously most of the users of wsdd would want smbd running. But not necessarily all of them. And those users would have already enabled the smbd service without regards to wsdd (I think)

[christgau]

The systemd unit file has

; It makes sense to have Samba running when wsdd starts, but is not required
Wants=samba.service

As you and @JedMeister already pointed out that this is actually not in this repo but rather a consequence of what the Gentoo ebuilds from christgau/wsdd-gentoo are doing. And further: the files under /etc in this repo are considered examples which might be modified for other distros (as the ebuilds do).

Since really this issue is for the wsdd-gentoo repository, can the issue be moved? I'm not actually sure if that's possible to do in github ?

You're right from the point of view that the actual issue you are facing comes from wsdd-gentoo, however other distros might be affected as well. Thus, I'd like to keep the discussion here. Nevertheless, moving issues between repos is possible on Github.

But I'd be just as satisfied with the Wants=samba.service line omitted.

I do not really understand why you want that line to be removed. Is it because it references the wrong service and you get according messages in your system log? In that case wouldn't it be better to "Want" another/a better unit? Or do you want that line to be remove because you don't want wsdd to pull any samba-related service?

Meanwhile, I digged a little through the systemd docs as well and it appears that Wants might not have been a wise choice when the systemd unit file was written. BindsTo looks like a more appropriate solution. Thus wsdd would terminate/start when Samba shuts down/starts as well. This also what @votdev did for OMV. If we go for BindsTo in the example (yet it will still be commented out) and the Gentoo ebuilds the question still remains which Samba unit would be the best. Looking again at what @votdev did for OMV, he choose smbd.service.

Would that (BindsTo=smbd.service) solve the issue for your case?

The meaning of the flag is... not accurate, though.

• • samba : Add support for SAMBA (Windows File and Printer sharing)

Which is what I wanted, but not what I got :-P

I just want to understand your comment. Therefore allow me to ask, in what sense you did not get what you want? Would you suggest to remove the samba use flag from the Gentoo ebuilds?

[jonesmz]

But I'd be just as satisfied with the Wants=samba.service line omitted.

I do not really understand why you want that line to be removed. Is it because it references the wrong service and you get according messages in your system log? In that case wouldn't it be better to "Want" another/a better unit? Or do you want that line to be remove because you don't want wsdd to pull any samba-related service?

Yes, generally speaking.

But also because running wsdd doesn't imply that smbd should also be running, even though most of the time it should be, nor vice versa. If it weren't for the annoying logs from the samba binary running instead of smbd, then I wouldn't have even noticed, since I enable or disable wsdd based on the machine's purpose, but once i noticed the behavior of pulling in samba instead of smbd, i thought about it more.

On the balance my preference really is:

1. wsdd does not attempt to activate samba.service, only smbd.service.
2. If I had to pick between "Attempt to activate both samba.service and smbd.service" or "don't attempt to activate any services" then I would pick "don't attempt to active any services", because I manage which machines have wsdd enabled manually anyway.

Would that (BindsTo=smbd.service) solve the issue for your case?

Yes, I believe that would work nicely.

The trick with BindsTo is that you still have to enable / disable the .service file, simply having it on your filesystem doesn't automatically enable the auto-start behavior. Which is what I would appreciate.

But it allows you to have BindsTo=samba.service and also BindsTo=smbd.service.

Since samba is configured such that only one of smbd.service or samba.service can be activated at a time, wsdd can be "automatically" started for either of them, while also being controllable by the admin of the machine.

I just want to understand your comment. Therefore allow me to ask, in what sense you did not get what you want? Would you suggest to remove the samba use flag from the Gentoo ebuilds?

The samba use flag in this case is being enabled globally on the machine in question, because I want the applications installed to speak and understand the smb protocol so i can interact with my file server.

While it's not necessarily the case that global use flags always work exactly how they're expected, a plain text reading here is about the file and print components of the samba package. As far as I understand it, the "samba.service" component is exclusively for domain controllers (which, I suppose, can also run the file and print components, but it's heavily discouraged), and the "smbd.service" retains the responsibility for file and print services.

So I wasn't expecting to see the ebuild make the switch from smbd.service to samba.service based on the "samba" use flag.

Being unfamiliar with wsdd when i originally installed it, i had assumed that wsdd could be usable for more than just samba related stuff, so i left the samba flag on it thinking that it enabled some specific protocol field to advertise the machine on the "network" browser in windows in addition to whatever else wsdd would also do.

As an end user, I my suggestion is that the wsdd.service file remove the "Wants=" line entirely, add "BindsTo=" for both smbd.service and samba.service (so that if either starts, wsdd will start, if enabled), and removes the "samba" use-flag from the ebuild entirely, since I think the change to the .service file will make it obsolete.

As a partially related "drive by" suggestion, which has not been carefully considered and might be invalid: Does it make sense to have a "wsdd.socket" unit file? With broadcast packets being involved, potentially that's not possible, but I do enjoy using .socket files when possible. Keeps seldom used services from cluttering up the process list.

[christgau]

As an end user, I my suggestion is that the wsdd.service file remove the "Wants=" line entirely, add "BindsTo=" for both smbd.service and samba.service (so that if either starts, wsdd will start, if enabled),

Great. Sounds good to me.

I've changed the example unit file in this repo, but kept the the BindsTo directives as comments. Although one could uncomment them, it looks cleaner to me to only enable them if really needed.

and removes the "samba" use-flag from the ebuild entirely, since I think the change to the .service file will make it obsolete.

For the same reason as above, I kept the use flag and the ebuild now enables the BindsTo directives if it is set.

I suppose the issue can be closed...

[christgau]

As a partially related "drive by" suggestion, which has not been carefully considered and might be invalid: Does it make sense to have a "wsdd.socket" unit file? With broadcast packets being involved, potentially that's not possible, but I do enjoy using .socket files when possible. Keeps seldom used services from cluttering up the process list.

Just to make a comment on this: To me it appears that there some reasons against this.

1. Multicast sockets are used and it looks as if systemd does not support them.
2. Even if it would support multicast sockets some things from the wsdd configuration must be replicated for the systemd, e.g. binding to the intended network interfaces. This would make things unhandy.
3. Even if multicast sockets were supported, wsdd needs to be modified to have either an inetd-like interface or tightly coupled with systemd. I'd like to avoid both approaches and keep wsdd to be usable as standalone application without additional (optional) dependencies
4. Upon startup wsdd announces the host to the network according to the WSD protocol. Using a socket activation would start wsdd "too" late and will start it only if the network is searched for network hosts (using multicast).