ubuntu无托盘通知停留时长设置，notify-send的-t参数需用毫秒（如-t 5000=5秒），gnome不提供图形化时长配置，cron中-t常因会话环境失效，可靠方案是改用zenity等替代工具。
Ubuntu 没有“托盘通知停留时长”这个独立设置项——它只有桌面横幅通知（notify-send）的显示时长，且由应用自身或系统通知服务控制，无法像 UOS 那样在图形界面里为每个应用单独设秒数。
notify-send 的 -t 参数只接受毫秒，不是秒
很多人误以为 -t 5 是“5秒”，结果通知一闪就消失。实际必须写成毫秒单位：-t 5000 才是 5 秒。
常见错误现象：通知弹出后不到 1 秒就消失，基本就是漏写了两个零。
参数差异：
• -t 0 表示“永不自动关闭”，但 GNOME 默认会忽略该值，仍按约 5 秒处理（除非应用主动支持持久化）；
• 大于 10000（10 秒）的值在 GNOME 中可能被截断，实测上限通常为 10000；
• 如果用脚本调用，记得加引号避免空格解析错误，比如：notify-send "标题" "内容" -t 8000。
GNOME 桌面不提供全局/ per-app 通知时长图形开关
Ubuntu（GNOME 版）的 Settings → Notifications 页面里，你找不到“显示时长”滑块，也没有“邮件应用设 12 秒”这类选项。
原因很简单：GNOME 将通知行为交由 D-Bus 接口和应用自身实现，系统层只保留基础开关（是否允许通知、是否播放声音、是否显示预览）。
所以：
• 不能通过控制中心统一改所有通知的停留时间；
• 也不能为 Chrome、Thunderbird 等单独指定秒数；
• 即使安装 gnome-tweaks，它的“Notifications”页也只管位置、声音、勿扰模式，不碰时长。
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
crontab 定时发通知时，-t 不生效的真正原因
很多用户发现定时任务跑出来的通知总是 5 秒，哪怕写了 -t 10000，这是因为：
• cron 默认运行在无 GUI 会话环境中，notify-send 实际走的是 fallback 机制，忽略 -t；
• 即使补了 export DISPLAY=:0 和 XDG_RUNTIME_DIR，GNOME 的通知服务仍可能降级处理；
• 更隐蔽的问题：某些 GNOME 版本（如 42+）对来自非活跃会话的通知强制使用默认超时，不读取 -t。
验证方法：手动在终端执行同一命令，看是否正常停留；如果手动可以、cron 不行，就是环境变量 + 会话上下文没对齐。
想延长停留时间？只能绕过 notify-send
真要让通知“挂久一点”，目前最可靠的方式是换工具或换逻辑：
• 用 zenity --notification：它弹的是 GTK 对话框，不受 GNOME 通知服务限制，--timeout=10（单位是秒）可稳定生效；
• 写个简易 GUI 提醒脚本（用 Python + tkinter），自己控制窗口生命周期；
• 改用状态栏图标 + 右键菜单提示，避开横幅通知机制。
注意：这些都不是“设置托盘通知时长”，而是放弃原生通知通道——因为 Ubuntu 根本没开放这个配置入口。
复杂点在于：你以为在调一个参数，其实是在和 GNOME 的通知架构、D-Bus 会话绑定、以及应用自身的通知实现方式打交道。最容易被忽略的是——notify-send -t 在非交互式环境里大概率被无视，而不是你的数字写错了。
