You can analyze systemd boot sequence by following command. View the output file by using a SVG supporting web browser.
systemd-analyze plot > test.svg
That plotting will provide you last boot's timing statistics, which will provide you more clarified point of view to problem.
I solved my NFS mounting problem by adding mount commands in to /etc/rc.local. However I'm not sure, will it work with glusterd integration, worth a try for a quick fix. In order to make systemd run rc.local you should satisfy following condition:
# grep Condition /usr/lib/systemd/system/rc-local.service
ConditionFileIsExecutable=/etc/rc.d/rc.local
For units that are defined in actual, static files, this can be seen in systemctl status:
$ systemctl status halt-local.service
● halt-local.service - /usr/sbin/halt.local Compatibility
Loaded: loaded (/lib/systemd/system/halt-local.service; static)
Active: inactive (dead)
But there are units that are not defined by files, e.g. with systemd-cron installed. These have no useful location listed with status:
$ systemctl status cron-jojo-0.timer
● cron-jojo-0.timer - [Cron] "*/10 * * * * ..."
Loaded: loaded (/var/spool/cron/crontabs/jojo)
Active: active (waiting) since Mon 2015-05-18 14:53:01 UTC; 9min ago
In either case, though, the FragmentPath field is educating:
$ systemctl show -p FragmentPath cron-daily.service
FragmentPath=/lib/systemd/system/cron-daily.service
$ systemctl show -p FragmentPath cron-jojo-0.service
FragmentPath=/run/systemd/generator/cron-jojo-0.service
$ systemctl show -p FragmentPath halt-local.service
FragmentPath=/lib/systemd/system/halt-local.service
Best Answer
According to the author himself (poettering) in this thread : it is forbiden because the executable name might be needed in advance (e.g.: SELinux needs this).
But according to other in the same thread and in that one, is still works sometime-ish.
Given that most specifiers can be determined statically in advance (template, machine, etc.) it should get supported eventually.
In the meantime, one solution is to launch a shell, as noted in the question comments and in the first thread:
Another solution would be to manually invoke the ELF interpreter:
(Basically the same idea as manually running
/usr/bin/perl script.plinstead of trusting the she-bang of the script)