Ich habe einen systemd-Dienst, der ein PHP-Skript aufruft, das tmuxbeim Booten eine Sitzung erstellt.
Global gesehen habe ich die aktuellste Version tmuxfür die Distribution (V>=2.5).
Das Skript USERhat eine Version $HOME/bin/tmuxvon 2.0
Ich muss dafür die Binärdatei im $HOME des Benutzers systemdverwenden . Ich habe die Variablen USER und GROUP in der systemd-Servicedatei festgelegt, aber es scheint, als würde die global installierte Binärdatei aufgerufen.tmux
Ist es möglich, die Binärdatei, die für diesen Dienstaufruf aufgerufen werden soll, explizit festzulegen?
Wenn möglich, würde ich lieber nicht damit beginnen, den Pfad in der PHP-Datei selbst fest zu codieren.
Vielen Dank.
Antwort1
Sie könnten Folgendes PATHim systemd-Dienst fest codieren:
[Service]
Environment=PATH=/home/someUser/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Flexibler wäre PAM. Es ist ein ziemlicher Umweg im Vergleich zur einfachen Verwendung bash -c '....', aber mit PAM ist das möglich.
Erstellen Sie eine neue PAM-Konfiguration in /etc/pam.d(sagen wir /etc/pam.d/foo) und fügen Sie hinzu:
session required pam_env.so user_envfile=some-file user_readenv=1
Und in /home/someUser/some-filefügen Sie hinzu:
PATH DEFAULT=/home/someUser/bin:${PATH}
Natürlich können Sie den some-fileNamen auch sinnvoller anpassen, der Pfad user_envfilemuss jedoch relativ zum Home-Verzeichnis des Benutzers sein (des Benutzers, den Sie User=im Dienst festgelegt haben).
Fügen Sie dann in der Servicedatei im [Service]Abschnitt ( fooes handelt sich um die zuvor erstellte Datei /etc/pam.d) Folgendes hinzu:
PAMName=foo
Wenn Sie nun den Dienst starten (nach dem Neuladen usw.), werden die sessionModule ausgeführt, was in diesem Fall einfach ist/etc/pam.d/foopam_env. pam_envlädt Umgebungsvariablen aus /etc/environment, vorbehaltlich der Einschränkungen in /etc/security/pam_env.conf, und dann die Benutzerumgebung aus ~/some-file. Da PATHin auf einen Standardwert eingestellt ist /etc/environment, wird die Benutzerumgebung diesem Standardwert vorangestellt.
user_envfileHier ist der Standardwert von .pam_environment, der auch von der PAM-Konfiguration anderer Dinge wie SSH- oder LightDM-Anmeldung usw. gelesen wird. Ich habe hier eine andere Datei verwendet, falls Sie diese Dinge nicht beeinflussen möchten. Sie könnten die entfernen user_envfile=...und den Standardwert verwenden ~/.pam_environment. Sie könnten auch einfach eine vorhandene PAM-Konfiguration verwenden, in /etc/pam.dder vorhanden ist user_readenv=1, aber andere PAM-Module können unerwünschte Nebenwirkungen verursachen.
Antwort2
Es sieht furchtbar nach Hack aus, aber das Voranstellen eines $PATHUpdates scheint zu funktionieren.
Ich achte jedoch auf Nebenwirkungen …
Beispiel:
ExecStart=/bin/bash -c "PATH=/home/someUser/bin:$PATH exec /usr/bin/php /some/path/to/a/script.php"
Antwort3
Ich weiß, dass ich einen etwas veralteten Beitrag ausgrabe, aber auch ich habe versucht herauszufinden, wie ich die PATH-/Umgebungsvariablen so konfigurieren kann, dass der Scheduler automatisch ausgeführt wird, wenn der Server läuft.
Ich habe eine Lösung gefunden, die für mich unter Ubuntu 18.04 und 18.10 funktioniert
Ich habe eine ausführliche Beschreibung bereitgestellt, wie manInstallieren Sie Airflow und PostgreSQLim Backend auf den LinkHier.
**aus dem späteren Teil meines Artikels. Im Wesentlichen läuft es darauf hinaus, eine bestimmte Änderung an der Datei airflow-scheduler.system vorzunehmen.
Dies ist eine der Fallstricke bei einer Implementierung unter Ubuntu. Das Entwicklerteam, das Airflow erstellt hat, hat es so konzipiert, dass es auf einer anderen Linux-Distribution läuft. Daher muss eine kleine (aber wichtige) Änderung vorgenommen werden, damit Airflow automatisch ausgeführt wird, wenn der Server eingeschaltet ist. Die standardmäßigen systemd-Dienstdateien sehen zunächst folgendermaßen aus:
[Unit]
Description=Airflow scheduler daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service
[Service]
EnvironmentFile=/etc/sysconfig/airflow
User=airflow
Group=airflow
Type=simple
ExecStart=/bin/airflow scheduler
Restart=always
RestartSec=5s
[Install]
WantedBy=multi-user.target
Dies funktioniert jedoch nicht, da das Protokoll „EnvironmentFile“ unter Ubuntu 18 nicht funktioniert. Kommentieren Sie stattdessen diese Zeile aus und fügen Sie Folgendes hinzu:
Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Sie möchten wahrscheinlich zumindest für den Airflow Scheduler und wahrscheinlich auch für den Webserver eine systemd-Servicedatei erstellen, wenn Sie möchten, dass die Benutzeroberfläche ebenfalls automatisch gestartet wird. Tatsächlich möchten wir in dieser Implementierung beides, also werden wir zwei Dateien erstellen, airflow-scheduler.service und airflow-webserver.service. Beide werden in den Ordner /etc/systemd/system kopiert. Diese lauten wie folgt:
airflow-scheduler.service
[Unit]
Description=Airflow scheduler daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service
[Service]
#EnvironmentFile=/etc/default/airflow
Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
User=airflow
Group=airflow
Type=simple
ExecStart=/home/ubuntu/anaconda3/envs/airflow/bin/airflow scheduler
Restart=always
RestartSec=5s
[Install]
WantedBy=multi-user.target
#airflow-webserver.service
airflow-webserver.service
[Unit]
Description=Airflow webserver daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service
[Service]
#EnvironmentFile=/etc/default/airflow
Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
User=airflow
Group=airflow
Type=simple
ExecStart=/home/ubuntu/anaconda3/envs/airflow/bin/airflow webserver -p 8085 --pid /home/ubuntu/airflow/airflow-webserver.pid
Restart=on-failure
RestartSec=5s
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Nachdem beide Dateien mit dem Superuser-Kopierbefehl „sudo cp“ in den Ordner /etc/systemd/systemd kopiert wurden, ist es an der Zeit, den Zündschlüssel zu betätigen:
sudo systemctl Airflow-Scheduler aktivieren sudo systemctl Airflow-Scheduler starten sudo systemctl Airflow-Webserver aktivieren sudo systemctl Airflow-Webserver starten
Antwort4
In einem Dienst, den ich einrichtete (Apache Airflow), hatte ich eine Umgebungsdatei festgelegt.
In meiner /etc/systemd/system/airflowDatei hatte ich diese Zeile:
[Service]
EnvironmentFile=/etc/default/airflow
Beim Öffnen dieser Umgebungsdatei habe ich die Zeile hinzugefügt, die ich in meinem Fall benötigte:
SCHEDULER_RUNS=5
PATH=/opt/anaconda3/bin:$PATH
Fügen Sie hier die Pfade zu den ausführbaren Dateien hinzu, die für den Dienst erreichbar sein müssen, dann sollte alles klappen. Hat bei mir gut funktioniert.