2016年の更新
ここでの回答のほとんどは5年前のものなので、いくつかの更新の時間です。
Ubuntuはデフォルトでupstartを使用していましたが、昨年systemdを支持して放棄しました-参照：
そのため、Ubuntu wikiにUpstartユーザー向けのSystemdという素晴らしい記事があります-upstartとsystemdの非常に詳細な比較とupstartからsystemdへの移行ガイド。
（Ubuntu wikiによれば、インストールしupstart-sysvて実行することで、デフォルトで現在のバージョンのUbuntuでまだupstartを実行できますがsudo update-initramfs -u、systemdプロジェクトの範囲を考慮すると、実際にどのように動作するか、systemdがアンインストール可能。）
以下の「コマンドとスクリプト」セクションの情報のほとんどは、その記事で使用されているいくつかの例から適合しています（これは、Creative Commons Attribution-ShareAlike 3.0 Licenseの Stack Exchangeユーザーコントリビューションと同様にライセンスされています）。
一般的なコマンドと簡単なスクリプトの簡単な比較を次に示します。詳細な説明については、以下のセクションを参照してください。この回答は、質問にあるように、Upstartベースのシステムの古い動作とsystemdベースのシステムの新しい動作を比較していますが、「Upstart」というタグの付いたコマンドは必ずしもUpstart固有ではないことに注意してください。システム化されていないすべてのLinuxおよびUnixシステムに共通です。
コマンド
suの実行：
- 新興企業：
su
- systemd：
machinectl shell
（以下の「suコマンドの置換」セクションを参照）
ランニング画面：
- 新興企業：
screen
- systemd：
systemd-run --user --scope screen
（以下の「バックグラウンドプロセスの予期しない強制終了」セクションを参照）
tmuxの実行：
- 新興企業：
tmux
- systemd：
systemd-run --user --scope tmux
（以下の「バックグラウンドプロセスの予期しない強制終了」セクションを参照）
ジョブfooの開始：
- 新興企業：
start foo
- systemd：
systemctl start foo
ジョブfooの停止：
- 新興企業：
stop foo
- systemd：
systemctl stop foo
ジョブfooの再起動：
- 新興企業：
restart foo
- systemd：
systemctl restart foo
ジョブのリスト：
- 新興企業：
initctl list
- systemd：
systemctl status
ジョブfooの構成の確認：
- 新興企業：
init-checkconf /etc/init/foo.conf
- systemd：
systemd-analyze verify /lib/systemd/system/foo.service
ジョブの環境変数のリスト：
- 新興企業：
initctl list-env
- systemd：
systemctl show-environment
ジョブの環境変数の設定：
- 新興企業：
initctl set-env foo=bar
- systemd：
systemctl set-environment foo=bar
ジョブの環境変数の削除：
- 新興企業：
initctl unset-env foo
- systemd：
systemctl unset-environment foo
ログ
upstartでは、ログは/ var / log / upstartディレクトリにある通常のテキストファイルであるため、通常どおりに処理できます。
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
systemdログでは、テキストファイルではなく内部バイナリ形式で保存されるため、journalctlコマンドを使用してログにアクセスする必要があります。
sudo journalctl -u foo
sudo journalctl -u foo -f
スクリプト
で記述されたupstartスクリプトの例/etc/init/foo.conf：
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
で書かれたsystemdスクリプトの例/lib/systemd/system/foo.service：
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
suコマンドの置換
suコマンド置換は、プルリクエスト＃1022にsystemdにマージされました：
Lennart Poetteringによれば、「suは本当に壊れた概念だ」からです。
彼がいることを説明して、「あなたは以前のようにsuとsudoを使用することができますが、それは完全な形で動作することを期待していません」。
su-like動作を実現する公式の方法は次のとおりです。
machinectl shell
レナート・ポエタリング
は、＃825の議論でさらに説明しています
。
「まあ、これについては長い議論がありましたが、問題はsuが何をすべきかが非常に不明確であるということです。 、そしてそのためにそれを使用することは問題ありませんが、それは完全なログインではなく、1つと間違われるべきではありません。」-レナート・ポタリング
こちらもご覧ください：
バックグラウンドプロセスの予期しない終了
次のようなコマンド：
期待どおりに動作しなくなりました。たとえばnohup、セッションからログアウトした後にプロセスが実行し続けることを確認するPOSIXコマンドです。それはもはや機能していないにsystemdに。また、のようなプログラムscreenとは、tmux特別な方法で呼び出されるか、そうでなければ必要があるあなたがそれらを実行するプロセスが殺されます（最初の場所での画面やtmuxのを実行しているの主な理由は、通常は殺され、それらのプロセスを取得していない間）。
これは間違いではなく、意図的な決定であるため、将来修正される可能性はありません。これが、レナート・ポエタリングがこの問題について言ったことです。
私の見解では、ログアウト後にデフォルトで任意のユーザーコードが制限されないままでいるということは、実際のところUNIXではかなり奇妙でした。これは多くのOSの人々の間で長い間議論されてきましたが、これは可能ですが、確かにデフォルトではありませんが、これまでスイッチを切り替えてデフォルトからオプションに切り替えることを誰も敢えてしませんでした。ログアウト後にユーザーセッションをクリーンアップしないことは、見苦しくてややハッキングされているだけでなく、セキュリティ上の問題でもあります。 systemd 230は最終的にスイッチを切り替え、最終的にユーザーがログアウトしたときにすべてを正しくクリーンアップします。
詳細については、以下をご覧ください。
高レベルのスタートアップコンセプト
ある意味では、systemdは逆方向に動作します-upstartジョブではできるだけ早く開始し、systemdジョブでは必要なときに開始します。結局のところ、両方のシステムでほぼ同じ順序で同じジョブを開始できますが、いわば反対方向から見ていると考えます。
ここではどのように成り上がりユーザーのためにsystemdはそれを説明します：
Upstartのプロセス（ジョブ）を開始するためのモデルは「貪欲なイベントベース」です。つまり、起動イベントが発生するすべての利用可能なジョブができるだけ早く開始されます。起動中に、upstartは、startupやrcSなどの初期イベントを「ツリールート」として合成し、それらで初期サービスが開始し、前者が実行されると後のサービスが開始します。新しいジョブは、構成ファイルを/ etc / init /にインストールするだけでアクティブになります。
systemdのプロセス（ユニット）を起動するモデルは「遅延依存ベース」です。つまり、ユニットは、他の起動ユニットがそれに依存している場合にのみ起動します。ブート中に、systemdは「ルートユニット」（default.target、grubでオーバーライド可能）を開始し、その後、一時的に展開して依存関係を開始します。新しいユニットは、アクティブになるために、ブートシーケンスのユニット（通常はmulti-user.target）の依存関係として自分自身を追加する必要があります。
ディストリビューションでの使用
ウィキペディアによると、最近のいくつかのデータ：
デフォルトでupstartを使用する配布：
デフォルトでsystemdを使用する配布：
（最新情報については、ウィキペディアを参照してください）
Upstartもsystemdも使用していないディストリビューション：
論争
過去に、systemdを避けるためにDebianのフォークが提案されました。Devuan GNU + Linuxが作成されました-にsystemdなしのDebianのフォーク（おかげでするfpmurphy1コメントでそれを指摘するために）。
この論争の詳細については、以下を参照してください。
既にご存知のように、Ian Jacksonが推進したInit GR Debian投票は、Debianの遺産とそのユーザーをsystemdなだれから保護するのに役立ちませんでした。
この状況は、開発の自由を事実上脅かし、Debian、その上流および下流に深刻な結果をもたらすsystemd依存関係のロックを予想しています。
CTTEは依存関係を交換し、sysvinitを介したsystemdの微妙なインストールに時間を費やすことができましたが、このプロセスでさえ疲れ果て、ドラマでいっぱいでした。最終的に、一週間前、イアン・ジャクソンは辞任した。[...]
私はすぐに技術委員会を辞任します。
私の意見に賛同するプロジェクトの30〜40％の意見が引き続きTCに掲載されることが重要ですが、私自身はこの点で明らかに物議を醸しすぎてそうはなりません。プロジェクトのガバナンスに関する会話がパーソナライズされる程度を減らすために、私は脇に出るべきです。[...]
Devuanは、Debianのデフォルトの初期化システムとして使用する決定についての論争から生まれました。systemdでの公式のDebianの立場は、他の人が暴かれたという主張でいっぱいです。興味のある読者は、systemd論争でこのホットなトピックについて議論し続けることができます。ただし、頭を冷静に保ち、声を冷静に保つことをお勧めします。Devuanでは、振り返るよりも間違ったプログラミングに興味があります。[...]
systemdの論争に特化したいくつかのWebサイトと記事が作成されました。
ハッカーニュースに関する興味深い議論がたくさんあります。
他のディストリビューションでも同様の傾向が見られます。
哲学
upstartは、DOTADIWのUnixの哲学、「Do One Thing and Do It Well」に従っています。これは、従来のinitデーモンに代わるものです。サービスの開始と停止以外には何もしません。他のタスクは、他の特殊なサブシステムに委任されます。
systemdはそれ以上のことを行います。サービスの開始と停止に加えて、パスワード、ログイン、端末、電源管理、工場出荷時設定へのリセット、ログ処理、ファイルシステムマウントポイント、ネットワークなどを管理します。一部の機能については、NEWSファイルを参照してください。
拡張計画
よる達成し、何が待ち受けているされているものにsystemdのための展望 GNOME.asiaで2014年にレナート・ポエッタリングによるプレゼンテーションを、ここにsystemdの主な目的、すでに覆われており、現在も進行中であったものられたエリアです。
システム化された目標：
私たちの目的
すでにカバーされている領域：
すでにカバーしているもの：
initシステム、ジャーナルロギング、ログイン管理、デバイス管理、一時および揮発性ファイル管理、バイナリ形式登録、バックライトの保存/復元、rfkillの保存/復元、ブートチャート、先読み、暗号化ストレージのセットアップ、EFI / GPTパーティションの検出、仮想マシン/コンテナー登録、最小コンテナ管理、ホスト名管理、ロケール管理、時間管理、ランダムシード管理、sysctl変数管理、コンソール管理など。。。
進行中の作業：
私たちが取り組んでいるもの：
- ネットワーク管理
- systemd-networkd
- ローカルDNSキャッシュ、mDNSレスポンダー、LLMNRレスポンダー、DNSSEC検証
- カーネル内のIPC
- kdbus、sd-bus
- NTPとの時間同期
- systemd-timesyncd
- コンテナとのさらなる統合
- サービスのサンドボックス化
- アプリのサンドボックス化
- OSイメージ形式
- コンテナイメージ形式
- アプリの画像形式
- 自動検出を使用したGPT
- ステートレスシステム、インスタンス化可能なシステム、ファクトリーリセット
- / usrはOSです
- / etcは（オプション）構成です
- / varは（オプション）状態です
- アトミックノードの初期化と更新
- クラウドとの統合
- ノード間のサービス管理
- 検証可能なOSイメージ
- ファームウェアに至るまで
- ブートローディング
この回答の範囲
以下のようfpmurphy1はコメントで指摘し、「systemdには、これまでのシステム起動の単にそれを超えて年間の仕事のその範囲を拡大していることを指摘すべきです。」
ここに関連情報のほとんどを含めようとしました。ここでは、質問で尋ねられているように、initシステムとして使用されるUpstartとsystemdの一般的な機能を比較しています。また、initdシステムの範囲を超えるsystemdの機能についてのみ言及しています。これら2つのプロジェクトの違いを理解するため。詳細については、関連するドキュメントを確認してください。
詳細情報
詳細については、次を参照してください。
エクストラ
LinOxideチームは、作成したSysVの初期のLinux早見対にsystemdを。