-
Notifications
You must be signed in to change notification settings - Fork 34
ipptool: Unable to connect to localhost on port 631 - Transport endpoint is not connected #35
Comments
This is a known misbehavior of Ubuntu 16.04 LTS: The CUPS service dies at random. A Ubuntu 16.04 LTS vagrant box is the default SUT (system under test) for all integration tests of this module. The box also used to have the problem you describe, but it does not occur with contemporary versions of the vagrant box. I don't know if someone ever found the reason for this, nor can I promise that a clean install of Ubuntu 16.04 LTS could fix it. There is however a known workaround with a custom systemd unit. See the code in the initial post of #12. If that works for you, I might add the workaround to the module. |
I have also seen this behaviour if you have set a default printer from the command line that writes to the /etc/cups/lpoptions file. The agent seems to nuke /etc/cups/lpoptions at the cost of crashing the cups services. Then cups service has respawned on the next agent run. |
@jhowe-uw This module deletes |
I can reproduce this reliably on a CentOS 7.6 desktop just by causing a refresh of the service:
It seems that the service refresh returns control to Puppet before CUPS is actually listening on the ipp port. Adding a systemd drop-in (inspired by #12) seems to work around the issue, by making systemd accept the connection on behalf of the starting CUPS: systemd::dropin_file { 'workaround-puppet-cups-35.conf':
unit => 'cups.socket',
content => @(END),
[Socket]
ListenStream=[::1]:631
|END
}
~> service { 'cups.socket':
ensure => running,
# Both units listen to port 631, however cups.service will play nice if
# cups.socket is started first. See sd_listen_fds(3).
start => 'systemctl stop cups.service && systemctl start cups.socket',
require => Package['cups'],
before => Service['cups'],
} The service start hack is a pity, though. CentOS 8 will probably include a better fix, but it's unlikely to make it in CentOS 7. |
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile).
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile). TODO: not tested for regressions on non-CentOS environments.
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile). TODO: not tested for regressions on non-CentOS environments.
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile). TODO: not tested for regressions on non-CentOS environments.
Sadly, I was not able to reproduce this with a CentOS 7.6 VirtualBox. |
@leoarnold, what did you try exactly? I can assure you, it happens in real life :) Also, at some point I'll clean up my patch and submit it as a PR. |
@tequeter The acceptance tests A pull request will only be accepted if it contains an acceptance test which will actually fail without the proposed changes. |
I do plan to provide the corresponding test, so that will work for me. It's a bit harsh for less technically-advanced users, though. Does that mean they have to figure out how to write a failing test to submit a bug report? |
@tequeter Everyone is always welcome to report issues. This is not the same as a pull request: As in any other open source project, pull requests are expected to be written in the style of the project and maintaining or raising its quality standards. In your case, we are talking about a problem which only some people report on some computers, but it has not yet been describe in a way that everyone can reproduce on any computer. Without a test that actually demonstrates which problem is solved here, it is unclear whether the patch actually solves a problem at all. Even worse: Without the test we cannot be sure that future manipulations of the code will not break your fix. That said, nobody has to really learn how to write those tests or use the dev environment of this module. I can write the tests myself, but therefore I need a reproducible way to cause the problem first. And then we could also see whether your proposed changes work on every operating system equally or maybe introduce problems for other platforms. |
This is not about me (well, I think?). As I wrote, you'll get a test with my PR, we both agree to this. Your first two comments today read as if bugs don't exist if they can't be reproduced with the current testsuite, though. That's... peculiar :) I do agree however that the issue is not well-defined. The CUPS service can be down for a lot of reasons (crashed, not yet started, ...) that are specific to the user's environment and hard to solve generically. Would you recommend that users affected by this class of bugs reopen issues specific to their environment? |
@tequeter This is a general purpose module, so all bugs that affect the general public will be fixed once understood. In the case of this issue I feel that it has not attracted huge attention per se, so only a minority seems to be affected, and we still seem to be at the stage of "Well, this seems to happen and then that, and I know how to fix that, but I can't really pinpoint why my setup is affected and others aren't." At that level of understanding, we have a trade-off: Your proposed way introduces a dependency (the systemd module) and tampers with another service (SystemD). This opens a lot of doors for additional maintenance, side effects, differences of how systemd is used in different operating systems. It could potentially break or impede other people's setups in ways we do not foresee yet. New features always introduce new liabilities. So, when a problem only affects a few setups and is not really thoroughly understood, it is more advisable that those affected fix their setups with a workaround of their choosing, rather than to add complexity to the general module. I am tempted though to add your workaround to the known issues section of the README. |
About the inline patch above: IIRC, there was some ordering issue (too strict? too loose? I forgot) with the service. My PR-in-the-works is better. About my PR-in-the-works, the branch @ 8884b1c :
But!
|
Ah, see, there's our user story: Given a system with CUPS already running On distros with systemd, this is not the case. On distros without systemd, this passes nicely. So now we seem to have isolated the problem. |
@tequeter I took the liberty of rephrasing your suggestions in the general style of the module and set you as the author of that commit: https://github.com/leoarnold/puppet-cups/tree/leoarnold/fix/systemd_distros I have already verified that the test fails without and passes with the patch on CentOS and Ubuntu. I'll publish the fix as |
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile).
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile).
A few comments:
I rebased my commit as 1570be5 for easier diffing. It's a rough job, some of the |
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile). TODO: not tested for regressions on non-CentOS environments.
Problem statement: on some OSes (most notably RHEL7 and derivatives), the Cups service may have started and not listen on the IPP port yet. This causes a problem when this module (re)starts the service and expects to be able to add/remove printers with ipptool right after. Thus, modify the standard cups.socket service on RHEL7 through a drop-in to also manage the IPP port. This way, systemd will accept the incoming connections and hand them off to Cups once it is really started. This is mostly a kludge for a 3rd party bug, but still required to make the module behave reliably. Fix some cases of leoarnold#35. Breaking changes: - Bump the Puppet minimum version to 4.10.0 for Hiera 5. - Depend on puppetlabs/stdlib and camptocamp/systemd (and its dependency puppetlabs/inifile). TODO: not tested for regressions on non-CentOS environments.
I have a problem integrating the systemd fix in my setup. When I use
Wouldn’t it be easier to support such configuration when a |
@PhilippvK Good catch. I think in Puppet 4 the Or maybe it is just about which is defined first and you were the first to use a different order than anybody else. I will keep this in mind when I find the time to review #250 which promises to ease the interaction with systemd. |
@leoarnold Thank you for your quick answer. You were right! I was not aware of the fact, that the order of resource declaration on in puppet manifest does matter unless if explicitly defined using require/subscribe/->/~>. |
Given Ubuntu 16.04 with Puppet 4.10.9cups and CUPS 2.1.3-4.
When I apply the manifest with
puppet agent -t
on a nodeThen I get the error message, but only the first time it runs. The next time it runs fine.
The text was updated successfully, but these errors were encountered: