web-dev-qa-db-ja.com

起動時にFedora 27がrc.localを実行しない

起動後にShadowsocksサーバーを自動的に実行しようとしましたが、rc.localファイルを使用しましたが、機能しませんでした。

rc.localは現在:

/usr/local/bin/ssserver -c /etc/shadowsocks.json -d start
#!/bin/bash
exit 0
  • a+x/etc/rc/d/rc.local特権を追加しました。
  • また、シンボリックリンク/etc/rc.local -> /etc/rc.d/rc.local(デフォルトの権限777)を修正しましたここ

ただし、rc.localのコードは、起動時にまだ機能しません。システムの起動時にrc.localが実行されていないことが判明しました。 こちら の助けを借りて、問題をさらに診断することができました。

これが/etc/systemd/system/rc-local.serviceファイルです(何も変更していません)。

[Unit]
Description=/etc/rc.d/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.d/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

-このファイルは大丈夫ですか?

systemctl enable rc-localを実行すると、次のエラーが発生します。

The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's 
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.

rc.localファイルは非常に単純なので、どちらの理由が私の状況であるかはわかりません。

3
jackxujh

Rc.localが壊れています!

/usr/local/bin/ssserver -c /etc/shadowsocks.json -d start
#!/bin/bash
exit 0

する必要があります

#!/bin/bash
/usr/local/bin/ssserver -c /etc/shadowsocks.json -d start
exit 0

編集:

rc.local systemdサービスの何が問題なのか、正確にはわかりません。

しかし、私はシャドウソックス用に別のsystemdユニットを作成します。これにより、起動および停止できるようになります。たとえば、構成を再ロードしたいときに、サーバーを維持する必要のある他のすべての人と同様に、再起動するサービス。

サンプルのshadowsocks systemdユニットファイル:

[Unit]
Description=Shadowsocks proxy server

[Service]
User=www-shadow
Group=www-shadow
Type=simple
ExecStart=/usr/local/bin/ssserver -c /etc/shadowsocks/shadowsocks.json -a shadowsocks -v start
ExecStop=/usr/local/bin/ssserver -c /etc/shadowsocks/shadowsocks.json -a shadowsocks -v stop

[Install]
WantedBy=multi-user.target

ここでは、プロキシを実行するためのユーザーwww-shadowがあり、そのユーザーはwww-shadowグループのメンバーです。 /etcを整頓するには、/etc/shadowsocksディレクトリを作成し、その中にJSONと他のshadowsocks関連ファイルを配置することをお勧めします。上記のsystemdユニットファイルの基本を linode.com から取得しましたが、デフォルトでポート8388を使用しているため、ルート(baaaaaaaaaad)としてプロキシを実行したいと考えています。これが必要だとは思いません。ユニットのwww-shadowユーザーとグループを作成しない場合、systemdはサービスをrootとして問題なく実行します(詳細には、設計上は「明らかに」)。

私はshadowsocksの経験がなく(プロキシにsquidを使用し、socksプロキシにsshを使用したことがあるだけです;-)、それを調べる時間はありませんが、ユニットファイルをざっと見たところ、(root folly)。

rc.localユニットファイル(下位互換性のため)を使用してもあまり意味がありません。imho、ExecStopを見逃してしまい、rc.localがshadowsocksであることを覚えておく必要があります...

rc.localユニットを修正する場合は、755chmod 755 /etc/rc.d/rc.local)である必要があります。誰もが誰でも書き込み可能なデーモンスクリプトを必要としているわけではありません。これは、別の問題である可能性があります。 Imho、systemdは常に妥当であるとは限りませんが、誰でも書き込み可能なスクリプトを実行できるとは思えません。

安全のために、質問にls -l /etc/rc.d/rc.localの出力を投稿してください。

EDIT2:

D'oh(私はばかげている、それはいつもそこにあり、私は気づかなかった)、あなたのユニットファイルには[Install]ディレクティブがありません:

[Install]
WantedBy=multi-user.target
4
thecarpy

Fedora 27は_ [を実行しないsystemdを使用します/etc/rc.local

AskUbunt で提案されているいくつかの解決策または回避策があります

1
PiedPiper

/etc/rc.localが「実行中」かどうかを確認するには、/ etc/rc.localに次のように入力します。

/ bin/date >> /root/test.txt

再起動して、ファイル/root/test.txtに日付があるかどうかを確認します。

0
user259526