2017-07-30 1 views
0

J'ai écrit un fichier de service dans l'espace utilisateur de systemd pour démarrer le démon emacs. Cela fonctionne très bien. Mais au démarrage d'emacsclient je laisse déchiffrer mon fichier agenda. Pour cela j'ai un gpg-agent en cours d'exécution. Normalement, lorsque emacs est lancé, pineentry-gtk apparaît et me demande mon mot de passe de clé privée. Mais a démarré le démon avec systemd les variables d'environnement $ SSH_AUTH_SOCKET, $ GPG_AGENT_INFO et SSH_AGENT_PID ne sont pas connues. Par conséquent, aucun pinentry-gtk n'apparaît. Plusieurs approches pour alimenter le système à partir du système ont été bloquées. Je veux utiliser une approche dynamique ne mettant pas dans un chemin absolu.

Je définis une EnvironmentFile systemd et mis là

SSH_AUTH_SOCKET=${SSH_AUTH_SOCKET} 

et inclus le fichier dans emacs.sevice. En recherchant ici j'ai trouvé le lien this et ne peux pas imaginer que ceci est vrai. Cela signifie que les paramètres d'environnement dans un fichier de service/unité sont une autre histoire en tant que paramètre dans le fichier d'environnement. Ils ne peuvent pas se voir. Quel sens fait alors un fichier d'environnement?

L'étape suivante consistait à importer les variables d'environnement à partir de mon heure de connexion au ~/.bash_profile source comme ceci. Après la connexion, j'ai jeté un oeil afin de voir si systemd avait les variables d'environnement ou non. J'ai obtenu ceci en tapant

systemctl --user show-environmet 

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 
GPG_AGENT_INFO=${GPG_AGENT_INFO} 
HOME=/home/xxxx 
LANG=de_DE.UTF-8 
LOGNAME=xxxx 
PATH=/home/xxxx/bin:~/.emacs.d/shell-scripts: ......... 
AUTH_SOCK=${SSH_AUTH_SOCKET} 
USER=xxxx 
XDG_RUNTIME_DIR=/run/user/1000 

Mais le démarrage du démon emacs dans l'environnement systemd me montre les mêmes symptômes.

L'étape suivante consistait à importer les variables directement dans le fichier d'unité/service comme ceci.

[Unit] 
Description=Emacs: the extensible, self-documenting text editor 

[Service] 
# loading default environment for systemd in user space 
EnvironmentFile=%h/.config/systemd/xxxx-default-evironment.env 

Type=forking 
ExecStartPre=/bin/systemctl --user import-environment SSH_AUTH_SOCKET 
ExecStart=/usr/bin/emacs --daemon 
ExecStartPost=/bin/systemctl --user set-environment SSH_AUTH_SOCK=${SSH_AUTH_SOCK} 
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" 

Restart=always 

[Install] 
WantedBy=non-graphical.target 

Pas de succès dans cette approche aussi bien. Par ailleurs, je ne peux pas croire qu'il est si difficile de publier certaines variables d'environnement de SYSTEM à SYSTEM (D).

Les réponses sont les bienvenues.

Merci Falk

+0

Avez-vous essayé d'importer vos variables d'environnement en utilisant le package https://github.com/purcell/exec-path-from-shell? –

Répondre

0

Il y a un joli utilitaire appelé trousseau qui va commencer un ssh-agent/GPG-agent, puis vider l'env vars dans un fichier. Les shells peuvent simplement trouver le fichier pour obtenir les variables, et d'autres programmes comme Emacs peuvent analyser le fichier pour obtenir les variables. Pour Emacs, il existe un paquet keychain-environment dans Melpa.

# .bash_profile 
type keychain >&/dev/null \ 
    && keychain --agents ssh 

# .bashrc 
[ -f $HOME/.keychain/$HOSTNAME-sh ] \ 
    && . $HOME/.keychain/$HOSTNAME-sh 

;; init.el 
(when (require 'keychain-environment nil 'noerror) 
    (keychain-refresh-environment))