气流when服务器- OAuth身份验证在作为系统服务运行时不起作用

Question

我们在Ubuntu 22.04上运行气流2.3.3。Airflow的and服务器使用针对Azure的OAuth身份验证(和授权)。当从命令行airflow webserver -D (以用户ubuntu的身份)调用气流when服务器时，这非常好。

现在，我们希望构建一个systemd服务，以便在服务器启动时自动运行气流网络服务器。这是我们的服务配置文件/lib/systemd/system/airflow-webserver.service

[Unit]
Description=Airflow webserver daemon
After=network.target
Before=airflow-scheduler.service

[Service]
EnvironmentFile=/home/ubuntu/airflow/airflow.env
User=ubuntu
Group=ubuntu
Type=simple
ExecStart=/usr/bin/python /home/ubuntu/.local/bin/airflow webserver -D
Restart=on-failure
RestartSec=5s
PrivateTmp=false
StandardOutput=file:/home/ubuntu/airflow/logs/webserver/systemd-stdout.log
StandardError=file:/home/ubuntu/airflow/logs/webserver/systemd-errout.log

[Install]
WantedBy=multi-user.target

airflow.env保存以下变量：

export AIRFLOW_CONFIG=/home/ubuntu/airflow/airflow.cfg
export AIRFLOW_HOME=/home/ubuntu/airflow

当启动服务(sudo systemctl start airflow-webserver)时，we服务器确实会出现并显示气流的注册屏幕，但是当涉及到针对Azure的身份验证时，我们会遇到一些超时。

我不知道从命令行运行vs.服务器与将其作为系统服务运行之间的区别。如何确保systemd使用与从命令行运行时完全相同的配置来运行when服务器？

Update (2022-10-04)：sudo journalctl -f -u airflow-webserver的输出看起来很好--有一些关于第三方插件的提示，我们可以使用igonore (因为在从命令行运行we服务器时会出现相同的消息)：

ubuntu@xxx:~/airflow$ sudo journalctl -f -u airflow-webserver
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,734] {init_appbuilder.py:515} INFO - Registering class RedocView on menu
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,734] {init_appbuilder.py:515} INFO - Registering class RedocView on menu
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,735] {baseviews.py:302} INFO - Registering route /redoc ('GET',)
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,735] {baseviews.py:302} INFO - Registering route /redoc ('GET',)
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: /home/ubuntu/.local/lib/python3.10/site-packages/airflow/plugins_manager.py:256 DeprecationWarning: This decorator is deprecated.
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: In previous versions, all subclasses of BaseOperator must use apply_default decorator for the `default_args` feature to work properly.
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: In current version, it is optional. The decorator is applied automatically using the metaclass.
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: /home/ubuntu/.local/lib/python3.10/site-packages/airflow/providers_manager.py:614 DeprecationWarning: The provider airflow-provider-vaultspeed uses `hook-class-names` property in provider-info and has no `connection-types` one. The 'hook-class-names' property has been deprecated in favour of 'connection-types' in Airflow 2.2. Use **both** in case you want to have backwards compatibility with Airflow < 2.2
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,780] {providers_manager.py:623} WARNING - The connection_type 'snowflake' has been already registered by provider 'airflow-provider-vaultspeed.'
Oct 04 10:07:48 ip-10-194-84-28 airflow[1508]: [2022-10-04 10:07:48,801] {providers_manager.py:623} WARNING - The connection_type 'snowflake' has been already registered by provider 'airflow-provider-vaultspeed.'

在分析htop中的过程时，我确实看到了一些不同之处(请注意，从airflow.cfg中保存参数的gunicorn子进程)。

从命令行运行(身份验证工作正常)

​

从systemctl运行(身份验证不起作用)：

​

Answer 1

我发现，尽管服务是以User=和Group=指定的用户身份运行的，但默认情况下，它缺少登录shell中的大多数环境变量(例如，由~/.bashrc设置或/etc/profile.d/中的任何脚本)。

我们最终找到了该解决方案，允许使用与直接从交互式shell直接运行时完全相同的环境变量启动服务：

ExecStart=/bin/bash -l -c 'exec "$@"' _ /some/folder/my-script.sh

bash -l启动一个登录shell并执行-c之后提供的命令。我不太确定是否真的需要exec部分，或者脚本路径是否可以直接在-c之后运行-但是这个解决方案对我们来说很好……