Questions tagged «init-script»

引导时要执行的脚本,通常用于启动恶作剧和挂载文件系统。

2
如何在Redhat下将Shell脚本作为守护程序运行?
我有一个shell脚本,它实际上是一个带有一些日志记录的线性脚本,我正在尝试从init脚本中运行它。我正在使用其中的daemon函数/etc/init.d/functions来运行它,因为Redhat似乎不可start-stop-daemon用。当我调用初始化脚本(/etc/init.d/script start)时,它停留在前台,而不是完成并使进程运行。我将该守护程序守护起来的正确方法是什么? 要运行的脚本: # conf file where variables are defined . /etc/script.conf echo "Starting..." | logger -i echo "Monitoring $LOG_LOCATION." | logger -i echo "Sending to $MONITOR_HOST:$MONITOR_PORT." | logger -i tail -n 1 -F $LOG_LOCATION | grep WARN --line-buffered | /usr/bin/nc -vv $MONITOR_HOST $MONITOR_PORT 2>&1 | logger -i 初始化脚本: #!/bin/bash …

1
带有内核和BusyBox的最小Linux:/ etc / inittab被忽略,仅执行/ init
我设法创建了一个小型且功能齐全的实时Linux CD,其中仅包含内核(使用默认选项编译)和BusyBox(使用默认选项+静态编译,所有小程序都包括在内/sbin/init)。我没有问题,建立initrd和填充/dev,/proc并且/sys也是我在所有与我没有任何问题/initshell脚本。 最近,我读到BusyBox支持/etc/inittab配置(至少在某种程度上),我非常想执行以下任一操作: 忘记我的/initshell脚本,完全依靠/etc/inittab配置。 同时使用/initShell脚本和/etc/inittab配置。 现在是实际问题- /etc/inittab当我的发行版启动时,似乎完全被忽略了。症状是: 当我删除/init并离开时,/etc/inittab我最终会陷入内核崩溃。我的假设是内核根本不执行/sbin/init,或者/sbin/init根本找不到(或读取)/etc/inittab。 我读到即使没有,BusyBox也应该可以正常工作/etc/inittab。因此,我同时删除了两者/init,/etc/inittab然后猜测是什么-再次出现内核恐慌。 我试图执行/sbin/init从我的外壳经过几次猜测,其中包括exec /sbin/init,setsid /sbin/init和exec setsid /sbin/init我结束了内核崩溃。文件系统上同时存在和不存在/ etc / inittab。 这是我的/initshell脚本的内容: #!/bin/sh dmesg -n 1 mount -t devtmpfs none /dev mount -t proc none /proc mount -t sysfs none /sys setsid cttyhack /bin/sh 在这一点上,我不在乎它的内容/etc/inittab,只要我有办法知道那里的配置确实有效。我尝试了几种/etc/inittab配置,所有这些配置都是基于在这里找到的信息。 作为最低要求,我的/ etc / inittab仅包含以下这一行: ::sysinit:/bin/sh 再次-我最终陷入内核恐慌,似乎/etc/inittab被忽略了。 /etc/inittab非常感谢任何有关如何强制我的小型现场发行版与BusyBox配合使用的建议! 更新: 为了清楚起见,使用和不使用当前的shell脚本,我都不会遇到内核崩溃的麻烦。一切正常,我的控制台运行良好,没有任何意外的麻烦。唯一的问题是,正如我上面所述,它被完全忽略了。/init/etc/inittab/bin/ash/etc/inittab …

3
为什么initramfs以只读方式挂载根文件系统
将根文件系统挂载ro到initramfs(和initrd)中的原因是什么? 例如,Gentoo initramfs指南使用以下命令挂载根文件系统: mount -o ro /dev/sda1 /mnt/root 为什么不以下? mount -o rw /dev/sda1 /mnt/root 我可以看到,可能有一个很好的理由(可能涉及switchroot),但是似乎没有任何地方对此进行记录。

1
在rhel / centos-6初始化脚本中启动守护程序的规范方法是什么?
我为ubuntu的start-stop-daemon找到了很多很好的文档,并且有一个二进制文件的手册页daemon。 但是,从我可以说出的在rhel / centos脚本中启动守护程序的规范方法来看,就是先获取源代码,/etc/init.d/functions然后使用该daemon()函数。但是我找不到任何好的例子或文档。 在rhel / centos-6初始化脚本中启动守护程序的规范方法是什么? 我的第一次尝试是: #!/bin/bash source /etc/init.d/functions daemon --user USER nohup /path/to/your/binary arg1 arg2 >/dev/null 2>&1 &

1
应该使用“ invoke-rc.d”或“ service”来重新启动服务吗?
我对哪个最好,在什么情况下感到困惑: invoke-rc.d apache2 restart 要么 service apache2 restart 有真正的区别吗? man service 有以下有趣的地方: 该服务在尽可能可预测的环境中运行System V初始化脚本,删除大多数环境变量并将当前工作目录设置为/。 我主要对Debian感兴趣,也对Mint(也基于Debian)感兴趣。

2
从Ubuntu引导过程中删除抽象
在将近5年之后,我一直在使用Linux,并且观察到启动过程几乎已经抽象了。我的意思是,用户看不到幕后发生的事情(由于启动屏幕等)。现在,这对于最终用户可能是好的,但对于极客却不是:) 我想带回过去的冗长。这是我所做的: 通过从命令行中删除“ splash”和“ quiet”参数,我已经能够摆脱其中的一些。但是,我仍然看不到服务是一一启动的(就像init.d中的一样)。 我认为这是因为init守护进程被upstart所取代。是否有一些配置文件,我可以对其进行调整以使发生的事情变得冗长。 另外,一旦出现登录屏幕,它就会擦除启动日志历史记录。有办法禁用它吗? 注意:我知道我可以通过将发行版切换到Arch或Slackware来做到这一点。但是我不想那样做。

1
/ var / run中* .pid文件的含义/用途是什么
我在Linux领域还很陌生,现在我正试图了解FHS原则。 在中,/var/run我发现了大约十个*.pid文件crond.pid,其中仅包含PID。 系统中运行着十多个进程,只有十个文件。 那么,它们的目的是什么?产生它们的原因是什么?

3
如何在CentOS中创建非特权用户?
我想创建一个无特权的用户来在CentOS实例上运行我的RhodeCode服务器和Celery守护程序。我认为可接受的定义是没有主目录,禁用登录名和没有shell访问权限?查看adduser的手册页,我只是看不到这样做的直观方法。任何建议表示赞赏。谢谢。

2
将socat初始化脚本迁移到systemd
我在sysVinit的debian 7.2上将socat与以下init脚本一起使用。它完美地工作: #!/bin/bash DESC=socat DAEMON=/usr/bin/socat LIB=/usr/lib/socat SOCAT_ARGS="-d -d -lf /var/log/socat.log" [ ! -f /etc/default/socat.conf ] || . /etc/default/socat.conf . /lib/lsb/init-functions PATH=/bin:/usr/bin:/sbin:/usr/sbin [ -x $DAEMON ] || exit 0 # # Try to increase the # of filedescriptors we can open. # maxfds () { [ -n "$SOCAT_MAXFD" ] || return …

3
为什么pidof和pgrep的行为有所不同?
我有一个初始化脚本,/etc/init.d/myservice用于初始化这样的服务: ... start() { ... daemon /usr/sbin/myservice ... } stop() { ... pgrep myservice pidof myservice ps -ef | grep myservice ... } 当我尝试停止该服务时,这是输出: 10000 10001 10000 root 10000 1 0 09:52 ? 00:00:02 /usr/sbin/myservice root 9791 9788 0 10:06 pts/1 00:00:00 /bin/sh /sbin/service myservice stop root 10001 9791 1 …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.