![用 Python 编写的 init.d 脚本](https://linux22.com/image/530013/%E7%94%A8%20Python%20%E7%BC%96%E5%86%99%E7%9A%84%20init.d%20%E8%84%9A%E6%9C%AC.png)
AStackOverflow 上出现了一个问题询问有关init.d
用 Python 编写脚本的问题。一条评论指出这些脚本应该用 shell 而不是 Python 编写。init.d
用 Python 编写脚本:
- 糟糕。糟糕。糟糕。千万不要这么做。
- 不推荐这种做法。
- 好的,但是有注意事项。
- 遗留的教条。
- 非常好。
如果知道任何噩梦场景,或者这条规则是否写在某些系统管理员的血液中,那就太好了。
答案1
我想说的是 #2,但与 #1 非常接近——“糟糕。糟糕。糟糕。千万不要这么做。” Linux 初始化脚本的标准是在 LSB 中,虽然它从未说“这些是 Bourne shell 脚本”,但还是做出了几个假设。其中一个假设是,以 # 开头的行是注释,这恰好可以正常工作。更成问题的是要求 init 脚本在/lib/lsb/init-functions
“当前环境中(参见 shell 特殊内置命令点)”执行命令。
但更重要的是,如果你在这里做任何非常复杂的事情,那你就做错了。初始化脚本应该非常简单和实用。它们应该是传统意义上的脚本,而不是程序。最好是忍耐一下,制作一个简单的 shell 脚本,任何系统管理员都可以快速理解,而不是用 Python 制作一些漂亮而精心设计的东西。
另一个需要考虑的问题是systemd
,这可能是也可能不是 Linux 上所有系统初始化的未来。在 systemd 下,初始化由简单的配置文件而不是脚本完成,其理念是所有启动都符合几种标准设计模式,实际上您只需选择一种即可。如果您的程序使用复杂的初始化方法,那么这应该超出 init 脚本本身的范围。
答案2
如果您确信在运行 init.d 脚本时 Python 解释器可用,那么我认为这没什么问题。对我来说,这表明您正在查看在多用户(或“图形控制台”)运行级别中相对较晚完成的某件事。
但是...这意味着特定版本的 Python 解释器可能对您的启动顺序至关重要,这是您在升级时需要检查的另一件事。
我想这意味着我在说“3.好的,但有注意事项”。
答案3
我同意“3. 好的,但有注意事项”,但原因不同。我使用 Solaris 的经验是,他们为一些内部程序提供了 Perl 的 OS 副本。shell 脚本只不过是启动 Perl 的 shell。启动脚本是否必须用 sh 编写?不,但它提高了管理员的可维护性。而且 init 脚本没有做比daemon --start
或更复杂的事情daemon --stop
。如果您这样做,那么普通用户可以以非特权模式启动您的工具,如果这在您的程序上下文中有意义的话。而且他们不需要进行各种复杂的设置来巧妙处理。
现代 Linux 发行版(甚至那些仍在使用的发行版init.d
)都拥有大量预构建函数,旨在简化守护进程的管理。图形启动过程通常会利用这些函数来保持漂亮的徽标,除非某个启动脚本开始出现错误。您的 Python 代码(或任何其他语言)可能无法很好地与这些方案配合使用。
如果您不关心美观性或可维护性,您可以随心所欲地编写您的 init 脚本。我见过许多管理员,他们甚至不能正确地剪切和粘贴,完全忽略命令行参数,他们只是启动守护进程。没有关机、状态或重新启动。这是不成熟的,但他们的代码仍然运行。
答案4
我说的是 #1-2 之间。LSB 会指引你这样做……而从系统管理员(非开发人员角色)的角度来看,工作要求需要 sh/bash 知识,而不是对 python、PHP 或 perl 的开发级别(甚至只是浅显的理解)。这是针对 LAMP 堆栈的,而不是针对系统初始化脚本的。