Fedora 15和Ubuntu现在使用systemd,Ubuntu使用Upstart(长时间默认)直到15.04),而其他人则使用System V的变体。
我有一个正在编写的应用程序是一个跨平台的守护程序。初始化脚本是根据可以在configure上传递的参数动态生成的。
我只想为他们正在使用的特定初始化系统生成脚本。这样,可以在没有参数作为root的情况下合理地运行安装脚本,并且可以自动“安装”守护程序。
这是我想到的:
在/ bin中搜索systemd,upstart等
将/ proc / 1 / comm与systemd,upstart等进行比较
询问用户
最好的跨平台/跨平台方法?
相关种类,我可以依赖bash来使用大多数* nix还是依赖发行版/操作系统?目标平台:
Mac OS
Linux(所有发行版)
BSD(所有版本)
Solaris,Minix和其他* nix
#1 楼
对于第二个问题,答案是否定的,您应该看看可移植Shell编程的参考资料。对于第一部分-首先,您一定要小心。我想说要进行几次测试以确保-因为有人确实安装了systemd(例如),但这并不意味着它实际上已用作默认
init
。另外,查看/proc/1/comm
可能会产生误导,因为安装各种初始化程序会自动使/sbin/init
成为符号链接硬链接,甚至是其主程序的重命名版本。 也许最有用的事情就是查看init脚本的类型-因为无论您运行什么脚本,它们实际上都是您要创建的。旁注,您还可以看一下OpenRC,它旨在提供一种与Linux和BSD系统兼容的初始化脚本的结构。
评论
“查看init脚本类型”是什么意思?通常,不同的init系统会将其脚本/文件放在/ etc / init之外,就像systemd将它们放在/ etc / systemd中一样。如果要让我的脚本使用这些内容,可能需要一些时间。哦,感谢BTW进行便携式外壳编程的链接。
–beatgammit
2011年8月7日,0:23
我的意思是说,可以对某些init实现进行调整,以利用不同init脚本的类型和位置(例如/etc/rc.d/或/etc/init.d/)。并且您应该在安装时适当地调整程序,以利用给定系统上使用的结构。
–rozcietrzewiacz
2011年8月7日在1:08
那么,您是说没有可靠的方法来以编程方式检测初始化系统吗?让用户传递参数当然更安全,但是如果用户不传递任何参数,那么猜测的最佳方法是什么?
–beatgammit
2011年8月7日,下午1:27
我不知道什么是您的程序的最佳方法-这完全取决于该程序最终将在哪些系统上运行。我没有使用太多的分布,但是我试图分享我的观察结果以帮助您。这是您将要尝试的一段艰难的脚本,我尝试向您提供一些有关该领域的看法-您必须自己做出最终答案,或者等待更多提示。
–rozcietrzewiacz
2011年8月7日在1:40
太好了,谢谢您的所有帮助。您肯定为我指明了正确的方向。
–beatgammit
2011年8月7日,下午1:47
#2 楼
我本人已介入此问题,并决定进行一些测试。我完全同意一个答案,即应该为每个发行版分别打包,但是有时存在一些实际问题会阻止这种发行(尤其是人力)。对于那些想要“自动检测”的人我在一组有限的发行版中发现的内容(更多内容请参见以下内容):
您可以从以下位置告诉暴发户:
[[ `/sbin/init --version` =~ upstart ]] && echo yes || echo no
您可以从以下位置告诉systemd:
[[ `systemctl` =~ -\.mount ]] && echo yes || echo no
您可以从以下位置告诉sys-v init:
[[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]] && echo yes
这是我在以下命令行下进行的实验:
if [[ `/sbin/init --version` =~ upstart ]]; then echo using upstart;
elif [[ `systemctl` =~ -\.mount ]]; then echo using systemd;
elif [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]]; then echo using sysv-init;
else echo cannot tell; fi
m,包括us-east AMI id):
ArchLinux:使用systemd(自2012.10.06起)
CentOS6.4 ami-52009e3b:使用upstart
CentOS7 ami-96a818fe:使用systemd
Debian 6 ami-80e915e9:使用sysv-init
Debian 7.5 ami-2c886c44:使用sysv-init
Debian 7.6 GCE容器-vm:使用sysv-init
RHEL 6.5 ami-8d756fe4:使用upstart
SLES 11 ami-e8 084981:使用sysv-init
ubuntu 12.04 ami-b08b6cd8:使用upstart
Ubuntu 14.04 ami-a427efcc:使用upstart
Ubuntu 14.10及更低:使用systemd
AWS linux 2014.3.2 ami-7c807d14:使用upstart
Fedora 19 ami-f525389c:使用systemd
Fedora 20 ami-21362b48:使用systemd
只是要清楚一点:我并不是说这是万无一失的!,几乎可以肯定不是。另请注意,为方便起见,我使用了bash regexp匹配项,但并非在所有地方都可用。以上对我来说已经足够了。但是,如果您发现发行版失败了,请告诉我,如果有EC2 AMI重现该问题,我将尝试修复它。
评论
根据systemd文档(sd_booted(3)),检查systemd的正确方法是检查目录/ run / systemd / system是否存在。
–罗比·巴萨克(Robie Basak)
17年12月13日在15:23
我将在macOS上的启动检测系统中添加此检测程序:[[$(ps 1)=〜'launchd']] && echo yes ||在macOS Sierra版本10.12的MacBookPro上未回显任何测试
–托尼
18年8月8日14:15
我还要添加busybox:如果[-h / sbin / init -a $(readlink / sbin / init | grep busybox | wc -l)-gt 0];然后回声是;否则回声不;科幻
–阿斯特里努斯
19-09-25在7:04
当前在我的debian机器上,/ sbin / init --version抱怨没有--version选项。
– Ben Crowell
20-10-7在13:01
#3 楼
使用进程查看几个
ps
命令的输出,这些命令可以检测systemd
和upstart
的各种版本,可以像这样制作:upstart
$ ps -eaf|grep '[u]pstart'
root 492 1 0 Jan02 ? 00:00:00 upstart-udev-bridge --daemon
root 1027 1 0 Jan02 ? 00:00:00 upstart-socket-bridge --daemon
systemd
$ ps -eaf|grep '[s]ystemd'
root 1 0 0 07:27 ? 00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
root 343 1 0 07:28 ? 00:00:03 /usr/lib/systemd/systemd-journald
root 367 1 0 07:28 ? 00:00:00 /usr/lib/systemd/systemd-udevd
root 607 1 0 07:28 ? 00:00:00 /usr/lib/systemd/systemd-logind
dbus 615 1 0 07:28 ? 00:00:13 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
注意PID#1的进程名称也可能会引起注意使用哪个初始化系统。在Fedora 19(使用
systemd
的情况下,例如: > UID PID PPID C STIME TTY TIME CMD
root 1 0 0 07:27 ? 00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
注意:但是请谨慎使用,没有任何东西说要在给定发行版上使用的特定初始化系统必须将
init
作为PID#1 。通用
$ ps -efa|grep init
root 1 0 0 Jan02 ? 00:00:03 /sbin/init
使用ppid 1(init进程的子进程)查看进程(某些)子进程名称指向正在使用的init系统。
文件系统
如果查询
/sbin/init
可执行文件,也可以从中获取一些信息,只需解析systemd
输出即可。例如:upstart
$ (ps -eo "ppid,args" 2>/dev/null || echo "ps call error") \
| awk 'NR==1 || ==1' | less
PPID COMMAND
1 /lib/systemd/systemd-journald
1 /lib/systemd/systemd-udevd
1 /lib/systemd/systemd-timesyncd
systemd
$ sudo /sbin/init --version
init (upstart 1.5)
Copyright (C) 2012 Scott James Remnant, Canonical Ltd.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
注意:事实
init
不在其标准位置是一个提示/提示,它始终位于sysvinit系统上的--version
中。sysvinit
$ type init
init is /usr/sbin/init
还这样:
$ type init
init is /sbin/init
结论
所以没有出现可以是任何一种方法,但是您可以制定一套检查方法,以相当高的信心确定正在使用的初始化系统。
评论
怎么样:pgrep systemd> / dev / null && echo初始化系统:systemd
–马可
2014年2月10日20:27在
谢谢,这正是我所要寻找的:尝试确定初始化系统的一些步骤。
–所有工人都是必不可少的
2014年2月10日20:30在
如果使用systemd,则PID#1不一定是/ usr / lib / systemd / systemd,这是一个错误的假设。例如,在我的系统上,PID#1是/ sbin / init(我使用systemd)。它取决于分布。
–马可
2014年2月10日在20:32
在我的kubuntu 15.04安装上,我似乎同时具有systemd和sysvinit。不知道为什么或那是什么意思,只是说一下。
– dotnetCarpenter
2015年9月3日,11:39
Linux Mint 17同时运行了systemd和upstart,因此仅pgrep的退出状态是不够的。
–ychaouche
19年11月19日在19:06
#4 楼
效率不高,但我似乎可以正常工作。多个字符串匹配,可以将其翻译为“无法猜测”。 grep中使用的字符串可以稍作修改,但是在以下操作系统中测试时,我总是只有一行。RHEL 6.4 [UPSTART]
RHEL ES 4(Nahant Update 7) [SYSVINIT]
Ubuntu 16.04.1 LTS [SYSTEMD]
Ubuntu 14.04.2 LTS [UPSTART]
Fedora 23版(在线外壳)[SYSTEMD]
Debian GNU / Linux 7 (在线外壳程序)[SYSTEMD]
Centos 7.6(VM)[SYSTEMD]
相同解决方案的一种更简单的方法(但在第一次匹配时停止) >
strings /sbin/init | grep -q "/lib/systemd" && echo SYSTEMD
strings /sbin/init | grep -q "sysvinit" && echo SYSVINIT
strings /sbin/init | grep -q "upstart" && echo UPSTART
评论
不错的第一个答案。欢迎来到unix.se!
–奥利维尔·杜拉克(Olivier Dulac)
16年11月24日在18:23
我只是在安装了OpenRC的Gentoo默认docker映像上尝试过此操作,它返回了SYSVINIT。根据wiki.gentoo.org/wiki/Comparison_of_init_systems的说法,Gentoo的默认值为OpenRC,但似乎OpenRC使用sysvinit。然后,当我尝试使用OpenRC命令时,我得到“您正在尝试在无法启动openrc的系统上运行OpenRC服务”。有没有办法区分sysvinit正确和使用sysvinit的OpenRC?
–tu-Reinstate Monica-dor duh
17年1月4日,2:10
+1。该awk命令可以简化为字符串-n7 / sbin / init | awk'/ upstart | systemd | sysvinit / {print; exit}'。或更佳的是,在GNU上:grep -aEiom1'upstart | systemd | sysvinit'
–阿米特·奈杜(Amit Naidu)
20-10-7在2:07
#5 楼
有时就像使用ls
一样容易:$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 juin 25 12:04 /sbin/init -> /lib/systemd/systemd
我想如果
/sbin/init
不是符号链接,则您必须在其他答案中进一步检查以下建议。 />#6 楼
我也遇到了同样的问题,并在某些RedHat / CentOS / Debian / Ubuntu / Mint机器上进行了很多测试。这是我最终得到的结果,很好。使用PID 1查找可执行文件的名称:
ps -p 1
如果是systemd或Upstart,问题就解决了。如果是“ init”,则可能是符号链接或其他名称。前进。
查找可执行文件的真实路径(仅以root身份工作):或systemd,问题已解决。否则,几乎可以肯定您具有SysV init。但是它可能是一个错误命名的可执行文件。前进。
查找提供可执行文件的程序包。不幸的是,这取决于发行版:
ls -l `which init`
然后,如果您要编写脚本(最有趣的部分,恕我直言),这些就是我的衬纸(以root用户身份运行):
dpkg-query -S (executable real path) # Debian
rpm -qf (executable real path) # RedHat
评论
并非所有指定的操作系统都具有dpkg或rpm(此问题并非仅针对您的答案,BTW)。
– Toby Speight
16 Apr 25 '17:10
@ toby-speight是的,可以。请注意,我在回答中是这样说的,只是为了明确限制。
–艾默生·普拉多(Emerson Prado)
16年5月1日在1:10
至于步骤3,您可以运行init --version来获取信息。
– jarno
16-10-4在9:14
#7 楼
检查文件描述符也可以提供帮助。它来自实际运行的init(Debian Stretch目前允许安装更多init系统):-)由于busybox通常使用符号链接:
$ ls -l /proc/1/fd |grep systemd
lrwx------ 1 root root 64 srp 14 13:56 25 -> /run/systemd/initctl/fifo
lr-x------ 1 root root 64 srp 14 13:56 6 -> /sys/fs/cgroup/systemd
$ ls -l /proc/1/fd |grep /run/initctl # sysvinit
lrwx------ 1 root root 64 srp 14 14:04 10 -> /run/initctl
$ ls -l /proc/1/fd |grep upstart
l-wx------ 1 root root 64 srp 13 16:09 13 -> /var/log/upstart/mysql.log.1 (delete
l-wx------ 1 root root 64 srp 13 16:09 9 -> /var/log/upstart/dbus.log.1 (deleted)
$ ls -l /proc/1/fd # busybox
total 0
lrwx------ 1 root root 64 Jan 1 00:00 0 -> /dev/console
lrwx------ 1 root root 64 Jan 1 00:00 1 -> /dev/console
lrwx------ 1 root root 64 Jan 1 00:00 2 -> /dev/console
所以检查可能是:
$ ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Jan 1 00:00 /proc/1/exe -> /bin/busybox
评论
同样,具有systemd的系统通常具有目录/ run / systemd / system。
– Pevik
2015年9月11日下午12:05
#8 楼
这是特定于发行版的软件包的用途。正确安装软件不只是检测启动系统而已。许多发行版都使用SysVinit,但并非所有人都以相同的方式编写其初始化脚本。解决此问题的正确方法是包括所有不同的变体,然后使用带有rpm发行版的发行版特定依赖项名称的spec文件,基于apt的系统的deb文件等将其打包。可以编写包括依赖项,脚本,初始化脚本等在内的内容。不要在这里重新发明轮子。
不。这使我们回到1。如果您需要bash,它应该是一个依赖项。您可以在配置脚本中指定此检查,但也应在软件包描述中。
编辑:在配置脚本上使用标志,例如
--with upstart
或--without sysvinit
。选择一个合理的默认值,然后将软件打包为其他发行版的脚本可以选择使用其他选项来运行它。评论
汉弗,所以看起来我无法拥有“一个脚本来统治所有人”的解决方案。我见过很多使用autoconf或类似程序来处理跨平台内容的程序,但似乎它不是我的应用程序的正确工具。维护每个平台的版本真的是唯一可靠的解决方案吗?
–beatgammit
2011年8月7日在7:27
BadIdea是一个可以全部使用的安装脚本。最终失败的地方超过了它的工作范围。就其本身而言,Autoconf很好。努力使软件的结尾尽可能通用,并在软件包中包含备用的初始化脚本。设置几个主要发行版的软件包规格。如果您的软件不错,则可以让其他人帮助您将其打包为其他系统。
–卡莱布
2011年8月7日在7:34
@tjameson:我刚刚意识到我忘记了最重要的一点。这种事情通常是通过传递给configure脚本的开关来完成的。每个发行版的构建/打包例程都可以调用不同的开关,并且您的configure / make仅需知道传递了哪个开关,而无需检测所有可能的软件配置。
–卡莱布
2011年8月7日在7:38
@ Caleb-是的,我已经在其中有了逻辑,但是很好。我希望找到一种方法来嗅探初始化系统,以使用明智的猜测而非合理的默认值。
–beatgammit
2011年8月7日在7:40
#9 楼
在Gentoo上,查看pid 1:USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 4216 340 ? Ss 2013 0:57 init [3]
如果是
init
,则初始化系统为OpenRC
。如果它是systemd
,则初始化系统是systemd
。您可以使用
[ -f /etc/gentoo-release ]
检测Gentoo。Gentoo的另一种方法是使用
profile-config show
,它将显示默认配置文件正在使用中。除以/ systemd结尾的两个以外的所有配置文件均使用OpenRC初始化。请记住,这些仅代表默认值,并且用户可能已采取步骤覆盖该默认值,而可能并不表示实际使用的初始化管理器。评论
愚蠢的问题,但是如何检查pid 1?
– Faheem Mitha
2014年2月28日在23:20
使用p选项(与-p和--pid相同)通过PID选择。上面的代码片段实际上是ps u --pid 1的输出。
–JoséM.Benítez
15年3月22日在11:27
#10 楼
在debian上,/ sbin / init是指向默认init的符号链接,因此ls -l /sbin/init
将为您提供所需的信息。
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 nov 18 13:15 /sbin/init -> /lib/systemd/systemd
评论
不是这样在具有Upstart的Ubuntu 14.04上,这不是符号链接。
–muru
2014年12月3日7:49
安装另一个初始化系统,然后再次检查。
–rmorelli74
2014年12月3日12:24
可以在Ubuntu 14.04上安装其他哪个init?
–muru
2014年12月3日,12:28
...为什么不使用sysv或systemd?
–rmorelli74
2014年12月3日,12:31
我不想投票,只希望您指定适用于哪个版本的Debian。 (也许仅将“基于Debian的”改写为“ Debian”,以便它变得正确。)
–muru
2014年12月3日,12:59
#11 楼
只需简单地使用PID 1进入过程即可告诉您:strings /proc/1/exe |grep -q sysvinit
strings /proc/1/exe |grep -q systemd
评论
并非所有提到的OSeS都有proc文件系统...
– Toby Speight
16 Apr 25 '17:10
#12 楼
不知道其他系统,然后是Debian(heezy)/或Ubuntu(14.10。),但是我使用普通的旧版file
命令测试了此类问题。 :file /sbin/init
带
systemd
(例如sid)的Debian系统显示如下:/sbin/init: symbolic link to 'upstart'
评论
您在什么系统上进行了测试?没有Debian / Ubuntu这样的东西,这在Debian上不起作用。您在Ubuntu上尝试过吗?
– terdon♦
2014年10月7日12:53
抱歉,我的意思是Debian(wheezy)/或Ubuntu(14.10。)。在debian上的输出:文件/ sbin / init / sbin / init:ELF 64位LSB可执行文件,x86-64,版本1(SYSV),动态链接(使用共享库),用于GNU / Linux 2.6.18,BuildID [sha1] ] = 0x8c68a736c6a4e6fadf22d5ac9debf11e79c6bdcd,剥离表示我们在这里使用SYSV。我的答案中显示了ubuntu的输出。
– zzeroo
2014年10月8日14:14
确实如此,因此,您的解决方案似乎仅在碰巧使用upstart和Ubuntu时才有效。
– terdon♦
2014年10月8日14:17
@terdon:在运行systemd的系统(RHEL,Fedora)上,它返回“符号链接到... systemd”;在运行upstart的系统(Ubuntu)上,它返回“到upstart的符号链接”;在运行SysV init的系统(RHEL,Ubuntu,Debian)上,它返回“可执行”。尽管这并不是一个全面的调查,而且这种方法显然不是100%可靠的,但它显然更接近“至少为主要发行版工作”,而不是“仅是暴发户和Ubuntu”!
–psmears
14-10-20在21:46
@psmears如果它也适用于某些systemd系统,那确实更好(但未在此答案中提及)。我刚刚在运行sysvinit的Debian上进行了测试,并在所有系统上对三个Ubuntu(10.04、12.04和14.04,都在运行upstart)和文件/ sbin / init返回“可执行”。在CentOS 5.8,SLES 10,Ubuntu 8.04上,它也返回相同的结果,基本上每个我都能使用的系统。因此,据我所知,它甚至不适用于新贵和Ubuntu。
– terdon♦
14-10-21在0:06
#13 楼
对于某些初始化系统来说,这确实很容易。对于systemd:test -d /run/systemd/system
对于暴发户:
initctl --version | grep -q upstart
对于其他任何内容,您都可以基于该发行版(在OS X上启动,在Debian上启动sysvinit,在Gentoo上启动OpenRC)。
评论
“基于发行版的假设”不适用于Debian,因为它至少支持三种不同的init ...
– Toby Speight
16年4月25日在17:13
#14 楼
这是执行检测的bash脚本。它目前仅检查新贵和systemd,但应该易于扩展。我是从我为DisplayLink驱动程序安装脚本贡献的代码中摘录的。detect_distro()
{
# init process is pid 1
INIT=`ls -l /proc/1/exe`
if [[ $INIT == *"upstart"* ]]; then
SYSTEMINITDAEMON=upstart
elif [[ $INIT == *"systemd"* ]]; then
SYSTEMINITDAEMON=systemd
elif [[ $INIT == *"/sbin/init"* ]]; then
INIT=`/sbin/init --version`
if [[ $INIT == *"upstart"* ]]; then
SYSTEMINITDAEMON=upstart
elif [[ $INIT == *"systemd"* ]]; then
SYSTEMINITDAEMON=systemd
fi
fi
if [ -z "$SYSTEMINITDAEMON" ]; then
echo "WARNING: Unknown distribution, assuming defaults - this may fail." >&2
else
echo "Init system discovered: $SYSTEMINITDAEMON"
fi
}
评论
我认为/ proc的使用将这个问题与Linux(如果配置正确)和一个或两个其他问题联系在一起-这肯定不是通用的。
– Toby Speight
16年4月25日在17:12
#15 楼
在测试systemd与initd时,存在很多兼容性陷阱。这实际上适用于OpenSuSE 42.1:ps --pid 1 | grep -q systemd && echo 'systemd' || echo 'init'
#16 楼
对于systemd
:if [[ `systemctl is-system-running` =~ running ]]; then echo using systemd; fi
评论
之所以投票,是因为与许多现有答案相比,该答案没有提供任何新的或不同的信息。
– Jayhendren
16年11月26日在19:27
@jayhendren我在其他地方看不到此片段。它本身并不完整,可能最好是对TvE的答案unix.stackexchange.com/a/164092/100397的评论
–roaima
16-11-26在22:42
哦,你说得对@roaima。它与其他不完全相同。我在页面上搜索了一个不太具体的字符串:)
– Jayhendren
16-11-26在22:46
到目前为止,这似乎是最正确的答案:)
–杰克·奥康纳(Jack O'Connor)
17-10-30在20:57
#17 楼
我的解决方案:检查以ID 1作为进程运行的命令。case `cat /proc/1/comm` in
init) echo Init ;;
systemd) echo SystemD ;;
# add here other patterns
*) echo "unknown: '`cat /proc/1/comm`'" ;;
esac
目前,我只能访问Init和SystemD机器,所以我不知道如何将检测到暴发户或macOS(OS X),但我会继续搜索。
#18 楼
check(){
if hash systemctl 2>/dev/null;
then
echo "there is systemd"
fi
if hash initctl 2>/dev/null;
then
echo "there is upStart"
fi
if [ -f "/etc/inittab"];
then
echo "there is systemV"
fi
}
#19 楼
这是怎么一回事:#20 楼
我将使用pstree
并简单地找到它的根。在我的Ubuntu
,Arch
和Fedora
系统上(不幸的是,所有systemd
都使用init
),运行pstree
给我提供了以下输出头:已在大多数系统上预安装的pstree
,我会运行head
在我测试过的所有三个操作系统上,它都向我扔了所需的字符串“ systemd”。 />
cut
评论
仅仅加我两美分,在FreeBSD上bash默认没有安装。@tjameson,您找到更直接的方法了吗?我正在寻找同一件事,但是这里的答案只是方向,而不是直接的答案。特别是1)要搜索的脚本位置和2)检测到有效的init系统,以防安装了多个系统(直接回答bash)。
@naxa-简短答案,不。长答案,您可以使用ps -p 1 -o命令走得很远(打印到当前init的路径)。在Arch Linux和Fedora(IIRC)上,它是与systemd二进制文件的符号链接(在所有systemd系统上可能相同)。在新贵公司上,init --help将打印使用情况信息,在我的盒子上,提到新贵公司并在其中指出向谁发送电子邮件。在FreeBSD(sysV)上,这将返回错误。在其他系统上可能也有类似的线索,但是自问这个问题以来,我决定只为所有平台创建它们,并为每个平台制作单独的软件包。
感谢伟大的信息!从中得知,我了解到sudo lsof -a -p 1 -d txt可能会给出更准确的结果。 ps可以打印一个任意名称,而使用lsof则可以获取实际的可执行路径。 (请参阅我的问题unix.stackexchange.com/questions/102453/…)
链接问题中的答案或评论均与bash无关。解决方案也应适用于您的情况。