ubunut 创建一个启动就执行的脚本_ubuntu脚本的编写和执行-优快云博客

本文链接：https://blog.youkuaiyun.com/xie__jin__cheng/article/details/145457963

1.概要

1.基本流程的常用命令

创建的服务名称是t2

1创建服务
sudo nano /etc/systemd/system/t2.service
2赋予执行权限
sudo chmod +x /etc/systemd/system/t2.service

3启用服务
sudo systemctl enable t2.service

4启动服务
sudo systemctl start t2.service
检查服务是否正在正常
sudo systemctl status t2.service
查看服务的日志
journalctl -u t2.service

重启系统

5.检查脚本是否被执行
cat /home/topeet/local/bin/my_startup_script.log

查看 systemd 对该服务的日志记录
journalctl -u t2.service

删除所有日志
sudo journalctl --vacuum-time=0

2.内容

在 Ubuntu 上创建一个启动时自动执行的脚本，并记录其执行状态，可以按照以下步骤进行：

步骤 1: 编写脚本

首先，创建一个你希望在启动时执行的脚本。例如，我们可以创建一个简单的 Bash 脚本，文件名为 my_startup_script.sh。

#!/bin/bash

# 记录脚本执行的日志文件
LOG_FILE="/var/log/my_startup_script.log"

# 记录当前时间到日志文件
echo "Script executed at: $(date)" >> $LOG_FILE

# 这里可以添加你的实际脚本逻辑
echo "Hello, world!" >> $LOG_FILE

确保脚本具有可执行权限：

chmod +x my_startup_script.sh

步骤 2: 使用 systemd 创建服务

使用 systemd 来管理启动脚本是一个推荐的方式，因为它可以很好地集成到系统的启动过程中。

创建一个 systemd 服务文件，例如 /etc/systemd/system/my_startup_script.service。

sudo nano /etc/systemd/system/my_startup_script.service

在文件中添加以下内容：

[Unit]
Description=My Startup Script

[Service]
ExecStart=/path/to/my_startup_script.sh
Restart=always
User=your_username

[Install]
WantedBy=multi-user.target

请确保将 /path/to/my_startup_script.sh 替换为你的脚本的实际路径，并将 your_username 替换为你希望以哪个用户身份运行脚本。

保存并关闭文件。

步骤 3: 启用并启动服务

运行以下命令以启用和启动服务：

sudo systemctl enable my_startup_script.service
sudo systemctl start my_startup_script.service

步骤 4: 检查脚本是否被执行

你可以通过检查日志文件来验证脚本是否被执行：

cat /var/log/my_startup_script.log

如果日志文件中有记录，则说明脚本已成功执行。

其他注意事项

确保日志文件的目录（如 /var/log）具有适当的写权限，或者将日志文件路径更改为具有写权限的目录。
如果你需要 root 权限来运行脚本，可以在服务文件中省略 User=your_username 行，或者将其更改为 root。
使用 journalctl -u my_startup_script.service 可以查看 systemd 对该服务的日志记录。

通过这种方式，你可以确保脚本在系统启动时自动执行，并能够检查其执行状态。

3.关联链接

4.关联知识

1.journalctl 清空日志

要清空 journalctl 的日志，你可以使用 --vacuum-time 或 --vacuum-size 选项来删除旧日志，或者直接删除日志文件。然而，请注意，清空日志是一个破坏性的操作，无法恢复已删除的日志数据。因此，在执行这些操作之前，请确保你确实不再需要当前的日志，或者已经做好了备份。

方法 1：使用 `--vacuum-time`

这个选项允许你删除指定时间之前的日志。例如，要删除 30 天之前的所有日志，可以运行：

sudo journalctl --vacuum-time=30d

方法 2：使用 `--vacuum-size`

这个选项允许你限制日志文件的总大小。例如，要将日志总大小限制为 100MB，可以运行：

sudo journalctl --vacuum-size=100M

方法 3：删除所有日志

如果你想完全清空所有日志，可以使用以下命令：

sudo journalctl --vacuum-time=0

或者，直接删除日志文件：

sudo rm -rf /var/log/journal/*

注意事项

权限：这些命令需要超级用户权限，因此需要使用 sudo。
影响：清空日志后，你将无法再查看或使用之前的日志信息进行调试或审计。
备份：在执行清空操作之前，建议备份重要的日志信息。
日志轮转：考虑配置日志轮转工具（如 logrotate）来自动管理日志文件的大小和保留时间。

通过这些方法，你可以有效地清空 journalctl 的日志，确保系统的日志存储不会过多占用磁盘空间。

2.journalctl 清空某个服务相关的日志

要清空特定服务的日志，journalctl 本身并没有直接提供删除特定服务日志的命令。不过，你可以通过以下方法间接实现这一目标：

方法：通过时间范围删除

如果你知道特定服务日志的时间范围，可以使用 --since 和 --until 选项来删除该时间范围内的日志。例如：

sudo journalctl --unit=your_service_name.service --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS" --vacuum-time=0

手动删除日志文件

另一种方法是手动找到并删除与该服务相关的日志文件。journalctl 的日志通常存储在 /var/log/journal/ 目录下。你可以通过以下步骤来删除特定服务的日志：

列出所有日志文件：

ls /var/log/journal/
查找特定服务的日志：

使用 grep 或其他工具查找包含特定服务名称的日志文件。由于日志文件是二进制格式的，直接使用 grep 可能不奏效。你可以通过 journalctl 导出日志来查看：

sudo journalctl --unit=your_service_name.service > service_logs.txt

然后在导出的文本文件中查找你想删除的部分。
删除日志文件：

一旦确认哪些日志文件包含你要删除的服务日志，可以删除这些文件。不过，直接删除文件需要小心，因为可能会影响其他服务的日志。

使用 `journalctl` 删除旧日志

如果你只是想减少特定服务的日志占用空间，可以使用时间范围来删除较旧的日志：

sudo journalctl --unit=your_service_name.service --vacuum-time=30d

上面的命令将删除 30 天之前的特定服务日志。

注意事项

权限：这些命令通常需要超级用户权限，因此需要使用 sudo。
备份：在删除日志之前，确保你不再需要这些日志，或者已经做好备份。
影响：删除日志后，你将无法再查看或使用这些日志信息进行调试或审计。

虽然没有直接的方法来只删除特定服务的日志，但通过时间范围和手动管理，你可以有效地减少特定服务日志的占用空间。

3.User=topeet

User=topeet 通常在配置文件中出现，尤其是在与 Unix/Linux 系统服务管理相关的上下文中，比如在 systemd 服务单元文件中。这个设置指定了服务运行时的用户身份。

解释

User=：
- 这是一个配置指令，用于指定服务应该以哪个用户的身份运行。
- 在 systemd 服务单元文件中，User= 指令用于定义服务进程的用户环境。
topeet：
- 这是具体的用户名，表示服务将以 topeet 用户的身份运行。

使用场景

systemd 服务单元文件：
- 在 systemd 服务单元文件中使用 User=topeet，意味着当这个服务启动时，它将以 topeet 用户的权限运行。
- 这对于需要访问特定用户资源的服务非常有用，比如用户的主目录或特定权限的文件。
安全性：
- 通过指定服务运行的用户，可以限制服务的权限，避免以 root 用户身份运行可能带来的安全风险。
- 确保服务只拥有执行其任务所需的最小权限。
资源管理：
- 以特定用户身份运行服务有助于更好地管理资源，比如文件系统的访问控制。

示例

以下是一个 systemd 服务单元文件的简单示例，展示了如何使用 User=topeet：

[Unit]
Description=My Sample Service

[Service]
ExecStart=/usr/bin/my-service-command
User=topeet
Group=topeet  # 通常也会指定组

[Install]
WantedBy=multi-user.target

在这个示例中，服务将以 topeet 用户和组的身份运行。

注意事项

用户存在性：确保指定的用户（如 topeet）在系统中存在，否则服务将无法启动。
权限问题：如果服务需要访问某些只有 root 或其他用户才有权限的资源，可能需要调整权限或用户。
系统兼容性：User= 指令需要 systemd 版本支持，确保你的系统版本满足要求。

通过使用 User=topeet，你可以更好地控制服务的运行环境，确保安全性和资源的合理使用。

5.过程记录

1.创建了一个符号链接

topeet@topeet:~$ sudo systemctl enable t2.service
sudo systemctl start t2.service
Created symlink /etc/systemd/system/multi-user.target.wants/t2.service → /etc/systemd/system/t2.service.

当你执行以下命令时：

sudo systemctl enable t2.service
sudo systemctl start t2.service

systemd 会进行以下操作：

sudo systemctl enable t2.service:
- 作用：启用 t2.service，使其在系统启动时自动运行。
- 输出解释：
  - Created symlink /etc/systemd/system/multi-user.target.wants/t2.service → /etc/systemd/system/t2.service.
  - 这条信息表示 systemd 已在 /etc/systemd/system/multi-user.target.wants/ 目录下创建了一个符号链接，指向你的服务文件 /etc/systemd/system/t2.service。这意味着在系统进入 multi-user.target 启动目标时，t2.service 会自动启动。
sudo systemctl start t2.service:
- 作用：立即启动 t2.service。
- 没有输出：通常，如果命令成功执行且没有错误，终端不会显示任何输出。这表示服务已成功启动。

后续步骤

检查服务状态：

你可以使用以下命令来检查服务是否正在正常运行：

sudo systemctl status t2.service

这将显示服务的当前状态，包括是否正在运行、最后的输出日志等。
查看日志：

如果需要更详细的信息（例如调试问题），可以查看服务的日志：

journalctl -u t2.service
确认自动启动：

重启系统后，你可以再次使用 systemctl status t2.service 来确认服务是否在启动时自动运行。

其他注意事项

服务文件配置：确保 /etc/systemd/system/t2.service 文件配置正确，包括 ExecStart 指向正确的可执行脚本路径。
权限：确保服务文件中指定的用户和权限设置正确，以便脚本能够正常运行。
调试：如果服务未能按预期启动，检查日志输出和服务配置，找出并修复问题。

通过这些步骤，你可以确保 t2.service 在系统启动时自动运行，并能够手动启动和检查其状态。

2.执行日志解析

2月 05 07:07:06 topeet systemd[1]: Started My Startup Script.
2月 05 07:07:06 topeet t2.sh[4391]: /home/topeet/local/bin/t2.sh: 行 7: /var/lo>
2月 05 07:07:06 topeet t2.sh[4391]: /home/topeet/local/bin/t2.sh: 行 10: /var/l>
2月 05 07:07:06 topeet systemd[1]: t2.service: Main process exited, code=exited>
2月 05 07:07:06 topeet systemd[1]: t2.service: Failed with result 'exit-code'.

从你提供的日志片段来看，t2.service 启动时执行了一个脚本 /home/topeet/local/bin/t2.sh，但该脚本在执行过程中遇到了一些错误，导致服务启动失败。让我们逐步分析这些日志信息：

服务启动：

2月 05 07:07:06 topeet systemd[1]: Started My Startup Script.

这行日志表示 systemd 已成功启动 t2.service。
脚本错误：
```
2月 05 07:07:06 topeet t2.sh[4391]: /home/topeet/local/bin/t2.sh: 行 7: /var/lo>
2月 05 07:07:06 topeet t2.sh[4391]: /home/topeet/local/bin/t2.sh: 行 10: /var/l>
```
这两行日志表示在执行 /home/topeet/local/bin/t2.sh 时，脚本的第 7 行和第 10 行出现了错误。日志内容被截断了，无法直接看到具体的错误信息，但通常这种错误可能包括文件路径不完整、权限问题、命令未找到等。
主进程退出：

2月 05 07:07:06 topeet systemd[1]: t2.service: Main process exited, code=exited>

这行日志表示 t2.sh 脚本的主进程已退出，退出代码未显示完整，但通常是某种非零值，表示异常退出。
服务失败：

2月 05 07:07:06 topeet systemd[1]: t2.service: Failed with result 'exit-code'.

这行日志表示 t2.service 启动失败，原因是脚本返回了一个非零的退出代码。

解决步骤

检查脚本：
- 打开 /home/topeet/local/bin/t2.sh，查看第 7 行和第 10 行的具体内容。
- 确认这些行中的命令或路径是否正确，是否有拼写错误或缺失的部分。
权限问题：
- 确保执行脚本的用户对所有相关文件和目录具有适当的权限。
- 使用 chmod 和 chown 命令来调整权限和所有权。
依赖项：
- 确认脚本中使用的所有命令和工具都已正确安装，并且在系统的 PATH 中可以找到。
调试输出：
- 在脚本中添加调试输出，例如 echo 语句，帮助定位问题。
- 可以在脚本的开头添加 set -x，以启用调试模式，跟踪每个命令的执行。
测试脚本：
- 手动运行脚本 /home/topeet/local/bin/t2.sh，观察是否有相同的错误输出。
- 根据错误信息进行修复。
查看完整日志：
- 使用 journalctl -u t2.service 查看该服务的完整日志，可能会提供更多上下文信息。

通过这些步骤，你应该能够识别并修复导致 t2.service 启动失败的问题。

3.配置文件在磁盘上已经发生了更改

topeet@topeet:~/local/bin$ sudo systemctl start t2.service
Warning: The unit file, source configuration file or drop-ins of t2.service changed on disk. Run 'systemctl daemon-reload' to reload units.

当你尝试启动一个 systemd 服务时，出现这个警告信息表示 t2.service 单元文件或其相关的配置文件在磁盘上已经发生了更改，但 systemd 守护进程尚未重新加载这些更改。为了确保 systemd 使用最新的配置启动服务，你需要先重新加载守护进程的配置。

解决步骤

重新加载 systemd 配置：

运行以下命令以重新加载 systemd 的所有单元文件配置：

sudo systemctl daemon-reload

这个命令会通知 systemd 重新读取所有单元文件，以便应用任何最近的更改。
再次启动服务：

在重新加载配置后，尝试再次启动服务：

sudo systemctl start t2.service

为什么需要 `systemctl daemon-reload`

动态配置：systemd 允许在不重启系统的情况下动态更改和重新加载服务配置。
一致性：重新加载确保 systemd 使用最新的单元文件定义来管理服务，避免因使用过时的配置而导致的问题。
安全性：及时更新配置可以防止由于配置错误或不一致导致的潜在问题。

其他注意事项

检查单元文件：如果你对单元文件进行了手动编辑，确保文件语法正确，并且所有路径和命令都是有效的。
查看状态：如果服务启动后仍有问题，可以使用以下命令查看服务状态，以获取更多调试信息：

sudo systemctl status t2.service
日志信息：如果需要更详细的错误信息，可以查看 journalctl 日志：

journalctl -xe

通过这些步骤，你应该能够成功启动 t2.service 服务，并确保 systemd 使用最新的配置来管理它。