chef-client fails when attempting to disable a service that doesn't exist.

I don't think it's so clear-cut.

There have been questions before, people wondering why Chef doesn't create an init script—and the general consensus was that the service resource should assume everything is set up correctly, including an init script.

Following that line of reasoning, if I ask Chef to stop a service and the init script is missing, Chef won't be able to stop it—and that's a fatal error if there ever was one.
The stop action cannot assume the recipe is also calling disable—maybe the recipe is stopping it to apply some changes and then start it again. If the service doesn't stop, all bets are off; subsequent actions may corrupt data and so on.

The disable action is different.
On most distros it doesn't depend on the init script at all, in which case I agree it can ignore the absence of the init script.
The bottom line is, the service shouldn't swallow exceptions.

I think that's already the case, so here's my vote for rejecting this ticket.

(Note that I'm not arguing the implementation is perfect—if a distro-specific init system doesn't need the init script to disable the service yet it fails, then the distro-specific provider should be fixed. I'm only arguing this shouldn't leak into the generic provider)

I certainly see your point, but I think there is a better approach without breaking backward compatibility and allowing flexibility. It would be ideal if the service resource supported an 'options' attribute that you could specify something like :ignore_if_missing.
Also, I thought the service resource checks to see if the service actually is stopped, regardless of whether the init script existed by looking at the process table to ensure either 'name' or what is specified in the 'patter' attribute doesn't exist?

Looking at git log, this new behavior seems intentional, as there is code to explicitly catch the 'no such file or directory' message in the redhat service provider.
Looks like it was introduced with commit e9da1c83.

That was an unintentional regression with the whyrun patches and since it changes the behavior it just needs to be reverted. It would only be acceptable to change that going from 10.x to 11.x not from 10.12 to 10.14.

As an aside, I like the current behavior. As a practical matter, it is good to be able to write security policy language to disable services:

%w{telnet telnetd}.each do |s|
  service s do
    action [:stop, :disable]
  end
end

That seems easy to argue that you could just protect that with not_if/only_if clauses, but at a large organization with thousands of servers you may need to apply security policy language to a mix of different version of different flavors of unix (homogenization is always good, but that fails right at the point where your company buys someone else for their software and it all runs on solaris and nobody has the time to port it, so your IT department is forced to support thousands of ubuntu or rhel-based servers and 5 solaris boxes – and it usually takes large organizations at least the time in between major revisions of rhel to be able to get the bulk of their software running on the new revision, just in time for a new major version bump).

So, given all the different ways of running services (sysv init, upstart, systemd, inetd/xinetd), the propensity for OS vendors to swap names and now swap boot systems around, and the possibility of heterogeneous environments, it makes it painful to have :stop and :disable throw assertions – requiring precisely specifying which services exist on which operating systems and protecting them with checks for their init scripts and/or installed packages.

At the same time I'm not against having the option of supporting the alternative behavior, but I think the existing behavior needs to be preserved as the default to as not to cause a lot of cookbook-rewriting. Flags could be added to the service resource to allow turning on strict error checking, and a global flag could be added to the Chef::Config so that users who disagree with me and want strict error checking by default could set their configuration up this way.

Mostly I see this as creating a lot of extra work in order to be "precise" when I just don't care in order to get my job done and move on – if its not installed that's fine, then its really disabled, that more than satisfies my requirements – there is an edge case where somehow the service has started but then the package has been removed and the service is still running and then issuing a [:stop, :disable] doesn't get me what I want, but that is an edge case which should never happen with well-behaved packages (that do their own stop on package removal) and with good chef recipes (that call stop before trying to remove a package and not vice versa), and that kind of condition can be caught by some simple 'knife ssh' auditing of running services (which should be done periodically as part of security policy – and in fact monitoring systems should simply be alerting of something like telnetd is running – trust chef, but verify).

So, this seems like forcing system admins to spend a lot of extra time writing configuration code to deal with edge case that aren't important, and which isn't going to offer benefits to configuration or security over the alternative approach, and makes it more difficult to simply write policy language and makes it harder to simply express "i want telnet to be off everywhere", which should be simple.

But this argument is a bit pointless anyway, since we can't change the API in 10.14...

Actually this does not affect Ubuntu 10.04, and seems to only affect redhat, which makes it even yuckier of a regression since the behavior is not consistent between operating systems right now.

Fixed in 10-stable for redhat + freebsd.