使用bluesky队列服务器

启动与停止运行引擎管理器

队列服务器的核心组件是 Run Engine 管理器，它可以作为应用程序或服务来启动。以应用程序运行RE管理器较为简单，建议用于评估、测试和演示环境。生产系统则更倾向于将 RE Manager 作为服务来运行。

以应用程序方式运行RE管理器

教程<<启动队列服务器>>中演示了以应用程序方式启动RE管理器，其中包括激活已安装队列服务器的 Conda 环境，并使用适当的参数集运行 start-re-manager。启用某些选项可能还需要在启动 start-re-manager 之前设置相应的环境变量。

默认情况下，只需在提示符下输入以下命令即可使用默认选项集启动RE管理：

$ start-re-manager

大多数演示（基于软件包附带的模拟启动代码）使用默认选项就已足够。如果某个演示涉及对控制台输出的远程监控，则需使用 --zmq-publish-console 选项激活将控制台输出发布到 0MQ 套接字的功能:

$ start-re-manager --zmq-publish-console ON

通过设置路径为有代码文件的路径, 可以配置管理器装载自定义启动代码:

$ start-re-manager --zmq-publish-console ON --startup-dir <path-to-directory-with-files>

RE管理器会自动创建 Bluesky Run Engine (RE) 和 数据代理(db) 的实例。生产环境中的脚本通常会创建自定义的 RE 和 db 实例。在这种情况下，调用 RE Manager 时必须使用 --keep-re 选项，以防止 RE Manager 覆盖已有的 RE 和 db 实例:

$ start-re-manager --zmq-publish-console ON --startup-dir <path-to-directory-with-files> --keep-re

这是RE管理器的最小配置，足以满足实验控制中 Queue Server 的实际使用需求。为生产系统配置 RE Manager 时可能还需要其他设置。参数的详细说明请参阅 start-re-manager 文档。

以应用程序方式运行的RE管理器可以通过在终端中按 Ctrl-C 来关闭。

以服务运行RE管理器

以下示例演示了如何以用户服务（无需 root 权限）的方式启动 RE管理器。该管理器将以最基本的配置启动。您可以根据需要，通过设置环境变量以及 start-re-manager 的附加参数来修改配置。设置此服务需要两个文件：服务配置文件以及启动 RE管理器的脚本。请将文件路径和脚本文件中的 <user-name> 替换为正确的用户名。同时，假定队列服务器已基于 miniconda3 安装在 bs-qserver 环境中。请根据实际系统配置修改脚本和路径。

服务配置文件

# File: ~/.config/systemd/user/queue-server.service [Unit] Description=Bluesky Queue Server [Service] ExecStart=/usr/bin/bash /home/blctrl/qs_startup/queue-server.sh [Install] WantedBy=default.target Alias=queue-server.service

用于启动RE管理器的脚本:

# File: ~/qs_startup/queue-server.sh source "/home/blctrl/miniforge3/etc/profile.d/conda.sh" conda activate apsbits_env start-re-manager --zmq-publish-console ON --console-output OFF

启动这个服务:

(apsbits_env) blctrl@blctrl-s3:~$ systemctl --user start queue-server

检查服务的状态:

(apsbits_env) blctrl@blctrl-s3:~$ systemctl --user status queue-server ● queue-server.service - Bluesky Queue Server Loaded: loaded (/home/blctrl/.config/systemd/user/queue-server.service; disabled; vendor preset: enabled) Active: active (running) since Tue 2026-04-28 12:31:12 CST; 2s ago Main PID: 24122 (bash) Tasks: 15 (limit: 9162) Memory: 58.6M CPU: 1.581s CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/queue-server.service ├─24122 /usr/bin/bash /home/blctrl/qs_startup/queue-server.sh ├─24128 /home/blctrl/miniforge3/envs/apsbits_env/bin/python3.11 /home/blctrl/miniforge3/envs/apsbits_env/bin/start-re-manager --zmq-pub> └─24135 /home/blctrl/miniforge3/envs/apsbits_env/bin/python3.11 /home/blctrl/miniforge3/envs/apsbits_env/bin/start-re-manager --zmq-pub> 4月 28 12:31:12 blctrl-s3 systemd[993]: Started Bluesky Queue Server.

停止服务:

(apsbits_env) blctrl@blctrl-s3:~$ systemctl --user stop queue-server

Run Manager 已配置为不打印任何控制台输出，而是将控制台输出发布到 0MQ 套接字。有关如何远程查看控制台输出的说明，请参阅“控制台输出的远程监控”一节以及“远程监控 RE Manager 控制台输出”教程。所演示的过程可根据实际运行需求进行修改。

使用API关闭RE管理器

RE Manager 可以通过发送"manager_stop"API 请求以编程方式停止。该 API 的参数允许选择操作是在安全模式下执行(如果 RE Manager 不处于空闲状态则拒绝请求)，还是禁用安全模式（即使 RE Manager 正在执行操作，例如某个计划正在运行，也会强制关闭RE管理器）。该 API 主要用于自动化系统测试，不应通过客户端应用程序暴露给普通用户。

RE管理器的状态监视

在任何使用使用'status' API可以加载RE管理器的状态. API返回一个状态参数的字典:

(apsbits_env) blctrl@blctrl-s3:~$ qserver status Arguments: ['status'] 12:37:58 - MESSAGE: {'msg': 'RE Manager v0.0.23', 'items_in_queue': 0, 'items_in_history': 6, 'running_item_uid': None, 'manager_state': 'idle', 'queue_stop_pending': False, 'queue_autostart_enabled': False, 'worker_environment_exists': False, 'worker_environment_state': 'closed', 'worker_background_tasks': 0, 're_state': None, 'ip_kernel_state': None, 'ip_kernel_captured': None, 'pause_pending': False, 'run_list_uid': '5b840505-40ad-4927-9616-b5b941e9421b', 'plan_queue_uid': '703b1d5a-66c2-4a66-90b5-20f3052371cd', 'plan_history_uid': '1f59be8d-b5f9-4da6-a4c2-c79ee09a6d0b', 'devices_existing_uid': '479563bc-91e9-43cf-81c3-2c8e7b89b4d5', 'plans_existing_uid': 'a9a5ecd9-9b28-4f30-a914-d98772a0850b', 'devices_allowed_uid': 'e9361634-c293-4ff3-afa2-f92f9ef1e4fa', 'plans_allowed_uid': '8dddb3d6-8207-429c-9841-42db62ba4fa3', 'plan_queue_mode': {'loop': False, 'ignore_failures': False}, 'task_results_uid': '081646bf-fb83-4cc7-9356-10fd98ebedb2', 'lock_info_uid': '7bd8224e-0052-437b-95dc-b7fcf7d514f5', 'lock': {'environment': False, 'queue': False}}

参数 msg 包含当前运行的 RE管理器的版本信息。RE管理器和运行引擎的状态通过参数 manager_state 和 re_state 返回。其中 re_state 表示运行引擎的真实状态，该状态从 RE Worker 环境传播而来(状态更新可能存在短暂延迟)。布尔参数 worker_environment_exists 在环境已打开时为 True，否则为 False。

名称以 _uid 结尾的参数(如 plan_queue_uid)包含了各自对应对象的唯一标识符(UID)，这些对象每次更新时其 UID 都会改变。例如，每当队列因响应客户端 API 请求或因内部进程而更新时，plan_queue_uid 都会随之改变。通过跟踪 UID 的变化，并仅在 UID 发生改变时才下载相应的对象，这比持续轮询对象本身更高效。

参数 status_uid 在每次状态变更时都会更新，可用于检测其他状态参数的变化。参数 time 是状态最近一次更新的时间戳。在某些情况下，状态可能长时间不更新。例如，只要RE管理器保持空闲状态，且未对队列或历史记录执行任何操作，那么 status_uid 和 time 就会保持不变。

有关状态参数的详细说明，请参阅有关 status API 的文档。

打开和关闭RE Worker环境

在启动队列、执行计划或函数，或上传脚本前, 必须先打开RE Worker环境 。打开环境的操作包括：创建一个独立的进程(Worker 进程)和加载启动代码。启动代码加载完成后，RE管理器会根据 Worker 命名空间中的内容更新现有和可用的设备和计划列表。通过发送'environment_open'API 请求来发起打开环境的过程；并且若请求被接受，则等待该过程完成。

可以通过'script_upload'API 上传并执行脚本来远程更改环境内容，从而在Worker命名空间中添加、删除或修改对象。一旦环境关闭，通过上传脚本引入的更改将会丢失。

与打开环境类似，关闭或销毁环境的操作通过发送'environment_close'或'environment_destroy' API 请求，并等待操作完成来发起。'environment_close'API 适用于正常运行期间。只有在RE管理器处于空闲状态(即当前没有执行任何计划或任务)时才能关闭环境。销毁环境的操作通过杀死 Worker 进程，可在环境卡死(例如执行无限循环)时尝试恢复RE管理器。该操作不安全，应仅在万不得已时使用。

管理计划队列

RE管理器支持对队列进行操作，允许客户端添加、移动、移除和替换队列项。所有队列操作都可在任何时候执行。队列内容可通过'queue_get'API 获取，该 API 返回队列项列表 (items)；若队列正在运行，还会返回当前运行项 (running_item)。当前运行项不被视为队列的一部分，且不能在大多数队列操作中使用。

队列支持两种类型的项：计划（在worker环境中执行的 Bluesky 计划）和指令。指令用于控制队列。目前仅支持一种指令('queue_stop')。

添加('queue_item_add')、移动('queue_item_move')和移除('queue_item_remove')项的操作都有对应的批量版本：'queue_item_add_batch'、'queue_item_move_batch'和' queue_item_remove_batch'。批量操作接受项列表（而非单个项），并且保证对队列执行原子操作。

队列操作支持多种定位队列项的方式。可以使用项位置(参数 pos)来定位项，该参数可以是项的正向或反向索引，也可以是字符串字面量（'front' 或 'back'）。使用 pos='front' 或 pos='back' 将项插入到队列前端或后端或删除对头或队尾的项时，可以保证产生预期结果；而使用索引仅在队列未运行时才是可靠的(如果队列正在运行，反向索引应该能可靠工作)，并且需要没有其他客户端正在修改队列。另一种定位方式是使用项的 UID 来唯一标识队列项。队列操作允许通过 UID 选择项，并在具有给定 UID 的项之前或之后插入项(参数 uid、before_uid 和 after_uid)。批量操作接受项 UID 列表(参数 uids)，以选择现有项并可能重新排序。

可随时使用'queue_clear'API 清空队列。如果队列正在运行，清空队列不会影响当前运行项或队列状态：如果在当前运行的计划完成时没有添加新项，则队列会自动停止。

有关完整的 API 列表，请参阅《ZMQ 通信 API 支持的方法》和《向队列添加项》教程。

管理计划历史

计划历史包含已完成的计划列表以及执行结果(开始和结束时间、完成状态、错误消息以及失败时的回溯信息)。可以使用'history_get' API 加载计划历史，使用'history_clear' API 清空计划历史。计划历史的设计并非无限增长，应定期清空以避免性能问题。

控制队列和计划的执行

如果 RE Worker 环境已打开，则可以使用'queue_start'启动计划队列，否则 API 请求将失败。队列中的计划执行完毕后会自动停止。用户可以通过发送'queue_stop' API 请求来要求 RE管理器停止队列。一旦 RE管理器收到该请求，它会等待当前正在执行的计划完成，然后停止队列。停止队列的待处理请求会反映在 RE管理器 的状态中(queue_stop_pending)，并且可以在队列仍在运行时随时通过发送'queue_stop_cancel'请求来取消该请求。

另一种停止队列的方法是将'queue_stop'指令添加到队列中的期望位置。RE管理器从队列中弹出该指令并停止执行。队列执行可以在后续项处随时恢复。

可以使用're_pause'API 请求中断当前正在运行的计划的执行。该 API 允许请求延迟暂停(计划运行到下一个检查点)或立即暂停。更多详细信息请参阅 Bluesky 文档的中断部分。暂停的计划可以恢复、停止、取消或终止。请注意，停止的计划被视为成功完成，而取消和终止的计划则被视为失败。

中断当前计划可以立即停止队列：可以通过发送're_pause' API 请求来暂停计划(这将暂停计划执行, 这可能足够解决某些技术困难), 然后使用're_stop'API 停止，或使用're_abort' API取消(后者会将计划推到队列顶部)。

队列可以在启用/禁用的LOOP模式下运行(参见'queue_mode_set')。如果LOOP模式被禁用(正常模式)，项会从队列前端弹出并在Worker(计划)或管理器(指令)中执行。成功完成的计划(包括已停止的计划)会从队列中永久移除，并在完成后添加到计划历史中。如果计划失败、取消或终止，它会被推送到队列前端，并与执行结果(错误消息和回溯信息)一起添加到历史中，同时队列执行会自动停止。可以通过启用 IGNORE_FAILURES 模式来改变此行为，在该模式下，即使当前计划失败，服务器也会继续执行队列中的下一个计划。如果启用了 LOOP 模式，操作略有不同：成功执行(或停止)的计划和指令会被添加到队列的后端，从而允许客户端无限重复一系列计划。在所有模式下，停止的计划都被视为成功。停止一个计划也会停止队列的执行。

请参阅教程《启动和停止队列》以及《与运行引擎交互》。

计划的立即执行

RE管理器支持不将计划放入队列而直接执行。可以使用'queue_item_execute' API提交计划以立即执行。仅当 RE管理器处于空闲状态时才会接受该请求，否则请求被拒绝且计划被丢弃。请求通过验证并被接受后，该计划会被传递给RE Worker立即执行。与来自队列的项类似，该计划会被分配一个项UID，并可通过相同的 API进行跟踪。在完成后，该计划会连同执行结果一起添加到历史中。该计划永远不会被添加到队列中，即使它执行失败或队列处于循环模式也是如此。如果队列中已有其他计划，其内容保持不变。提交计划以立即执行并不会启动现有队列的执行。

请参阅教程《计划的立即执行》。

执行函数

RE管理器允许在RE Worker环境中启动函数执行。客户端可以使用'function_execute' API 提交启动函数执行的请求，该API接受函数名称和与队列项相同格式的参数。客户端只能访问存在于RE Worker命名空间中(例如在启动脚本或上传的脚本中定义)且由其用户组权限允许的函数(请参阅《配置用户组权限》)。这些函数可以访问命名空间中的所有对象，并用于更改对象状态或读取对象状态，并将结果返回给客户端。虽然运行任意代码可能会破坏环境，但可以通过权限配置仅允许用户访问一个或几个精心设计的函数，或者阻止对任何函数的访问（默认设置），从而保证系统的安全性。

一旦API请求被RE管理器接受，该任务会被分配一个任务UID(task_uid)，并作为 API 响应参数之一返回。通过任务UID可以使用'task_status'和'task_result' API跟踪任务的执行情况。函数执行完成后，任务会包含函数的返回值(成功时)以及错误消息和回溯信息(失败时)。

函数可以作为前台任务或后台任务启动。有关运行和监控任务的详细信息，请参阅《运行任务》。

请参阅教程《执行函数》。

上传脚本

RE管理器为用户提供了上传并在Worker命名空间中执行Python脚本的功能。'script_upload' API 接受以字符串形式表示的脚本，该脚本通过 0MQ上传到RE管理器，传递给worker环境并执行。脚本作为任务执行，API返回的 task_uid 可用于监控任务状态并下载结果，以指示脚本是否成功完成，并在失败时包含错误消息和回溯信息。

脚本可以包含任意 Python 代码，并在worker环境中执行。该代码可以完全访问 worker 命名空间，并可以修改、替换或创建新的对象，包括函数、设备和计划。例如，上传的脚本可能包含一个新计划的代码，该计划随后在worker命名空间中可用；或者包含对现有计划修改后的代码，从而替换命名空间中的原计划。默认情况下，在每个脚本执行后，现有和允许的计划及设备列表会更新。新的计划和设备会立即对具有相应权限的用户可用(请参阅《配置用户组权限》)。

变量RE和d 预留给 Bluesky运行引擎和数据代理的实例。默认情况下，即使脚本包含相应代码(脚本可以自由使用这些对象)，worker命名空间中现有的RE或db对象也不会被替换。此限制是为了防止意外更改命名空间而导致RE管理器失败。为了允许脚本替换RE和db，需要在调用 API 时设置 update_re=True。如果上传的脚本不包含新的或修改后的计划或设备，则无需更新相应的列表；若设置 update_lists=False，操作可以更高效地执行。

脚本可以作为前台任务或后台任务执行。有关运行和监控任务的详细信息，请参阅《运行任务》。

请注意:脚本可以包含任意代码。用户和开发者应仔细考虑在worker命名空间中执行什么代码以及它如何影响worker环境的状态。例如，一个执行计划的脚本可以作为前台任务成功启动并完成，从而绕过队列管理的所有机制，但这并不建议这样做。

上传的脚本可以导入服务器上可用的模块。脚本也可以包含“本地”导入。例如，如果根目录下有一个子目录 mod，其中包含一个 Python 文件 my_module.py，则可以通过以下方式导入该代码：

import mod.my_module

根目录是启动目录（直接传递给 start-re-manager，或根据传递的或默认的 IPython 目录和/或配置文件名称确定），或者是当服务器使用相应选项启动时包含启动脚本的目录。上传的脚本中不支持相对导入（例如 from .mod import my_module）。

运行任务

任务是用于RE Worker命名空间中函数和脚本执行的远程监控。每个任务都会被分配一个 UID(task_uid)，该UID由启动任务的API返回，可用于监控任务状态并在完成后加载结果。例如，调用'function_execute' API 启动一个函数function_sleep(在演示启动代码中定义)的执行时，会返回该 UID。

(apsbits_env) blctrl@blctrl-s3:~$ qserver function execute '{"name": "function_sleep", "args": [100], "kwargs": {}}' Arguments: ['function', 'execute', '{"name": "function_sleep", "args": [100], "kwargs": {}}'] 10:50:51 - MESSAGE: {'success': True, 'msg': '', 'item': {'name': 'function_sleep', 'args': [100], 'kwargs': {}, 'user': 'qserver-cli', 'user_group': 'primary', 'item_uid': 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6'}, 'task_uid': 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6'}

用任务UID 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6'调用'task_status'和'task_result'返回此任务当前状态的信息以及在任务结束后, 任务执行的结果:

(apsbits_env) blctrl@blctrl-s3:~$ qserver task status e7f64792-60bd-44bb-a331-0e2a1bd2f4a6 Arguments: ['task', 'status', 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6'] 10:51:06 - MESSAGE: {'success': True, 'msg': '', 'task_uid': 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6', 'status': 'running'} (apsbits_env) blctrl@blctrl-s3:~$ (apsbits_env) blctrl@blctrl-s3:~$ qserver task status e7f64792-60bd-44bb-a331-0e2a1bd2f4a6 Arguments: ['task', 'status', 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6'] 10:53:17 - MESSAGE: {'success': True, 'msg': '', 'task_uid': 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a6', 'status': 'completed'}

return_value是函数的返回值(对于脚本来说始终为 None)，msg 和 traceback 是在任务失败时表示错误消息和完整回溯信息的字符串。

(apsbits_env) blctrl@blctrl-s3:~$ qserver task result e7f64792-60bd-44bb-a331-0e2a1bd2f4a Arguments: ['task', 'result', 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a'] 10:53:46 - MESSAGE: {'success': True, 'msg': '', 'task_uid': 'e7f64792-60bd-44bb-a331-0e2a1bd2f4a', 'status': 'not_found', 'result': {}}

函数和脚本可以作为前台任务和后台任务执行。前台任务在RE Worker进程的主线程中执行。只有当RE Manager处于空闲状态(即没有其他前台任务或计划正在运行)时才能启动前台任务。前台任务启动后，RE管理器的状态会变为 'executing_task'，这会阻止其他前台任务或计划的启动。后台任务在独立的后台线程中执行，可以随时启动，并且不会阻塞前台任务或计划的执行。任意合理数量的后台任务可以同时运行。后台任务的数量作为RE管理器状态 'status' 的一个参数返回。

(apsbits_env) blctrl@blctrl-s3:~$ qserver status Arguments: ['status'] 11:03:01 - MESSAGE: {... 'manager_state': 'executing_task', ... 'worker_environment_state': 'executing_task', 'worker_background_tasks': 0, ... 'task_results_uid': '94e82726-a95e-457d-8b87-e5bf01e0c03d', ... }

参数'task_results_uid'在每次有新任务启动或任务执行完成时都会更新。等待一个或多个任务完成的应用程序可以等待该 UID 发生变化，然后再检查每个任务的状态。考虑到应用程序可能出于其他目的而监控管理器状态，监控'task_results_uid'可能比持续轮询每个任务的状态更高效。

请注意:任务结果在服务器上仅存储有限时间，之后会被删除。目前，任务完成后的过期时间为 2 分钟，但将来可能会参数化配置。
请注意:后台任务在后台线程中执行。确保线程安全是软件或工作流开发者的责任。前台任务在主线程中逐一执行，不会引入与线程安全相关的风险。

锁定RE管理器

用户和客户端应用程序可以临时锁定RE管理器。当管理器被锁定时，用户只有在 API 请求中传递锁键才能访问某些API组。锁键是锁定RE管理器的用户选择的任意字符串，在管理器解锁前一直有效。该键可以共享给需要控制已锁定管理器的其他用户。锁状态存储在 Redis 中。重启管理器不会重置锁。如果管理器被锁定，则需要使用有效的锁键来解锁。此外，可以通过环境变量 QSERVER_EMERGENCY_LOCK_KEY_FOR_SERVER设置紧急密钥。紧急键允许在锁键丢失时解锁管理器，但不能用于控制已锁定的RE管理器。

'lock' API用于锁定那些控制RE Worker环境和/或队列的 API。锁定不影响只读API，因此当管理器被锁定时，监控客户端应用程序仍能继续工作。锁定环境和队列所影响的 API 完整列表，请参阅 'lock' API 的文档。

锁的设计并非用于访问控制。典型使用场景包括：

• 束线科学家或现场用户在进入实验棚屋更换样品前锁定环境。这可以防止远程用户、自动化代理等打开/关闭环境、启动队列以及执行计划和任务。如有必要，锁定环境的科学家仍可使用锁键执行这些操作，而无需解锁管理器。由于队列未被锁定，远程用户和自动化代理仍然可以自由编辑队列或向队列添加计划。
• 束线科学家进行维护或校准时，同时锁定环境和队列，以独占管理器的控制权。

用于控制和监控管理器锁状态的 API：

• lock——使用锁键锁定环境和/或队列。该 API 还需提供锁定管理器的用户名(必填)以及给其他用户的文本备注(可选)。这些信息将作为锁信息的一部分返回，并包含在所有相关的错误消息中。
• unlock——使用有效的锁键(必须与锁定管理器时的锁键相同)或紧急锁密钥(如果设置了)解锁管理器。如果锁密钥丢失且未设置或不知道紧急密钥，可以使用 qserver-clear-lock 命令行工具清除锁，然后重启RE管理器应用程序或服务。
• lock_info——获取管理器的锁状态。锁状态会被分配一个 UID，每次状态变更时该UID都会更新。该UID包含在管理器状态（status API）中，从而简化了锁状态的监控。管理器状态中还包含lock参数，用于指示环境和/或队列当前是否被锁定。

有关使用命令行工具锁定和解锁RE管理器的操作，请参阅教程《锁定RE管理器》。

请注意: 'lock' API控制对其他 API 的访问权限，而非服务器的内部运行。例如，如果服务器正在执行队列，那么管理器被锁定后，队列仍会继续运行，直到计划执行完毕或被停止。

队列自动启动模式

RE管理器支持队列自动启动模式。在自动启动模式下，只要队列非空且管理器和工作进程处于正确的状态，管理器就会自动开始执行队列。例如，如果在队列为空时启用了自动启动模式，添加一个队列项将自动启动队列执行。一旦队列中的项执行完毕，管理器会切换到空闲状态，但当更多项被添加到队列时，队列会自动重新启动。如果在添加计划时管理器正忙于执行其他任务(脚本或函数)，则在当前任务完成后立即重新启动队列。

通过用enable=True调用'queue_autostart' API 来启用自动启动模式，用enable=False使用相同的 API并来禁用自动启动模式。该模式可以随时启用，即使队列当前无法启动(例如环境已关闭)。管理器会自动监控状态，并在可能时启动队列(例如一旦环境打开)。一旦用户停止队列(通过插入 'queue_stop'队列指令或调用'queue_stop' API)或者计划被停止/暂停/取消或失败(除非启用了 ignore_failures 队列模式)，自动启动模式会被自动禁用。

自动启动模式也可以通过命令行界面启用和禁用:

qserver queue autostart enable qserver queue autostart disable

用IPython内核运行RE Worker

队列服务器可以配置为在IPython内核中运行工作进程的执行环境。该内核在工作进程内创建，并用于执行计划、函数和脚本。在IPython模式下，工作进程可以加载带有IPython特有功能(例如魔法命令、user_ns 等)的启动代码和脚本。用户还可以绕过RE管理器，直接使用Jupyter Console连接到该内核。

有关IPython内核配置的更多信息，请参阅：IPython内核配置。

用IPython模式启动RE管理器

通过向start-re-manager传递--user-ipython-kernel=ON, 设置config参数worker/user_ipython_kernel: True或者环境变量QSERVER_USE_IPYTHON_KERNEL=tRUE配置RE管理器使用IPython内核.

指定IPython内核IP地址

使用start-re-manager的--ipython-kernel-ip参数, 设置 QSERVER_IPYTHON_KERNEL_IP 环境变量，或通过config参数 worker/ipython_kernel_ip 来设置IPython内核的IP地址通过。参数值可以是 'localhost'(默认值)、'auto'，或者一个表示运行内核的主机有效网络 IP 地址的字符串，例如 127.0.0.1或192.168.50.49。如果 IP 地址是 'localhost'（默认值）或 127.0.0.1，内核将不接受来自其他主机的连接。如果参数设置为 'auto'，队列服务器会尝试自动确定主机的网络IP地址并将其传递给内核。如果网络 IP 地址正确确定，内核将接受来自其他主机的连接。如果自动模式失败，可以将正确的 IP 地址显式传递给服务器。传递给内核的IP地址会作为连接信息的一部分返回，客户端应用程序使用该信息连接到内核(请参见'config_get' API)。

还可以使用其他参数来设置IPython内核连接文件的目录和名称，以及内核用于通信的0MQ端口号。更多详细信息请参阅《IPython 内核配置》。

指定启动代码的位置

在这种模式下，RE Worker会启动一个嵌入式IPython内核，并在内核初始化期间加载启动代码、IPython配置以及IPython历史记录。启动代码的位置由start-re-manager的--startup-profile、--startup-module、--startup-script和--startup-dir参数决定(对应配置文件中的 startup/startup_profile、startup/startup_module、startup/startup_script 和 startup/startup_dir参数)。内核会在<ipythondir>/profile_<profile_name>/startup目录下查找启动代码，其中 <ipythondir> 是环境变量 IPYTHONDIR 的值(它决定了 IPython 配置文件的存放位置，默认位置为 ~/.ipython)，而profile_name是通过--startup-profile参数传递的名称。IPython配置文件的位置也可以通过--ipython-dir参数指定，该参数会覆盖 IPYTHONDIR 环境变量。此外，启动配置文件的位置也可以通过--startup-dir参数指定。如果RE管理器配置为使用IPython内核，那么启动目录必须符合标准模式(<ipythondir>/profile_<profile_name>/startup)，以便能够成功解析出配置文件名和 IPython 目录。

除了IPython配置文件中的启动代码外，如果指定了脚本路径或模块路径，IPython内核还可以加载启动脚本或启动模块。这一行为与基于Python的Worker不同：后者在指定了脚本路径或模块名称时，不会尝试加载配置文件中的启动文件。如果不希望加载启动代码，可以创建一个startup目录为空的配置文件，并将该配置文件名传递给RE管理器。如果指定了--startup-script或--startup-module，但未传递配置文件名，则会加载默认的IPython配置文件($IPYTHONDIR/profile_default).

设置Matplotlib后端

如果RE管理器在本地机器上运行且启用了 IPython 模式，则可以直接从 worker 环境中进行进程内实时绘图。这一功能对于那些希望保留现有基于 IPython 的交互式工作流程，但可能希望将 REPL 交互与环境的 API 控制(例如用于 GUI 或自主控制)混合使用的用户来说可能很方便。为了启用绘图，必须使用start-re-manager的--ipython-matplotlib参数或worker/ipython_matplotlib配置参数来设置合适的 Matplotlib 后端。该参数直接传递给IPython内核，并接受与 ipython的--matplotlib参数相同的一组值。后端默认设置为 agg，这会禁用绘图，并在远程服务器上运行RE管理器时应使用此设置。请选择其他合适的后端(例如 qt5)以启用绘图。

IPython内核状态的监控

正在运行的 IPython 内核状态可以通过检查RE管理器状态的ip_kernel_state参数来监控(参见 'status' API）。状态参数ip_kernel_captured指示正在运行的内核是否被RE管理器“捕获”。如果内核正在运行由管理器启动的前台任务，则该参数为True，否则为False。当内核被管理器“捕获”时，外部客户端无法与之交互。如果环境未运行或者worker未使用IPython内核，则这两个参数均为None。

下载内核连接信息

随时可以通过向RE管理器发送config_get API请求来下载正在运行的 IPython 内核的连接信息(命令行命令：qserver config)。

(apsbits_env) blctrl@blctrl-s3:~$ qserver config Arguments: ['config'] 12:38:25 - MESSAGE: {'success': True, 'msg': '', 'config': {'ip_connect_info': {}}}

连接信息(ip_connect_info键)是一个字典，其中包含运行内核的主机的网络 IP 地址、0MQ端口号等信息。如果内核因任何原因未运行，则该连接信息字典为空。由于每次关闭环境时旧内核会被销毁，而每次打开环境时会创建新内核，因此必须为新的环境重新下载更新后的连接信息。qserver-console命令行工具会自动从RE管理器加载连接信息，并启动连接到该内核的Jupyter控制台。

使用Jupyter控制台连接到正在运行的IPython内核

一旦IPython内核在worker进程中运行(即RE管理器启动时启用了IPython选项且环境已打开)，用户就可以通过运行qserver-console命令行工具使用Jupyter控制台直接连接到该内核。该工具会从RE 管理器加载连接信息，并将其传递给Jupyter Console应用程序。

请注意: 如果内核正在运由RE管理器启动的行任何前台任务(计划, 函数, 脚本), 在任何结束并且'被捕获的'内核被释放前, Jupyter Console将保持无响应.

Jupyter Console 的工作方式与IPython终端类似，不同之处在于关闭控制台不会中断从控制台启动的任务。例如，从控制台手动启动的计划在控制台关闭后会继续运行。该计划的执行将不受RE 管理器的管理，但计划的输出会包含在RE管理器的控制台输出中，并流式传输给所有已订阅的消费者。

请注意: 使用Ctrl-D关闭Jupyter Console. 在Jupyter控制台中输入quit或exit将关闭内核并且引起worker环境关闭.

更新Worker环境缓存

直接通过Jupyter Console连接到IPython内核的用户可以更改worker命名空间的内容，包括在命名空间中添加、删除或修改计划与设备等操作。若要令RE管理器感知这些变更，并使更新后的计划和设备反映在现有/允许的计划和设备列表中，请调用'environment_update' API。

中断 IPython 内核

可以使用'kernel_interrupt' API 中断 IPython 内核（相当于 Ctrl-C）。默认情况下，如果在RE 管理器执行通过管理器启动的计划或前台任务(脚本或函数)时调用该 API，API 调用会失败。该 API 的参数 interrupt_plan 和 interrupt_task 可用于覆盖默认行为。

请注意:虽然通过发送一次中断（延迟暂停）或两次中断（立即暂停）可以暂停计划，但使用 're_pause' API是暂停通过RE管理器或直接使用Jupyter Console启动的计划的更优方式。