Thanks for looking into this. This definitely sounds like an upstream problem, so please contact them about it.

I sent upstream a pointer to this report and asked Thorsten whether he could move the sd_notify() to the place where the ypserver binds for the first time.

I got the scoop from upstream. He says that RedHat and OpenSUSE use an ExecStartPost in their .service files to delay dependent units like autofs from starting until a bind has been performed. He also said that the nm dbus thing was a bad idea in the first place. With that, I think that the attached .service file will do the trick to resolve this problem.

Well, let me test it thouroughly first. Back in a moment...

The attached service file works nicely.

I think you have a strange definition of "nicely". Your single line of /bin/sh isn't even /bin/sh compatible.

Please just fix sd_notify support in ypbind and offer it upstream. It's trivial to do.

Works on Arch Linux's /bin/sh.

If you prefer:

ExecStartPost=/bin/sh -c "while ! /usr/bin/ypwhich; do sleep 1; done"

Because Arch's /bin/sh is a symlink to bash. It should not work.

"If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well."

That it does work is, frankly, a bug in bash.

$ dash -c 'for ((i=0; i<5; i++)); do echo $i; done'
dash: 1: Syntax error: Bad for loop variable

You would be better off invoking bash if you're going to use bash syntax. Better yet, just fix the problem at the source rather than hacking around it.

The problem isn't at the source:

sd_notify(3): READY=1 tells the init system that daemon startup is finished. This is only used by systemd if the service definition has Type=notify set.

systemd.service(5): Behavior of notify is similar to simple, however, it is expected that the daemon sends a notification message via sd_notify(3) or an equivalent call when it finished starting up. (Note this is non-forking.)

ypbind(8): -debug: starts ypbind in debug mode. ypbind will not put itself into the background, and error messages and debug output are written to standard error.

So, unless you want your logs/journal filled with ypbind debugging messages, it is necessary to set Type=forking.

systemd.service(5): If set to forking it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels set up.

That is what ypbind does, forks() and main exits once the communications channels have started up. It also calls sd_notify(3) so that you can run it with Type=notify in debug mode under systemd.

So it seems upstream ypbind is behaving quite properly.

So unless we at least put ExecStartPost=/usr/bin/sleep 5, logins and autofs mounts will proceed and fail routinely on boot.

The old rc.d files used to query with ypwhich and loop sleeping a second (displaying a '.' or a count). Debian still does this (dash compatible):

log_action_begin_msg "binding to YP server"
for i in 1 2 3 4 5 6 7 8 9 10
do
sleep 1
log_action_cont_msg "."
if [ "`ypwhich 2>/dev/null`" != "" ]
then
echo -n " done] "
bound="yes"
break
fi
done

ExecStartPost= is precisely the replacement for this kind of thing. They obviously don't know about the return code.

ExecStartPost=/bin/sh -c "for i in 1 2 3 4 5; do ! ypwhich >/dev/null || break; sleep 1; done"

Is that better?

> That is what ypbind does, forks() and main exits once the communications channels have started up. It also calls sd_notify(3) so that you can run it with Type=notify in debug mode under systemd.

I'm reading this as:

1) In forking mode: ypbind-mt isn't actually ready to do work when main exits in forking mode. If it was actually ready, the sleep loop wouldn't be required.
2) In notify mode: upstream forces you to run in debug mode, but this works "properly" and doesn't need the sleep loop hack. Forcing debug logging on the user for a more preferable mode of operation under systemd seems like broken behavior.

How is this not an upstream problem?

> Is that better?
Syntactically, sure. 'ypwhich >/dev/null && break' would be a little more readable, but it's still a filthy hack.

No, systemd only wants to know that all sockets (communications channels) are open by the time that sd_notify(3) is sent. In forking it expects that the daemon sets up the sockets, forks and then exits, which is what it does.

The sleep loop has been done in sysvinit ypbind/nis scripts since time immemorial (well, 15 years). I have sysvinit scripts going back to redhat 7.3 that do this. redhat, mageia, mandriva, mandrake, suse, opensuse, fedora, debian, ubuntu, ... everybody but Arch.

I attach the ypbind initscript from RedHat 7.3 from Aug 13, 2001, current debian squeeze, and fedora 18's *.service file and supporting script. See?

> The sleep loop has been done in sysvinit ypbind/nis scripts since time immemorial (well, 15 years). I have sysvinit scripts going back to redhat 7.3 that do this. redhat, mageia, mandriva, mandrake, suse, opensuse, fedora, debian, ubuntu, ... everybody but Arch.
You're completely missing/ignoring my point. *WHY* is this needed? You claim the daemon behaves properly -- it signals to systemd (either by sd_notify or by main exiting) that it's setup all its sockets and is ready to handle requests. Why then do you need to wait even further before it's capable of handling requests?

Because follow-on units cannot start until a bind has been acheived. It is not the daemon's responsibility to determine what follow-on units can or cannot start, there are quite a few NIS maps that can be used for various purposes. It depends on how nssswitch, libc, nscd and others are set up as to what might depend on a bind, or not. Name service cacheing can be set up to serve the last cached maps, just not usually.

It has always been the init system's responsibility to determine the dependencies between services. If there is a bug in upstream, its systemd not ypbind. It has facilities for major subsystems but seems to have forgotten about name services.

The .service file in ypbind package is working quite nicely for quite a while now. Can we close this report?