Bug 961707

Thank for a bug report. I currently cannot test this, I do not have Fedora 19 installed yet, but it's planned to be done pretty soon. Meanwhile, I do not think that evolution itself does anything with brightness, I do not know where the settings key or anything for the brightness level is, thus I guess it's more related to your desktop environment. I suppose you use gnome-shell. Does the same happen when you close gedit, or gnome-terminal, or Nautilus, or it's just evolution returning back the brightness. Also, do you change the brightness when evolution is already running, or before you run it?

After more investigation, I've found this only happens when colour management is enabled for the laptop screen.

Changing component to colord.

I'm seeing this in Fedora 20 with:
colord-1.1.4-1.fc20.x86_64
gnome-shell-3.10.2.1-3.fc20.x86_64
gnome-settings-daemon-3.10.2-3.fc20.x86_64

Is closing evolution somehow making gnome-settings-daemon crash perhaps?

I'll watch out for it next time and see if I can see any evidence of that.

No, gnome-settings-daemon is still running with the original PID it had.

This is the only thing in the journal:

Jan 13 23:33:39 rubik systemd[1]: Started Load/Save Screen Backlight Brightness of acpi_video0.

The next question is: why does that service start at odd times?

Here is the result of 'systemctl show systemd-backlight':

Id=systemd-backlight
Names=systemd-backlight
Requires=-.mount
WantedBy=sys-devices-pci0000:00-0000:00:02.0-backlight-acpi_video0.device
Conflicts=shutdown.target
Before=sysinit.target shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service systemd
RequiresMountsFor=/var/lib/systemd/backlight
Documentation=man:systemd-backlight@.service(8)
Description=Load/Save Screen Backlight Brightness of acpi_video0
LoadState=loaded
ActiveState=active
SubState=exited
FragmentPath=/usr/lib/systemd/system/systemd-backlight@.service
UnitFileState=static
InactiveExitTimestamp=Thu 2014-01-16 09:46:44 GMT
InactiveExitTimestampMonotonic=14911839
ActiveEnterTimestamp=Thu 2014-01-16 09:46:44 GMT
ActiveEnterTimestampMonotonic=15285836
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=no
OnFailureIsolate=no
IgnoreOnIsolate=no
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestamp=Thu 2014-01-16 09:46:44 GMT
ConditionTimestampMonotonic=14910584
ConditionResult=yes
Transient=no
Slice=system-systemd\x2dbacklight.slice
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=0
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestampMonotonic=0
StartLimitInterval=10000000
StartLimitBurst=5
StartLimitAction=none
ExecStart={ path=/usr/lib/systemd/systemd-backlight ; argv[]=/usr/lib/systemd/sy
ExecStop={ path=/usr/lib/systemd/systemd-backlight ; argv[]=/usr/lib/systemd/sys
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
Result=success
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=30584
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=30584
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
SameProcessGroup=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
CPUAccounting=no
CPUShares=1024
BlockIOAccounting=no
BlockIOWeight=1000
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
ExecMainStartTimestamp=Thu 2014-01-16 09:46:44 GMT
ExecMainStartTimestampMonotonic=14911808
ExecMainExitTimestamp=Thu 2014-01-16 09:46:44 GMT
ExecMainExitTimestampMonotonic=15285659
ExecMainPID=352
ExecMainCode=1
ExecMainStatus=0

and here are some journal entries showing the service being started before and after starting a VM(!):

Jan 16 13:14:01 rubik systemd[1]: Started Virtual Machine and Container Registration Service.
Jan 16 13:14:01 rubik systemd[1]: Starting Virtual Machine qemu-RHEL7.0-altgr.
Jan 16 13:14:01 rubik systemd-machined[14784]: New machine qemu-RHEL7.0-altgr.
Jan 16 13:14:01 rubik systemd[1]: Started Virtual Machine qemu-RHEL7.0-altgr.
Jan 16 13:14:02 rubik avahi-daemon[676]: Registering new address record for fe80::fc54:ff:fe6a:3778 on vnet0.*.
Jan 16 13:14:02 rubik kernel: virbr0: port 2(vnet0) entered learning state
Jan 16 13:14:04 rubik systemd[1]: Started Load/Save Screen Backlight Brightness of acpi_video0.
Jan 16 13:14:04 rubik kernel: virbr0: topology change detected, propagating
Jan 16 13:14:04 rubik kernel: virbr0: port 2(vnet0) entered forwarding state
Jan 16 13:14:04 rubik kernel: IPv6: ADDRCONF(NETDEV_CHANGE): virbr0: link becomes ready
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: DHCPDISCOVER(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: DHCPOFFER(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: DHCPREQUEST(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: DHCPACK(virbr0) 192.168.122.213 52:54:00:6a:37:78 localhost
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: not giving name localhost.default to the DHCP lease of 192.168.122.213 because the name exists in /etc/hosts with address 127.0.0.1
Jan 16 13:14:34 rubik dnsmasq-dhcp[1533]: not giving name localhost to the DHCP lease of 192.168.122.213 because the name exists in /etc/hosts with address 127.0.0.1
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: DHCPDISCOVER(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: DHCPOFFER(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: DHCPREQUEST(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: DHCPACK(virbr0) 192.168.122.213 52:54:00:6a:37:78
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: not giving name localhost.default to the DHCP lease of 192.168.122.213 because the name exists in /etc/hosts with address 127.0.0.1
Jan 16 13:14:48 rubik dnsmasq-dhcp[1533]: not giving name localhost to the DHCP lease of 192.168.122.213 because the name exists in /etc/hosts with address 127.0.0.1
Jan 16 13:15:30 rubik systemd[1]: Started Load/Save Screen Backlight Brightness of acpi_video0.

One or other of these two instances reset the backlight brightness to full. Why were they triggered at all?

Smells like an other weird instance of bug 1043212.

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

I saw this again today, even though systemd-208-14.fc20.x86_64 is installed (and the system was rebooted after).

However, this time I looked at the journal but did *not* see any "Load/Save Screen Backlight Brightness of acpi_video0" messages that corresponded to the time of the brightness reset.

So maybe this is related to colord after all (see comment #2).

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.