Use systemd-notify(1) shell helper as fallback

[binarin]

As discussed at the end of #52

Currently external erlang library sd_notify is used to make systemd
unit with Type=notify to work correctly. This library contains some C
code and thus cannot be built into architecture-independent package.

But it is not actually needed, as systemd provides
systemd-notify(1) helper for shell scripts.

The only thing is that you need to add NotifyAccess=all to your unit file to
make everything work well.

[michaelklishin]

Thinking out loud: os:cmd/1 always returns a string, even when execution failed. I couldn't make it throw an exception, so this is hopefully safe.

[michaelklishin]

@binarin your commit message says that

The only thing is that you need to add `NotifyAccess=all` to your unit
file to make everything work well.

should we do it in our own RPM package?

[binarin]

Currently there is no systemd unit files in source tree and so there is no place where this change can be applied.

RedHat maintains their unit file externally, and they will need to make that change there when sd_notify will be completely removed.

And I'll keep an eye on Debian packages and will suggest to switch from rabbitmqctl wait in their unit file. Right after they'll start to package 3.6.1 or some later version.

[michaelklishin]

@binarin someone brought up a few related questions today: should we use --pid to communicate RabbitMQ node PID to systemd? Can it be that os:cmd/1 uses a separate PID? Can we notify systemd when RabbitMQ shuts down?

[michaelklishin]

I see that every os:cmd/1 call starts a separate port/OS process. Try running

os:cmd("sleep 10 &\necho $!").

multiple times in a row.

[michaelklishin]

The comment above means that we can't let systemd-notify use the caller OS process' pid.

[binarin]

I though that systemd-notify will infer parrent pid correctly because

os:cmd("echo $PPID").

works correctly and systemd-notify by default uses this parent pid. But after some strace-ing I observe
that os:cmd/1 introduces one extra intermediary shell process. And even if it was working as intended, it wouldn't have lasted long: erlang 19 is going to change this scheme.

So yes, --pid should indeed be used.

[michaelklishin]

@binarin is this shortcoming worth delaying 3.6.1 for in your opinion?

[binarin]

No, because old users aren't affected - as 3.6.1 still contains old code which uses sd_notify NIF.