This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 741727

Summary: tigervnc package scripts reference a non-existent file
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: tigervncAssignee: Adam Tkac <atkac>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: atkac, ovasik
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 14:38:18 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Michal Jaegermann 2011-09-27 15:02:54 EDT
Description of problem:

Package scripts for tigervnc-server-1.1.0-1.fc17 try to do things like:

   /bin/systemctl try-restart vncserver.service

and that always fails because 'systemctl status vncserver.service' responds with:

vncserver.service
          Loaded: error (Reason: No such file or directory)
          Active: inactive (dead)

There is no such file or directory as this package supplies:
'/lib/systemd/system/vncserver@.service'

Version-Release number of selected component (if applicable):
tigervnc-1.1.0-1.fc17

How reproducible:
always

Additional info:
I would suggest that dropping a spurious '@' from that file name would be a good idea or shell may come with unwanted surprises.
Comment 1 Adam Tkac 2011-10-06 07:30:34 EDT
Although the /lib/systemd/system/vncserver@.service file looks wrongly, it is actually correct.

The main reason why we don't ship /lib/systemd/system/vncserver.service is that the vncserver service starts multiple Xvnc sessions. This was previously configured in /etc/sysconfig/vncservers but there is no good mechanism how to use similar way with systemd.

Please read the /lib/systemd/system/vncserver@.service:
...
# Quick HowTo:
# 1. Copy this file to /etc/systemd/system/vncserver@:<display>.service
# 2. Edit "User" and "ExecStart" variables appropriately
#       (ExecStart should be "/usr/bin/vncserver %i -arg1 -arg2")
# 3. Run `systemctl daemon-reload`
...

This way you can create vncserver@:1.service, vncserver@:2.service etc with proper parameters and you can start this service via `systemctl start vncserver@:1.service`, for example. This allows fine grained configuration of each VNC session and also allows you to control each session (for example you are able to stop only one session, not all VNC sessions).

This is not a bug, this is intentional.
Comment 2 Michal Jaegermann 2011-10-06 10:11:49 EDT
(In reply to comment #1)
> Although the /lib/systemd/system/vncserver@.service file looks wrongly, it is
> actually correct.

The report was not really about what is correct or not but about a discrepancy between what tigervnc supplies and what it is using it its own scripts.

> This is not a bug, this is intentional.

Are you seriously suggesting that spilling error messages from package scripts is intentional?  There are various ways to avoid this issue but package scripts need a bit of rewriting.

> there is no good mechanism how to use similar way with systemd.

Apparently you can put that on a banner and carry around.
Comment 3 Adam Tkac 2011-10-06 10:44:51 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Although the /lib/systemd/system/vncserver@.service file looks wrongly, it is
> > actually correct.
> 
> The report was not really about what is correct or not but about a discrepancy
> between what tigervnc supplies and what it is using it its own scripts.

Ah, sorry for misunderstanding, I read original description too quickly and though you talk that `/bin/systemctl try-restart vncserver.service` doesn't work from command line.

You are right the rpm scripts are wrong, I will fix this.
Comment 4 Adam Tkac 2013-03-12 14:38:18 EDT

*** This bug has been marked as a duplicate of bug 753216 ***