Project

General

Profile

Bug #5593

Recent versions of svcadm invoked for multiple FMRIs say "Partial FMRI matches multiple instances"

Added by Jim Klimov almost 5 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
smf
Start date:
2015-02-05
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

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).

  1. svcadm clear frequent hourly weekly daily monthly
    svcadm: Partial FMRI matches multiple instances
  1. svcadm clear {frequent,hourly,weekly,daily,monthly}
    svcadm: Partial FMRI matches multiple instances
Single-argument works as it should, and also proves that the short FMRI names are not in fact ambiguous:
  1. for X in frequent hourly weekly daily monthly; do svcadm clear $X; done
Also "svcs" proves that:
  1. 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
Same for separate single-instance services:
  1. svcadm restart autofs nfs/client
    svcadm: Partial FMRI matches multiple instances
  1. svcs autofs nfs/client
    STATE STIME FMRI
    disabled Jan_28 svc:/network/nfs/client:default
    online Jan_28 svc:/system/filesystem/autofs:default
Overall, "svcs -a" also finds nothing hidden:
  1. 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

Following the comments of the code above, I see that a contrived wildcard in command-line solves the issue:
  1. 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

Related to illumos gate - Bug #8688: svcadm does not handle multiple partial FMRI argumentsClosed2017-09-28

Actions

History

#1

Updated by Jim Klimov almost 5 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:

  1. 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

#2

Updated by Andy Fiddaman about 2 years ago

  • Related to Bug #8688: svcadm does not handle multiple partial FMRI arguments added
#3

Updated by Electric Monk about 2 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>

Also available in: Atom PDF