Difference between revisions of "Systemd/User (日本語)"

From ArchWiki
Jump to: navigation, search
Line 78: Line 78:
 
[[#D-Bus|D-Bus]] を正しく設定して {{AUR|xlogin-git}} をインストールする必要があります。
 
[[#D-Bus|D-Bus]] を正しく設定して {{AUR|xlogin-git}} をインストールする必要があります。
  
Set up your [[xinitrc]] from the skeleton, so that it will source the files in {{ic|/etc/X11/xinit/xinitrc.d/}}. Running your {{ic|~/.xinitrc}} should not return, so either have {{ic|wait}} as the last command, or add {{ic|exec}} to the last command that will be called and which should not return (your window manager, for instance).
+
雛形から [[xinitrc (日本語)|xinitrc]] を設定して、{{ic|/etc/X11/xinit/xinitrc.d/}} 内のファイルが読み込まれるようにしてください。Running your {{ic|~/.xinitrc}} should not return, so either have {{ic|wait}} as the last command, or add {{ic|exec}} to the last command that will be called and which should not return (your window manager, for instance).
  
 
The session will use its own dbus daemon, but various systemd utilities need the {{ic|dbus.service}} instance. Possible solution to this is to create aliases for such commands:
 
The session will use its own dbus daemon, but various systemd utilities need the {{ic|dbus.service}} instance. Possible solution to this is to create aliases for such commands:
Line 268: Line 268:
 
=== X アプリケーションについての注意 ===
 
=== X アプリケーションについての注意 ===
  
Most X apps need a {{ic|DISPLAY}} variable to run (so it's likely the first reason why your service files aren't starting), so you have to make sure to include it:
+
ほとんどの X アプリは実行するのに {{ic|DISPLAY}} 変数を必要とします (あなたのサービスファイルが起動しない理由として第一に挙げられるでしょう)、変数を含めるようにしてください:
  
 
{{hc|$HOME/.config/systemd/user/parcellite.service|<nowiki>
 
{{hc|$HOME/.config/systemd/user/parcellite.service|<nowiki>
Line 282: Line 282:
 
</nowiki>}}
 
</nowiki>}}
  
A simpler way, if using {{AUR|user-session-units}}, is to define it in {{ic|user-session@yourloginname.service}} so it's inherited. Add {{ic|1=Environment=DISPLAY=:0}} to the {{ic|[Service]}} section. Another helpful environment variable to set here is {{ic|SHELL}}.
+
{{AUR|user-session-units}} を使っている場合は、{{ic|user-session@yourloginname.service}} の中に定義しておけば継承されるのでシンプルになります。{{ic|[Service]}} セクションに {{ic|1=Environment=DISPLAY=:0}} を追加してください。他にも {{ic|SHELL}} 環境変数をここに設定しておけば役に立ちます。
  
A cleaner way though, is to '''not''' hard code the DISPLAY environment variable (specially if you run more than on display):
+
ただし、DISPLAY 環境変数を'''決め打ちしない'''ほうがよりキレイな方法かもしれません (特に複数のディスプレイを使う場合):
  
 
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
Line 298: Line 298:
 
</nowiki>}}
 
</nowiki>}}
  
Then you can run it with:
+
次のコマンドで実行できます:
  
 
  systemctl --user {start|enable} x-app@your-desired-display.service # <= :0 in most cases
 
  systemctl --user {start|enable} x-app@your-desired-display.service # <= :0 in most cases
  
Some X apps may not start up because the display socket is not available yet. This can be fixed by adding something like
+
X アプリによってはディスプレイソケットが利用できないため起動できないことがあります。この問題はユニットに以下のように書き加えることで修正できます ({{ic|xorg.target}} は {{AUR|xorg-launch-helper}} に含まれています):
  
 
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
Line 311: Line 311:
 
...
 
...
 
</nowiki>}}
 
</nowiki>}}
 
to your units (the {{ic|xorg.target}} is part of {{AUR|xorg-launch-helper}}).
 
  
 
== 参照 ==
 
== 参照 ==

Revision as of 04:06, 23 February 2014

Template:Related articles start (日本語)

  • systemd
  • 仮想コンソールに自動ログイン
  • ログイン時に X を起動する
  • </ul></div>

    systemd はユーザーに systemd のインスタンスを実行させてユーザーのセッションやサービスを管理できる機能を提供しています。これによって systemd がユーザーによって実行されている時、特定のディレクトリに入っているユニットをユーザーが起動・停止・有効化・無効化することが可能です。このことは root や特別なユーザーではなく普通のユーザーとして通常実行される mpd などのデーモン・サービスで重宝します。

    設定

    Note: ユーザーセッションは開発中であり、いくつかの機能が欠けていたり上流でのサポートがなかったりします。現状については [1][2] を見て下さい。

    バージョン 206 から、systemd のユーザーインスタンスの仕組みが変更されています。現在、ユーザーの最初のログイン時にデフォルトで pam_systemd.so モジュールが user@.service の実行によってユーザーインスタンスを起動します。以前の systemd のバージョンと比べて、注意する必要がある差異がいくつか存在します:

    • systemd --user インスタンスはユーザーセッションの外で動きます。これは mpd などを動かすのには問題ありませんが、systemd のユーザーインスタンスからウィンドウマネージャを起動しようとする場合に支障をきたす可能性があります。ウィンドウマネージャがアクティブセッションの外で動作するために、通常ユーザーでの usb のマウントや再起動が polkit によって止められてしまいます。
    • ユーザーインスタンスのユニットは環境を継承しないため、手動で設定する必要があります。
    • user-session-unitsAURuser-session@.service は使えなくなっています。

    ユーザーインスタンスのユニットを使用する手順:

    1. systemd のユーザーインスタンスが正しく起動していることを確認してください。次のコマンドで確認することができます:
    systemctl --user status
    Note: /etc/pam.d/system-loginpam_systemd.so を実行するはずです: これには -session optional pam_systemd.so が含まれていなくてはなりません; .pacnew ファイルが存在しないか確認してください。

    2. user@.service の設定ファイルに必要な環境変数を追加してください。例えば:

    /etc/systemd/system/user@.service.d/environment.conf
    [Service]
    Environment=DISPLAY=:0

    3. ユーザーユニットを ~/.config/systemd/user に配置してください。ユーザーインスタンスが起動すると、~/.config/systemd/user/default.target のデフォルトのターゲットが実行されます。その後、systemctl --user でユーザーユニットを管理することが可能です。

    D-Bus

    ユーザーユニットで dbus を使うには、以下のファイルを作成してください:

    /etc/systemd/user/dbus.socket
    [Unit]
    Description=D-Bus Message Bus Socket
    Before=sockets.target
    
    [Socket]
    ListenStream=/run/user/%U/dbus/user_bus_socket
    
    [Install]
    WantedBy=default.target
    
    /etc/systemd/user/dbus.service
    [Unit]
    Description=D-Bus Message Bus
    Requires=dbus.socket
    
    [Service]
    ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
    ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
    

    次を実行してソケットを有効にしてください:

    # systemctl --global enable dbus.socket
    

    ユーザーの systemd インスタンスを起動するユニット user@.service はデフォルトで以下のバスパスを export してインスタンス下で動作するサービスに伝えます。

    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
    

    しかしながら、それぞれのユーザーセッションは固有の dbus デーモンインスタンスを持つべきだということが提案されました (つまり Xorg セッションのための dbus デーモンを起動するスケルトンの xinitrc を使う必要があるということ)。この問題について systemd のメーリングリスト では議論が続けられています。最終的な結論はまだ出ておらず、公式の解決策はありません。

    ディスプレイマネージャを使わずに Xorg に自動ログインする

    D-Bus を正しく設定して xlogin-gitAUR をインストールする必要があります。

    雛形から xinitrc を設定して、/etc/X11/xinit/xinitrc.d/ 内のファイルが読み込まれるようにしてください。Running your ~/.xinitrc should not return, so either have wait as the last command, or add exec to the last command that will be called and which should not return (your window manager, for instance).

    The session will use its own dbus daemon, but various systemd utilities need the dbus.service instance. Possible solution to this is to create aliases for such commands:

    ~/.bashrc
    for sd_cmd in systemctl systemd-analyze systemd-run; do
        alias $sd_cmd='DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/dbus/user_bus_socket" '$sd_cmd
    done
    

    Finally, enable (as root) the xlogin service for automatic login at boot:

    # systemctl enable xlogin@username
    

    The user session lives entirely inside a systemd scope and everything in the user session should work just fine.

    systemd のユーザーインスタンスを自動で起動する

    The systemd user instance is by default run after the first login of a user, but sometimes it may be useful to start it right after boot. Lingering is used to spawn the systemd user instance at boot and keep it running after logouts.

    Warning: systemd services are not sessions, they run outside of logind. Do not use lingering to enable automatic login as it will break the session.

    Use the following command to enable lingering for specific user:

    # loginctl enable-linger username
    

    systemd 205 以前での設定

    Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

    Reason: After systemd 206, systemd --user mechanism has changed. (See [[3]], [[4]], [[5]]) (Discuss in Talk:Systemd/User (日本語)#)

    /usr/lib/systemd/systemd --user を使ってセッションを管理する

    Systemd has many amazing features, one of which is the ability to track programs using cgroups (by running systemctl status). While awesome for a pid 1 process to do, it is also extremely useful for users, and having it set up and initialize user programs, all the while tracking what is in each cgroup is even more amazing.

    All of your systemd user units will go to $HOME/.config/systemd/user. These units take precedence over units in other systemd unit directories.

    There are two packages you need to get this working, both currently available from the AUR: systemd-xorg-launch-helper-gitAUR and optionally, systemd-user-session-units-gitAUR if you want to have autologin working.

    Next is setting up your targets. You should set up two, one for window manager and another as a default target. The window manager target should be populated like so:

    $HOME/.config/systemd/user/wm.target
    [Unit]
    Description=Window manager target
    Wants=xorg.target
    Wants=mystuff.target
    Requires=dbus.socket
    AllowIsolate=true
    
    [Install]
    Alias=default.target
    

    This will be the target for your graphical interface.

    Put together a second target called mystuff.target. All services but your window manager should contain a WantedBy line, under [Install], pointing at this unit.

    $HOME/.config/systemd/user/mystuff.target
    [Unit]
    Description=Xinitrc Stuff
    Wants=wm.target
    
    [Install]
    Alias=default.target
    

    Create a symbolic link from this unit to default.target. When you start /usr/lib/systemd/systemd --user, it will start this target.

    Next you need to begin writing services. First you should throw together a service for your window manager:

    $HOME/.config/systemd/user/YOUR_WM.service
    [Unit]
    Description=your window manager service
    Before=mystuff.target
    After=xorg.target
    Requires=xorg.target
    
    [Service]
    #Environment=PATH=uncomment:to:override:your:PATH
    ExecStart=/full/path/to/wm/executable
    Restart=always
    RestartSec=10
     
    [Install]
    WantedBy=wm.target
    
    Note: The [Install] section includes a 'WantedBy' part. When using systemctl --user enable it will link this as $HOME/.config/systemd/user/wm.target.wants/YOUR_WM.service, allowing it to be started at login. Is recommended enabling this service, not linking it manually.

    You can fill your user unit directory with a plethora of services, including ones for mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys and xmodmap to name a few.

    To exit your session, use systemctl --user exit.

    自動ログイン

    If you want to have systemd automatically log you in on boot, then you can use the unit in user-session-units to do so. Enabling a screen locker for will stop someone from booting your computer into a nice, logged in session. Add this line to /etc/pam.d/login and /etc/pam.d/system-auth:

    session    required    pam_systemd.so

    Because user-session@.service starts on tty1, you will need to add Conflicts=getty@tty1.service to the service file, if it doesn't exist already. Alternately, you can have it run on tty7 instead by modifying TTYPath accordingly as well as the ExecStart line in xorg.service (cp /usr/lib/systemd/user/xorg.service /etc/systemd/user/ and make the modifications there).

    Once this is done, systemctl --user enable YOUR_WM.service

    Note: One must be careful with tty's to keep the systemd session active. Systemd sets a session as inactive when the active tty is different from the one that the login took place. This means that the X server must be run in the same tty as the login in user-session@.service. If the tty in TTYPath does not match the one xorg is launched in, the systemd session will be inactive from the point of view of your X applications, and you will not be able to mount USB drives, for instance.

    One of the most important things you can add to the service files you will be writing is the use of Before= and After= in the [Unit] section. These two parts will determine the order things are started. Say you have a graphical application you want to start on boot, you would put After=xorg.target into your unit. Say you start ncmpcpp, which requires mpd to start, you can put After=mpd.service into your ncmpcpp unit. You will eventually figure out exactly how this needs to go either from experience or from reading the systemd manual pages. Starting with systemd.unit(5) is a good idea.

    その他の活用事例

    永続的なターミナルマルチプレクサ

    You may wish your user session to default to running a terminal multiplexer, such as GNU Screen or Tmux, in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with myStuff.target).

    To create this type of user session, procede as above, but instead of creating wm.target, create multiplexer.target:

    [Unit]
    Description=Terminal multiplexer
    Documentation=info:screen man:screen(1) man:tmux(1)
    After=cruft.target
    Wants=cruft.target
    
    [Install]
    Alias=default.target

    cruft.target, like mystuff.target above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.

    You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to /tmp/gpg-agent-info. This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.

    [Unit]
    Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
    After=gpg-agent.service
    Wants=gpg-agent.service
    
    [Service]
    Type=forking
    ExecStart=/usr/bin/tmux start
    ExecStop=/usr/bin/tmux kill-server
    Environment=DISPLAY=:0
    EnvironmentFile=/tmp/gpg-agent-info
    
    [Install]
    WantedBy=multiplexer.target

    Once this is done, systemctl --user enable tmux.service, multiplexer.target and any services you created to be run by cruft.target and you should be set to go! Activated user-session@.service as described above, but be sure to remove the Conflicts=getty@tty1.service from user-session@.service, since your user session will not be taking over a TTY. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!

    X を起動する

    You have probably noticed that, since the terminal multiplexer is now default.target, X will not start automatically at boot. To start X, proceed as above, but do not activate or manually link to default.target wm.target. Instead, assuming you are booting to a terminal, we will simply be using a hack-ish workaround and masking /usr/bin/startx with a shell alias:

    alias startx='systemctl --user start wm.target'

    ユーザーサービス

    システムサービスと同じように、ユーザーは以下のディレクトリにあるユニットを使用することができます (下のディレクトリほど優先されます):

    • /usr/lib/systemd/user/
    • /etc/systemd/user/
    • ~/.config/systemd/user/

    systemd インスタンスをコントロールするために、ユーザーはコマンド systemctl --user を使って下さい。

    パッケージでインストールされるサービス

    パッケージによってインストールされるユニットで systemd のユーザーインスタンスで実行されるように作られているものは /usr/lib/systemd/user/ にユニットがインストールされます。システムの管理者はユニットを /etc/systemd/user/ にコピーすることでユニットに修正を加えることができます。ユーザーはユニットを ~/.config/systemd/user/ にコピーすることで変更できます。

    サンプル

    以下は mpd サービスのユーザーバージョンの例です。

    mpd.service
    [Unit]
    Description=Music Player Daemon
    
    [Service]
    ExecStart=/usr/bin/mpd --no-daemon
    
    [Install]
    WantedBy=default.target
    

    変数を使用したサンプル

    以下は sickbeard.service のユーザーバージョンの例で、SickBeard が特定のファイルを見つけられるようホームディレクトリの変数を使っています:

    sickbeard.service
    [Unit]
    Description=SickBeard Daemon
    
    [Service]
    ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard
    
    [Install]
    WantedBy=default.target
    

    man systemd.unit に書かれているように、%h 変数はサービスを実行しているユーザーのホームディレクトリに置き換えられます。他にも systemd のマニュアルページで示されている変数が存在します。

    X アプリケーションについての注意

    ほとんどの X アプリは実行するのに DISPLAY 変数を必要とします (あなたのサービスファイルが起動しない理由として第一に挙げられるでしょう)、変数を含めるようにしてください:

    $HOME/.config/systemd/user/parcellite.service
    [Unit]
    Description=Parcellite clipboard manager
    
    [Service]
    ExecStart=/usr/bin/parcellite
    Environment=DISPLAY=:0 # <= !
    
    [Install]
    WantedBy=mystuff.target
    

    user-session-unitsAUR を使っている場合は、user-session@yourloginname.service の中に定義しておけば継承されるのでシンプルになります。[Service] セクションに Environment=DISPLAY=:0 を追加してください。他にも SHELL 環境変数をここに設定しておけば役に立ちます。

    ただし、DISPLAY 環境変数を決め打ちしないほうがよりキレイな方法かもしれません (特に複数のディスプレイを使う場合):

    $HOME/.config/systemd/user/x-app-template@.service
    [Unit]
    Description=Your amazing and original description
    
    [Service]
    ExecStart=/full/path/to/the/app
    Environment=DISPLAY=%i # <= !
    
    [Install]
    WantedBy=mystuff.target
    

    次のコマンドで実行できます:

    systemctl --user {start|enable} x-app@your-desired-display.service # <= :0 in most cases
    

    X アプリによってはディスプレイソケットが利用できないため起動できないことがあります。この問題はユニットに以下のように書き加えることで修正できます (xorg.targetxorg-launch-helperAUR に含まれています):

    $HOME/.config/systemd/user/x-app-template@.service
    [Unit]
    After=xorg.target
    Requires=xorg.target
    
    ...
    

    参照