Ceph

OK - I've re-grokked what is happening, and yes, the * does need to be escaped to prevent shell file globbing. However this got me thinking and I believe there's a more fundamental issue here.

systemd interprets * literally in certain situations - but uses it as a wildcard in others.

This is because it is impossible for some systemctl commands (like enable or preset) to know what to expand wildcards to. For example, on a host with 2 existing osds enabled:

> ls /etc/systemd/system/ceph-osd.target.wants/
ceph-osd@0.service  ceph-osd@1.service

# Expect a no-op, since the services are already enabled.
> systemctl enable ceph-osd@\*.service
Created symlink from /etc/systemd/system/ceph-osd.target.wants/ceph-osd@\x2a.service to /usr/lib/systemd/system/ceph-osd@.service.

> ls /etc/systemd/system/ceph-osd.target.wants/
ceph-osd@0.service  ceph-osd@1.service  ceph-osd@\x2a.service

# Try to disable all ceph-osd services
> systemctl disable ceph-osd@\*.service
Removed symlink /etc/systemd/system/ceph-osd.target.wants/ceph-osd@\x2a.service.

# run again, in case previous presence of literal * stopped wildcard expansion
> systemctl disable ceph-osd@\*.service

> ls /etc/systemd/system/ceph-osd.target.wants/
ceph-osd@0.service  ceph-osd@1.service

As you can see, enable and disable (and others like preset) always treat * as literal.

As a result I suspect that several of the systemctl commands in the rpm scripts aren't doing whatever they were intended to do.

You are right that disable/enable treats * as literal (and it makes sense there) but we do not use them in the scripts. The preset itself should do the * expansion (and in both my test systems it does). There might be a bug in the systemd version that you use that does not do that though (I do recall there were a couple of issues with * expansion in some versions of systemd :-/ ).

fyi: I tested with systemd-231-17 in fedora and systemd-219-20 in rhel.

@Matthew: For completeness, can you write which version of systemd you tested with?

Hi - it's Scientific Linux: systemd-219 - installed from rpm systemd-219-30.el7_3.3

However... I've rebuilt my test box to try and replicate this bug from scratch, and now I can't. Something obviously created the '\x2a' service files in the last iteration, but they don't seem to be being created this time. My last install was an upgrade from a running jewel cluster, whereas this time it was a fresh install, so that might be related, but at this point I'm happy for this to be closed and I'll just keep an eye out for it in future, and re-open if I can find a way to reliably reproduce this (or if anyone else hits the same situation).

Sorry for this dead-end!