Quando é a hora apropriada para iniciar o Redshift usando upstart?

Question

Eu tenho tentado fazer com que o Redshift inicie antes de modo que a tela de boas-vindas não seja ceguem-me, em especial quando mudam de utilizador.

Rodar o Redshift como um serviço não parece totalmente suportado (veja, por exemplo, este bug ) mas parece para ser possível em princípio.

Depois de tentar algumas coisas encontradas no AskUbuntu sem sucesso, minha tentativa atual é configurar minha própria tarefa inicial; aqui está o meu /etc/init/redshift.conf :

# Redshift

description "Redshift"
author      "[email protected]"

start on (started lightdm)

script
  exec redshift -c /etc/redshift.conf
end script

stop on runlevel [016]

Eu percebi que iniciar após o LightDM estar funcionando deve funcionar e parar com ele também.

Agora, isso acaba no meu arquivo de log /var/log/upstart/redshift.log :

'RANDR Query Version' returned error -1
Initialization of randr failed.

Pesquisando o erro não foi muito informativo. Eu acho que ainda sou muito cedo e algum serviço ou outro relacionado a magicks de exibição ainda não está em execução.

Qual deve ser minha expressão start on ?

^{Ubuntu 14.04 LTS; 3.13.0-77-genérico # 121-Ubuntu SMP ... x86_64 GNU / Linux;
redshift 1.8; Servidor RandR versão 1.4; upstart 1.12.1}

    

Answer 1

O Redshift está ligado a um servidor X . Embora você possa iniciá-lo como parte da inicialização do sistema, isso é frágil; a maneira robusta de iniciá-lo está no contexto da sessão do servidor X (que é mais ampla que a sessão de login do X).

Pode haver vários servidores X sendo executados na mesma máquina em um determinado momento. Eles são atribuídos números de exibição em um primeiro a chegar, primeiro a ser servido. O número de exibição é como um programa sabe qual servidor contatar, e os programas procuram por ele na variável de ambiente DISPLAY . A maneira natural de iniciar um programa GUI é em um contexto em que a variável de ambiente DISPLAY está configurada para o valor desejado.

Você pode supor que lightdm é a primeira entidade que inicia um servidor X, portanto, exibe :0 e codifica a variável de ambiente DISPLAY=:0 em seu trabalho inicial. Você também precisará definir a variável XAUTHORITY (consulte Abra uma janela em um display X remoto (por que" Não é possível abrir o display ")? ). Acho lightdm no Ubuntu armazena o cookie em /var/lib/lightdm/.Xauthority .

env DISPLAY=":0"
env XAUTHORITY="/var/lib/lightdm/.Xauthority"

Mas isso é frágil: presume-se que o display lightdm esteja em :0 . Eu acho que não vai funcionar em sua forma atual por causa de uma condição de corrida: o trabalho lightdm pode ser considerado iniciado antes do servidor X estar ativo e em execução (não tenho certeza sobre isso, não sei que ponto o trabalho conta como iniciado).

A maneira limpa é fazer com que o lightdm inicie o Redshift. Dessa forma, é iniciado no momento certo e no contexto certo. Edite /etc/lightdm/lightdm.conf e adicione redshift -c /etc/redshift.conf à linha display-setup-script na seção SeatDefaults :

[SeatDefaults]
…
display-setup-script=redshift -c /etc/redshift.conf &

Observe o & para iniciar redshift no segundo plano (caso contrário, o lightdm esperaria que ele fosse concluído). Acho que o Redshift sairá quando o servidor X sair (os aplicativos X geralmente saem quando a tela some, portanto não há necessidade de rastrear o processo e eliminá-lo explicitamente.

    

Answer 2

Para evitar o lightdm-freeze .

A razão é que o & não é passado para o shell, mas sim para redshift como um parâmetro (veja em ps -aux para verificar). Para resolver isso, crie um script, f.ex.

redshift -c  /etc/redshift.conf &

em /root/bin/redshift.sh . Chmod 755 e edite /etc/lightdm/lightdm.conf.d/90-redshift.conf para conter

[Seat:*]
display-setup-script=/root/bin/redshift.sh

( [Seat:*] parece ser o novo [SeatDefaults] ).