Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Fedora] cups.service.in: Use 'notify' service type and run after net… #51

Merged
merged 3 commits into from
Nov 25, 2020
Merged

[Fedora] cups.service.in: Use 'notify' service type and run after net… #51

merged 3 commits into from
Nov 25, 2020

Conversation

zdohnal
Copy link
Member

@zdohnal zdohnal commented Nov 25, 2020

…work.target

  1. If the service is defined with 'simple' type, the result of 'systemctl' is 0 regardless of actual startup result, because it reports success/failure of forking process (even before cupsd is started). This way errors due bad configuration or programming errors are masked during systemctl invocation.
    The 'notify' type depends on executable sending a 'Im running' type of message to systemd after successful start and systemctl's return code depends whether this message came or not, which solves the issue.
  2. The service needs to be started after all units needed for network.target are activated. This prevents starting cupsd before we have ports ready.

Fedora bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1153660 (adding network.target)
https://bugzilla.redhat.com/show_bug.cgi?id=1088918 (change of the service type)

…work.target

1) If the service is defined with 'simple' type, the result of 'systemctl' is 0 regardless of actual startup result, because it reports success/failure of forking process (even before cupsd is started). This way errors due bad configuration or programming errors are masked during systemctl invocation.
The 'notify' type depends on executable sending a 'Im running' type of message to systemd after successful start and systemctl's return code depends whether this message came or not, which solves the issue.
2) The service needs to be started after all units needed for network.target are activated. This prevents starting cupsd before we have ports ready.

Fedora bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1153660 (adding network.target)
https://bugzilla.redhat.com/show_bug.cgi?id=1088918 (change of the service type)
@zdohnal
Copy link
Member Author

zdohnal commented Nov 25, 2020

The next patches depends on the code in this PR, so I'll commit them into the same branch to prevent conflicts between PRs.

Other bugs descriptions are within commit messages.

If an user has a NIS group as SystemGroup in cups-files.conf, then cupsd fails to start if it is activated before ypbind service. Setting 'After=ypbind.service' sets unit's order to cupsd being started after ypbind.

Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1494558
@michaelrsweet michaelrsweet self-assigned this Nov 25, 2020
@michaelrsweet michaelrsweet added enhancement New feature or request platform issue Issue is specific to an OS or desktop priority-medium labels Nov 25, 2020
@michaelrsweet michaelrsweet added this to the v2.3.3op1 milestone Nov 25, 2020
Copy link
Member

@michaelrsweet michaelrsweet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor stylistic issues, but I’ll take care of those...

@michaelrsweet michaelrsweet merged commit 1b12723 into OpenPrinting:master Nov 25, 2020
@zdohnal
Copy link
Member Author

zdohnal commented Nov 25, 2020

Thanks for the merge and coding style fix!

I really try to follow coding style, even if it doesn't look like that :) .

@michaelrsweet
Copy link
Member

@zdohnal No worries :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request platform issue Issue is specific to an OS or desktop priority-medium
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants