我有3个shell脚本，每个脚本包含一个while循环，并“打电话”主页打开反向ssh隧道。 隧道工作。
我谷歌search，但不知道什么会为此工作。 我主要担心的是，脚本中的循环会阻止引导，而不是“忘却”。
我目前没有物理访问远程机器，所以我不能玩弄，看看它是否工作，我需要的东西， 将工作，并继续工作。
我对这个问题的希望是一步一步的指导，因为我不是很有把握这个工作所需要的东西。
过去，你可以在/ etc / inittab底部的“respawn”条目中调用每一个脚本，并完成它。 简单。 但是自从Debian转向使用新手而不是init以及不推荐使用的inittab之后，情况变得更加复杂和脆弱。 你需要写一个新贵的configuration文件。 那些在/ etc / init中，他们更容易出错。
你可能要做的是通过/ etc / init / *的内容grep来查找使用'respawn'关键字的现有configuration，并启动一些networking守护进程 – 这些守护进程应该已经具有相关性，确保networking已经启动。 复制并修改每个隧道的其中一个。 约定是把你自己的configuration放在/ etc / init / local / *中。 在启动过程中，你可以通过早些时候启动你的隧道来消除一些脆弱性，当networking还没有启动的时候，让它们挂起，死亡，超时或者其他任何东西。 “重生”最终会重新生成，如果他们提前尝试重试，可能会在较长时间后重新生成。
只要你使用“重生”，你可以相对安全地挂起引导过程 – 但是暴发户，任何事情都是可能的。 其增加的灵活性意味着configuration错误可能以不太明显的方式挂起引导; 目视检查不再像使用inittab那样可靠。
顺便说一句，你可能不需要那些“真正的”脚本。 我通常使用“autossh”来启动和pipe理这些隧道。 它比典型的脚本更可靠，autossh命令可以直接放在/ etc / initconfiguration文件中。
我毫不犹豫地给你一个configuration文件的例子，因为新贵的configuration可能会有所不同，所以对我来说什么工作可能不适合你（更多的是脆弱性）。 但是这里是我的autosshconfiguration之一 – 这可能会进入，比如/etc/init/local/autossh-example.conf。 你会注意到，我没有明确说明任何networking设置的依赖 – 我期待的“重生”，导致重试，直到networking在那里。 您需要在相同的机器上进行本地testing，然后才能在远程计算机上进行信任：
start on stopped rc RUNLEVEL=[2345] stop on runlevel [!2345] respawn exec /usr/bin/autossh -R 20042:127.0.0.1:22 -N foo.example.com