Bug #5593
closed
Recent versions of svcadm invoked for multiple FMRIs say "Partial FMRI matches multiple instances"
100%
Description
Initial discussion on the mailing list: http://comments.gmane.org/gmane.os.illumos.devel/20204
With recent illumos-based distros (OI Hipster, OmniOS bloody) unlike older distros (from Solaris 10 up to OI 151a8 at least) there is a regression in that calling "svcadm <command> abbrfmri1 abbrfmri2 ... abbrfmriN" no longer works and instead complains that "Partial FMRI matches multiple instances". This happens for abbreviated FMRIs that do unambiguously name a service instance, be it a shortened name of a single-instance service or a unique name of a non-"default" instance (where no other services have an instance with the same name). Thus, each partial FMRI in reality matches one instance, so the message is wrong as well as the ultimate failure of the command (as a way to protect from mistakes due to ambiguity).
- svcadm clear frequent hourly weekly daily monthly
svcadm: Partial FMRI matches multiple instances
- svcadm clear {frequent,hourly,weekly,daily,monthly}
svcadm: Partial FMRI matches multiple instances
- for X in frequent hourly weekly daily monthly; do svcadm clear $X; done
- svcs frequent hourly weekly daily monthly
STATE STIME FMRI
online Feb_03 svc:/system/filesystem/zfs/auto-snapshot:weekly
online Feb_03 svc:/system/filesystem/zfs/auto-snapshot:monthly
maintenance Feb_03 svc:/system/filesystem/zfs/auto-snapshot:hourly
maintenance Feb_03 svc:/system/filesystem/zfs/auto-snapshot:frequent
maintenance Feb_04 svc:/system/filesystem/zfs/auto-snapshot:daily
- svcadm restart autofs nfs/client
svcadm: Partial FMRI matches multiple instances
- svcs autofs nfs/client
STATE STIME FMRI
disabled Jan_28 svc:/network/nfs/client:default
online Jan_28 svc:/system/filesystem/autofs:default
- svcs -a | egrep 'frequent|hourly|weekly|daily|monthly|autofs|nfs/client'
disabled Jan_28 svc:/network/nfs/client:default
online Jan_28 svc:/system/filesystem/autofs:default
online Feb_03 svc:/system/filesystem/zfs/auto-snapshot:weekly
online Feb_03 svc:/system/filesystem/zfs/auto-snapshot:monthly
maintenance Feb_03 svc:/system/filesystem/zfs/auto-snapshot:hourly
maintenance Feb_03 svc:/system/filesystem/zfs/auto-snapshot:frequent
maintenance Feb_04 svc:/system/filesystem/zfs/auto-snapshot:daily
The regression was probably introduced in this commit:
https://github.com/joyent/illumos-joyent/commit/5d047bee30f80f141cc55b60b0f84cb75f5ad80d
(jjelinek authored on Oct 22, 2013: OS-2567 SMF: allow svcadm to act on multiple instances simultaneously)
and the error may be lurking around usr/src/lib/libscf/common/lowlevel.c:6826 as of that commit:
https://github.com/joyent/illumos-joyent/commit/5d047bee30f80f141cc55b60b0f84cb75f5ad80d#diff-d873aa76861657c835899e99f573a6f1R6826
- svcadm clear frequent hourly weekly daily monthly
(this worked)
At the very least, this looks like a regression (worked before, but no longer does, and some scripts/habits may and do rely on old behavior) and the usecase in example is not something the manpage says it is protecting against (abbreviated FMRI is not ambiguous).
Related issues
Updated by Jim Klimov almost 9 years ago
For a bit more historic context, here are Jerry's insights from the mailing list discussion on the issue:
When we implemented the support for using wildcards in svcadm to allow you to operate on multiple instances with a single invocation we had some discussion about this behavior.
Here is an edited comment from our internal bug report:
**
smf has a standard mechanism for matching fmri's, the scf_walk_fmri() function.
It is simple to make svcadm handle wildcards, we just add the SCF_WALK_MULTIPLE flag, just like the svcs command does.
However, smf also has builtin shortened fmri handling, so, for example, giving the base name matches multiple instances:
- svcs mdata
STATE STIME FMRI
disabled 12:52:58 svc:/smartdc/mdata:fetch
disabled 12:53:01 svc:/smartdc/mdata:execute
If we make svcadm work like svcs already does, then it is hard to see how anyone could be depending on the old behavior, since in the case of multiple instances, svcadm was always failing before. However, in a chat one of the engineers expressed concern about users needing to be protected from themselves. For example, with PostgreSQL, it is delivered with a postgres:pg32 and postgres:pg64 service and it would be weird, or possibly dangerous, to enable both, so if someone ran "svcadm enable postgres" then previously they would have been protected by the failing command but now both would be enabled.
So, we either need to add an option to svcadm which says to enable multiple instance support (lame) or we need to see how hard it will be to change the fmri walking code to disable matching on partial fmri's with a new option. Actually, we can't simply disable that, since it is normal for people to use partial fmri's when they know there is only a single match, so we really need the new option to error on partial fmri's only when there is more than one, but succeed when there are multiple matches because of wildcards.So, I think our assumption about users depending on specific svcadm behavior when using a partial FMRI might have been incorrect, but this gives the rationale for the current behavior, which is documented on the svcadm man page:
*For subcommands taking one or more operands, if the operand specifies a
service (instead of a service instance), and that service has only a
single instance, svcadm operates on that instance. If an abbreviated
FMRI (a fault management resource identifier) matches more than one
service or instance, a warning message is displayed and that operand is
ignored. If a pattern matches more than one service or instance, the
subcommand is applied to all matches. See smf(5).
You can feel free to file a bug on the current behavior. If you do, it would be helpful to describe how you think this should work given the constraints described above.
When you file the bug it will be helpful to include the "svcs -a" output to compare against the FMRI that should be unique.
Jerry
Also, here's another user's example of unexpected failure:
$ svcadm restart samba wins swat
svcadm: Partial FMRI matches multiple instances
...and this works:
$ for each in samba wins swat ; do
svcadm restart $each
done
Updated by Andy Fiddaman about 6 years ago
- Related to Bug #8688: svcadm does not handle multiple partial FMRI arguments added
Updated by Electric Monk about 6 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit ad3ad82ad2fb99c424a8482bd1908d08b990ccea
commit ad3ad82ad2fb99c424a8482bd1908d08b990ccea
Author: Andy Fiddaman <omnios@citrus-it.net>
Date: 2017-10-18T20:16:11.000Z
5112 svcadm manpage needs more 5021-related updates
5593 Recent versions of svcadm invoked for multiple FMRIs say "Partial FMRI matches multiple instances"
8688 svcadm does not handle multiple partial FMRI arguments
Reviewed by: Dominik Hassler <hadfl@omniosce.org>
Reviewed by: Chris Fraire <cfraire@me.com>
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>