The current systemd service does not allow gracefully for services to depend on bitcoind. All dependent units will be launched immediately, regardless of current status. So if it is to work at all, they need an inefficient polling loop.
In the service file the service type is specified as Type=forking but we don’t heed the behavior specified. From the systemd.service(5) man page:
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 are set up.
A possible solution is #21007, which adds -daemonwait so that the control is only returned to the parent process when startup is complete. In combination with Type=forking, I think this achieves the proper functionality: to start dependent units only when RPC functionality is working.
With that the only change to the service file needed would be to use -daemonwait instead of -daemon.
An alternative would be to implement support for Type=notify and do readyness notification through sd_notify. But I opted for daemonwait because it seems more generally useful. The advantage of using a native notification mechanism, however, would be that it is still possible to have logging through stdout to the journal. The drawback that it introduces an optional dependency on libsystemd.
