Bug 983232 - Tigervnc server fails to start via systemd
Tigervnc server fails to start via systemd
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tigervnc (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
: 984588 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-10 15:00 EDT by Alexander Shopov
Modified: 2013-10-09 10:45 EDT (History)
9 users (show)

See Also:
Fixed In Version: tigervnc-1.3.0-7.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-27 21:05:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
systemd unit file for vncserver@:1.service, including explicit PIDFile= line (1.74 KB, text/plain)
2013-07-19 16:35 EDT, "FeRD" (Frank Dana)
no flags Details

  None (edit)
Description Alexander Shopov 2013-07-10 15:00:33 EDT
Description of problem:
=================================
tigervnc server does not start when executed with the systemd modules. It starts just fine when executed as a user (normal or root)


Version-Release number of selected component (if applicable):
=================================
Latest Fedora 19 as of July 10, 2013.

tigervnc-license-1.2.80-0.16.20130314svn5065.fc19.noarch
tigervnc-server-minimal-1.2.80-0.16.20130314svn5065.fc19.x86_64
tigervnc-server-1.2.80-0.16.20130314svn5065.fc19.x86_64

systemd-python-204-9.fc19.x86_64
systemd-sysv-204-9.fc19.x86_64
systemd-libs-204-9.fc19.i686
systemd-libs-204-9.fc19.x86_64
systemd-204-9.fc19.x86_64
wine-systemd-1.6-0.1.rc2.fc19.noarch

How reproducible:
=================================
I have reproduced this on 2 x86_64 machines (one physical - Lenovo ThinkPad, the other virtual in vSphere) and one i686 laptop. All were done with clean installs.

Steps to Reproduce:
=================================
1. yum install tigervnc-server
2. cd  cd /lib/systemd/system
3. cp vncserver@.service 'vncserver@:1.service'
4. vi 'vncserver@:1.service'
 - replace <USER> with real username
Here is the part in my occasion
[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l ash -c "/usr/bin/vncserver %i"
ExecStop=/sbin/runuser -l ash -c "/usr/bin/vncserver -kill %i"

5. As the user from 4 - set password for vnc with vncpasswd
6. systemctl enable 'vncserver@:1.service'
7. verify that no previous instances of vncserver have been started
8. verify that there are no stale pid files in users $HOME/.vnc dir
7. systemctl start 'vncserver@:1.service'

Actual results:
=================================
VNC exits so quickly that no client can connect. It exits so quickly that wen you do
ps fax | grep vnc 
after the  systemctl start - the process is already gone



Expected results:
=================================
vnc should work. When I try to run it as the normal user with:
/usr/bin/vncserver :1
vnc works OK

It also works OK when I start with with /sbin/runuser -l ash -c "/usr/bin/vncserver :1" as root

Additional info:
=================================
1. Log in ~ash/.vnc/.localhost.localdomain:1.log
=================

Xvnc TigerVNC 1.2.80 - built Jun 17 2013 14:19:13
Copyright (C) 1999-2011 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 11401000, The X.Org Foundation

Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension VNC-EXTENSION
Initializing built-in extension GLX

Wed Jul 10 21:32:20 2013
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on all interface(s), port 5901
 vncext:      created VNC server for screen 0
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
      after 141 requests (141 known processed) with 0 events remaining.

** (gnome-session-check-accelerated:1487): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Disconnected: Connection was disconnected before a reply was received

(gnome-session-check-accelerated:1487): Gtk-WARNING **: cannot open display: :1

** (gnome-session-check-accelerated:1499): WARNING **: Could not open X display

(gnome-session-check-accelerated:1499): Gtk-WARNING **: cannot open display: :1

** (process:1450): WARNING **: software acceleration check failed: Child process exited with code 1

** (gnome-session:1450): WARNING **: Could not open X display

** (gnome-session:1450): WARNING **: Cannot open display: 

2. Log in /var/log/messages
=================
Jul 10 21:32:19 localhost systemd[1]: Starting Remote desktop service (VNC)...
Jul 10 21:32:22 localhost runuser[1412]: New 'localhost.localdomain:1 (ash)' desktop is localhost.localdomain:1
Jul 10 21:32:22 localhost runuser[1412]: Starting applications specified in /home/ash/.vnc/xstartup
Jul 10 21:32:22 localhost runuser[1412]: Log file is /home/ash/.vnc/localhost.localdomain:1.log
Jul 10 21:32:23 localhost runuser[1453]: Killing Xvnc process ID 1439
Jul 10 21:32:24 localhost systemd[1]: Started Remote desktop service (VNC).
Comment 1 Alexander Shopov 2013-07-15 07:44:18 EDT
Just a small ping about the issue - this is not fire and forget - if you need any further information, try different configuration - I will  gladly help.
Comment 2 Tim Waugh 2013-07-16 06:25:30 EDT
*** Bug 984588 has been marked as a duplicate of this bug. ***
Comment 3 Tony White 2013-07-16 13:31:37 EDT
Same issue here. The vncserver unit file method worked fine before an upgrade to Fedora 19. I am using KDE.
I tried to run vncserver manually and that does work. Using the systemd unit method does not. Same thing happens that Alexander is describing. The service starts and then stops.
I can test any patches to fix this here. It would be really useful if this worked again.
Thank You.
Comment 4 "FeRD" (Frank Dana) 2013-07-18 19:14:29 EDT
The problem appears to be the detection of the Xvnc process / PID; systemd isn't picking it up and thinks the service has died, so it launches the ExecStop script almost immediately after vncserver (ExecStart) completes.

I was able to work around the problem by manually directing systemd to the Xvnc PID file in my homedir. The following line added to the /etc/systemd/system/vncserver@:1.service unit file Works For Me(TM):

PIDFile=/home/<USER>/.vnc/%H%i.pid
Comment 5 Erik P. Olsen 2013-07-19 14:02:29 EDT
(In reply to "FeRD" (Frank Dana) from comment #4)
> The problem appears to be the detection of the Xvnc process / PID; systemd
> isn't picking it up and thinks the service has died, so it launches the
> ExecStop script almost immediately after vncserver (ExecStart) completes.
> 
> I was able to work around the problem by manually directing systemd to the
> Xvnc PID file in my homedir. The following line added to the
> /etc/systemd/system/vncserver@:1.service unit file Works For Me(TM):
> 
> PIDFile=/home/<USER>/.vnc/%H%i.pid

I can't make it work with this addition but maybe there is more to it. Could you please include the entire service section of your unit file? I'll copy your file and see if that works for me.
Comment 6 "FeRD" (Frank Dana) 2013-07-19 16:35:13 EDT
Created attachment 775960 [details]
systemd unit file for vncserver@:1.service, including explicit PIDFile= line

Sure, I'm attaching my unit file — as usual, all instances of <USER> should be replaced by the username under which the vncserver process should be run.

Another potential issue is if the %H specifier (which evaluates to systemd's idea of the hostname) doesn't expand to the same string as the hostname part of the logfile name that Xvnc generates. On my installation, they match, but just in case you might try hardcoding the hostname part as

PIDFile=/home/<USER>/.vnc/hostname%i.pid

Or even just skip all of the specifiers and hardcode the exact filename.

When systemd's correctly picking up the pidfile,
'systemctl status vncserver@:1.service' will include a line such as:

Main PID: 9385 (Xvnc)

showing that it's using the lifecycle of the Xvnc process to monitor the service state.
Comment 7 Alexander Shopov 2013-07-22 04:44:30 EDT
I can also report that on all 3 machines I have (real - i686, x86_64 and virtual - x86_64) the fix given by FrankDana in Comment 4 works fine.
Comment 8 Alexander Shopov 2013-07-22 04:49:24 EDT
> I can't make it work with this addition but maybe there is more to it. Could
> you please include the entire service section of your unit file? I'll copy
> your file and see if that works for me.

Eric - try what Frank Dana advised. My 2c will be to
1st. Remove the line and see hat is the name of the pid file that Xvnc generates in ~/.vnc - basically remove all the stale *.log and *.pid files there, start the vnc service via systemd and see what is the name of the generated file
2nd - add the PIDFile line and use hardcoded value at first and if successful and then try to use the %H and %i aliases
3rd - if the above does not work - tray setting the hostname with the hostnamectl utility and try 1 and 2 again
Comment 9 Fedora Update System 2013-07-24 12:52:13 EDT
tigervnc-1.3.0-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/tigervnc-1.3.0-3.fc19
Comment 10 Fedora Update System 2013-07-25 20:36:29 EDT
Package tigervnc-1.3.0-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tigervnc-1.3.0-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13650/tigervnc-1.3.0-3.fc19
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2013-07-27 21:05:22 EDT
tigervnc-1.3.0-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 brhahlen 2013-07-31 15:39:09 EDT
Just installed a fresh (virtual) Fedora 19 system with the latest tigervnc-server update, however, this problem still persists for me.
Log output (relevant part):
===============================
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86AudioMicMute
Errors from xkbcomp are not fatal to the X server
/home/ben2404/.vnc/xstartup: line 5: x-terminal-emulator: command not found
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
      after 141 requests (140 known processed) with 0 events remaining.
cp: cannot stat ‘/usr/share/lxde/pcmanfm/pcmanfm.conf’: No such file or directory
===============================

Tried also with the adjustments in vncserver@:1.service, but unfortunately to no avail.
Comment 13 "FeRD" (Frank Dana) 2013-07-31 17:44:57 EDT
@brhalen (#12): From the output you showed us, I'm not sure that is the same problem -- it looks like perhaps the desktop environment you're trying to start inside the VNC server isn't installed completely/properly. (That failure to copy pcmanfm.conf is especially suspicious.)

If you manually run 'vncserver :1' as the appropriate user, do you get a working Xvnc? If the answer is NO (my prediction), then you're not experiencing this bug. It's a local issue (probably solved by installing some missing packages).

Also, if you ARE encountering the bug reported here, then there'll be an explicit
"runuser[###]: Killing Xvnc process ID ####"
line in /var/log/messages immediately after attempting to start vncserver@:1.service, like in Alexander's initial report.
Comment 14 brhahlen 2013-08-01 02:56:27 EDT
Sorry, I forgot to mention that, I see now.

The pcmancfm.conf error is something that I see everytime, ever since Fedora 17. I had resolved it at one time, but can't remember how.

When running 'vncserver :1' manually, my VNC works without a problem.

You mean errors like these:
Aug  1 08:54:36 Bilbo systemd[1]: Starting Remote desktop service (VNC)...
Aug  1 08:54:36 Bilbo systemd[1]: Started Remote desktop service (VNC).
Aug  1 08:54:39 Bilbo runuser[1222]: New 'Bilbo.benweb.eu:1 (ben2404)' desktop is Bilbo.benweb.eu:1
Aug  1 08:54:39 Bilbo runuser[1222]: Starting applications specified in /home/ben2404/.vnc/xstartup
Aug  1 08:54:39 Bilbo runuser[1222]: Log file is /home/ben2404/.vnc/Bilbo.benweb.eu:1.log
Aug  1 08:54:39 Bilbo runuser[1222]: Killing Xvnc process ID 1246
Comment 15 brhahlen 2013-08-01 03:12:17 EDT
Think I may have found the problem, at least, in my case:
The 'vncserver@.service' file, contains the following line:

ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver -fg %i"

I was looking at this, when I realized that the only thing that seems to differ from running the line from the command-prompt, is the '-fg' switch, which, according to the man-page, is used to spawn the vncserver as a foreground process.
I just deleted this switch, did a systemctl daemon-reload, relinked the service and started it successfully.
My line therefore now is:
ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver %i"
Comment 16 Tim Waugh 2013-08-01 11:05:18 EDT
Your [Service] section should look like this:

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver -fg %i"

The only difference from this should be that <USER> is replaced by your username.

If you take out "-fg", that makes the Type=simple line wrong.

brhahlen: could you please paste in your [Service] section as it now is, in its working state?
Comment 17 brhahlen 2013-08-01 15:37:34 EDT
This is the full vncserver@:1.service file that I have.
----------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l ben2404 -c "/usr/bin/vncserver %i -geometry 1600x850"

[Install]
WantedBy=multi-user.target
----------
I admit: my trying to remove the "-fg" was only due to the fact that it was the only difference I could think of from running it through CLI.
Also, reading the manpage, which said that the "-fg" switch makes it a foreground process, seemed odd to me, due to the fact that you're running it as a service, hence, not in the foreground.
However, this could just be my simplistic way of seeing things :-)

Could you elaborate on what the Type=simple line is meant for? I don't know too much about systemd and the service files, but am curious enough to want to find out.
Comment 18 "FeRD" (Frank Dana) 2013-08-01 15:47:53 EDT
systemd's Type= option is covered pretty well in the systemd.service(7) man page. The structure and operation of unit files in general is covered in systemd.unit(5), and the rest of the types have their own man pages as well (systemd.socket(5), systemd.target(5), systemd.mount(5), etc...)
Comment 19 "FeRD" (Frank Dana) 2013-08-01 15:48:54 EDT
Sorry, I knew I'd screw that up at least once. ALL of the man pages I mentioned are in section 5, including systemd.service.
Comment 20 brhahlen 2013-08-01 15:49:39 EDT
Thanks Frank, I'll have a look at those :-)
Comment 21 Tim Waugh 2013-08-08 09:59:36 EDT
brhahlen: so, your file looks fine except that it needs to have "-fg" before "%i" in the ExecStart line -- exactly the thing you said you needed to take out to fix the problem you were seeing.

I can't reproduce the problem you were seeing here. I use a service file with Type=simple and ExecStart having -fg in, and it all works as expected for me.

Is anyone else seeing problems with the as-shipped set-up, or is it perhaps something specific to brhahlen's machine?
Comment 22 Alexander Shopov 2013-08-19 03:25:37 EDT
The fix provided with the new package *worked for me an all* of my 3 configurations - x86 & 64 bit physical machines and the virtual 64 bit one.
Just adding for completeness - the provided fix changes the template file in
/lib/systemd/system/vncserver@.service
After the update - either regenerate your own file or use a diff tool such as meld to see the changes in lines and arguments.
Comment 23 Bill McGonigle 2013-09-05 03:24:42 EDT
Thanks for the tip, Alexander, this works for me on f19, in simple/-fg mode.

There does still appear to be a systemd regression with a PID file problem in forking mode, from what I can see from here.
Comment 24 Emmett Culley 2013-09-23 17:54:18 EDT
I have the same problem.  Here is the systemd file I am using:

------------------------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
PIDFile=/home/uname/.vnc/%H%i.pid
#PIDFile=/home/uname/.vnc/ws1.mydomain.tld.pid
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver -fg %i -geometry 1590x998 -rfbport 5902 -nolisten tcp"
ExecStop=/sbin/runuser -l uname -c "/usr/bin/vncserver -kill %i"

[Install]
WantedBy=multi-user.target

----------------------------------------

I have tried it with each of the PIDFile definitions shown it the above listing.  Niether worked

When I run systemd start vncsserver@:3.service it appears to be OK and if I quickly run netstat -ntlp I see that port 5903 is opened.  But very soon it disapears.  I also see the PID file for a few seconds, which disapears when the vncserver instance disapears.

This is the status output:

-----------------------------------
[root@ws1 ~]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: failed (Result: exit-code) since Mon 2013-09-23 14:43:25 PDT; 8s ago
  Process: 13764 ExecStop=/sbin/runuser -l emmett -c /usr/bin/vncserver -kill %i (code=exited, status=2)
  Process: 13685 ExecStart=/sbin/runuser -l emmett -c /usr/bin/vncserver -fg %i -geometry 1590x998 -localhost -rfbport 5902 -nolisten tcp (code=exited, status=0/SUCCESS)

Sep 23 14:43:20 ws1.mydomain.tld systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 14:43:20 ws1.mydomain.tld systemd[1]: Started Remote desktop service (VNC).
Sep 23 14:43:25 ws1.mydomain.tld systemd[1]: vncserver@:3.service: control process exited, code=e...s=2
Sep 23 14:43:25 ws1.mydomain.tld systemd[1]: Unit vncserver@:3.service entered failed state.
-----------------------------------

System is fully updated Fedora 19 (9/23/13)
Comment 25 "FeRD" (Frank Dana) 2013-09-23 18:27:40 EDT
Emmett,

I'd suggest re-generating your vncserver@:N.service file from the template in /usr/lib/systemd/system/vncserver@.service. Your current unit file contains a mix of the non-daemonized fix ("Type=simple", "vncserver -fg") and the daemonized fix ("ExecStop", "PIDFile").

(I think the main problem is the ExecStop, which isn't used with Type=simple — systemd can just kill the vncserver process directly to stop it.)
Comment 26 Emmett Culley 2013-09-24 01:28:19 EDT
I changed the service file to:

--------------------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver -fg %i -geometry 1590x998 -localhost -rfbport 5903 -nolisten tcp"

[Install]
WantedBy=multi-user.target
---------------------------------

And I still have the same problem.  The session starts (I see port 5903 open), then it disappears (I don't port 5903 open).

Here is the status report before it disappears:

-----------------------------------------------------
[root@ws1 emmett]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: active (running) since Mon 2013-09-23 22:23:25 PDT; 1s ago
  Process: 22408 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 22413 (runuser)
   CGroup: name=systemd:/system/vncserver@.service/vncserver@:3.service

Sep 23 22:23:24 ws1.webengineer.com systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 22:23:25 ws1.webengineer.com systemd[1]: Started Remote desktop service (VNC).
-----------------------------------------------------

And here is is after it disapears:

-----------------------------------------------------
[root@ws1 uname]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: inactive (dead)

Sep 23 22:13:16 ws1.domain.tld systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 22:13:17 ws1.domain.tld systemd[1]: Started Remote desktop service (VNC).
--------------------------------------------------------
Comment 27 brhahlen 2013-09-24 03:13:08 EDT
@Emmett: Have you tried taking out the -fg switch in the ExecStart part? That is what fixed my problem...
Comment 28 Emmett Culley 2013-09-24 12:59:03 EDT
Doh.  That fixed it.  The file(s) now look like this:

-----------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver %i -geometry 1590x998 -localhost -rfbport 5903 -nolisten tcp"

[Install]
WantedBy=multi-user.target
---------------------------

And each vnc server session stays up until stopped using systemctl.
Comment 29 Fedora Update System 2013-10-02 07:37:26 EDT
tigervnc-1.3.0-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/tigervnc-1.3.0-7.fc20
Comment 30 Richard S. Hendershot 2013-10-02 07:53:32 EDT
After you have tried running vncserver from a local login, you might need to specify the Desktop Manager, especially if you only have MATE Desktop installed.  I had to add the stop command and modify xstartup to make this work.  I did not need to remove the "-fg" toggle.

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l root -c "/usr/bin/vncserver -fg %i"
ExecStop=/sbin/runuser -l root -c "/usr/bin/vncserver -kill %i"


### ~/.vnc/xstartup
### fix for having only mate installed 
### - http://www.linuxreaders.com/2013/01/fix-blank-vnc-client-screen-on-mate-desktop-fedora.html
/usr/bin/mate-session
Comment 31 Fedora Update System 2013-10-09 10:45:57 EDT
tigervnc-1.3.0-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.