https://wiki.archlinux.org/api.php?action=feedcontributions&user=Scientes&feedformat=atomArchWiki - User contributions [en]2024-03-29T10:52:10ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=KVM&diff=287343KVM2013-12-09T03:37:58Z<p>Scientes: </p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
[[it:KVM]]<br />
[[zh-CN:KVM]]<br />
{{Related articles start}}<br />
{{Related|QEMU}}<br />
{{Related|Libvirt}}<br />
{{Related|VirtualBox}}<br />
{{Related|Xen}}<br />
{{Related|VMware}}<br />
{{Related articles end}}<br />
'''KVM''', Kernel-based Virtual Machine, is a [[Wikipedia:hypervisor|hypervisor]] built into the Linux kernel. It is similar to [[Xen]] in purpose but much simpler to get running. Unlike native [[QEMU]], which uses emulation, KVM is a special operating mode of QEMU that uses CPU extensions ([[Wikipedia:Hardware-assisted virtualization|HVM]]) for virtualization via a kernel module.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status] for more information.) Each virtual machine has private virtualized hardware: a network card, disk, graphics card, etc.<br />
<br />
Differences between KVM and [[Xen]], [[VMware]], or QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
This article does not cover features common to multiple emulators using KVM as a backend. You should see related articles for such information.<br />
<br />
You may need to turn on hardware support for KVM on in your BIOS.<br />
<br />
== Checking support for KVM ==<br />
<br />
=== Hardware support ===<br />
<br />
KVM requires that the virtual machine host's processor has virtualization support (named VT-x for Intel processors and AMD-V for AMD processors). You can check whether your processor supports hardware virtualization with the following command:<br />
$ lscpu<br />
<br />
Your processor supports virtualization only if there is a line telling you so.<br />
<br />
You can also run:<br />
$ grep -E "(vmx|svm|0xc0f)" --color=always /proc/cpuinfo<br />
<br />
If nothing is displayed after running that command, then your processor does '''not''' support hardware virtualization, and you will '''not''' be able to use KVM.<br />
<br />
=== Kernel support ===<br />
<br />
You can check if necessary modules ({{ic|kvm}} and one of {{ic|kvm_amd}}, {{ic|kvm_intel}}) are available in your kernel with the following command (assuming your kernel is built with {{ic|CONFIG_IKCONFIG_PROC}}):<br />
$ zgrep CONFIG_KVM /proc/config.gz<br />
<br />
{{Note|Arch Linux kernels provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.}}<br />
<br />
=== Loading kernel modules ===<br />
<br />
You need to load {{ic|kvm}} module and one of {{ic|kvm_amd}} and {{ic|kvm_intel}} depending on the manufacturer of the VM host's CPU. See [[Kernel modules#Loading]] and [[Kernel modules#Manual module handling]] for information about loading kernel modules.<br />
<br />
If modprobing {{Ic|kvm_intel}} or {{Ic|kvm_amd}} fails but modprobing {{Ic|kvm}} succeeds, (and {{ic|lscpu}} claims that hardware acceleration is supported), check your BIOS settings. Some vendors (especially laptop vendors) disable these processor extensions by default. To determine whether there's no hardware support or there is but the extensions are disabled in BIOS, the output from {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
{{Note|Newer versions of [[udev]] should load these modules automatically, so manual intervention is not required.}}<br />
<br />
== How to use KVM ==<br />
See the main article: [[QEMU]].<br />
<br />
== Tips and tricks ==<br />
<br />
{{Note|See [[QEMU#Tips and tricks]] and [[QEMU#Troubleshooting]] for general tips and tricks.}}<br />
<br />
=== Nested virtualization ===<br />
<br />
{{Expansion|Is it possible also with {{ic|kvm_amd}}?}}<br />
<br />
On host, enable nested feature for {{ic|kvm_intel}}:<br />
# modprobe -r kvm_intel<br />
# modprobe kvm_intel nested=1<br />
<br />
To make it permanent (see [[Kernel modules#Setting module options]]):<br />
{{hc|/etc/modprobe.d/modprobe.conf|<nowiki><br />
options kvm_intel nested=1<br />
</nowiki>}}<br />
<br />
Verify that feature is activated: <br />
{{hc|<nowiki>$ systool -m kvm_intel -v | grep nested</nowiki>|<nowiki><br />
nested = "Y"<br />
</nowiki>}}<br />
<br />
Run guest VM with following command:<br />
$ qemu-system-x86_64 -enable-kvm -cpu host<br />
<br />
Boot VM and check if vmx flag is present:<br />
$ grep -E "(vmx|svm)" /proc/cpuinfo<br />
<br />
=== Poor Man's Networking ===<br />
<br />
{{Merge|QEMU|This section is not KVM-specific, it's generally applicable to all QEMU VMs.}}<br />
<br />
Setting up bridged networking can be a bit of a hassle sometimes. If the sole purpose of the VM is experimentation, one strategy to connect the host and the guests is to use SSH tunneling.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]].<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
{{poor writing|Usage of {{ic|/etc/rc.local}} is discouraged. This should be a proper [[systemd]] service file.}}<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your {{ic|/etc/rc.local}}<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
In this example a tunnel is created to the SSH server of the VM and an arbitrary port of the host is pulled into the VM.<br />
<br />
This is a quite basic strategy to do networking with VMs. However, it is very robust and should be quite sufficient most of the time.<br />
<br />
{{Accuracy|Isn't this option enough? I think it should have the same effect: {{ic|-redir tcp:2222:10.0.2.15:22}} (it redirects port 2222 from host to 10.0.2.15:22, where 10.0.2.15 is guest's IP address.}}<br />
<br />
=== Enabling huge pages ===<br />
<br />
{{Accuracy|With systemd, {{ic|hugetlbfs}} is mounted on {{ic|/dev/hugepages}} by default, but with mode 0755 and root's uid and gid.}}<br />
{{Merge|QEMU|{{Pkg|qemu-kvm}} no longer exists as all of its features have been merged into {{Pkg|qemu}}. After the above issue is cleared, I suggest merging this section into [[QEMU]].}}<br />
<br />
You may also want to enable hugepages to improve the performance of your virtual machine.<br />
With an up to date Arch Linux and a running KVM you probably already have everything you need. Check if you have the directory {{ic|/dev/hugepages}}. If not, create it. <br />
Now we need the right permissions to use this directory.<br />
<br />
Add to your {{ic|/etc/fstab}}:<br />
hugetlbfs /dev/hugepages hugetlbfs mode=1770,gid=78 0 0<br />
<br />
Of course the gid must match that of the {{ic|kvm}} group. The mode of {{ic|1770}} allows anyone in the group to create files but not unlink or rename each other's files. Make sure {{ic|/dev/hugepages}} is mounted properly:<br />
{{hc|# umount /dev/hugepages<br />
# mount /dev/hugepages<br />
$ mount <nowiki>|</nowiki> grep huge|<br />
2=hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,mode=1770,gid=78)<br />
}}<br />
<br />
Now you can calculate how many hugepages you need. Check how large your hugepages are:<br />
$ cat /proc/meminfo | grep Hugepagesize<br />
<br />
Normally that should be 2048 kB ≙ 2 MB. Let's say you want to run your virtual machine with 1024 MB. 1024 / 2 = 512. Add a few extra so we can round this up to 550. Now tell your machine how many hugepages you want:<br />
# echo 550 > /proc/sys/vm/nr_hugepages<br />
<br />
If you had enough free memory you should see:<br />
{{hc|$ cat /proc/meminfo <nowiki>|</nowiki> grep HugePages_Total|<br />
HugesPages_Total: 550<br />
}}<br />
<br />
If the number is smaller, close some applications or start your virtual machine with less memory (number_of_pages x 2):<br />
$ qemu-system-x86_64 -enable-kvm -m 1024 -mem-path /dev/hugepages -hda <disk_image> [...]<br />
<br />
Note the {{ic|-mem-path}} parameter. This will make use of the hugepages.<br />
<br />
Now you can check, while your virtual machine is running, how many pages are used:<br />
{{hc|$ cat /proc/meminfo <nowiki>|</nowiki> grep HugePages|<br />
HugePages_Total: 550<br />
HugePages_Free: 48<br />
HugePages_Rsvd: 6<br />
HugePages_Surp: 0<br />
}}<br />
<br />
Now that everything seems to work you can enable hugepages by default if you like. Add to your {{ic|/etc/sysctl.d/40-hugepage.conf}}:<br />
vm.nr_hugepages = 550<br />
<br />
See also:<br />
* https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt<br />
* http://wiki.debian.org/Hugepages<br />
* http://www.linux-kvm.com/content/get-performance-boost-backing-your-kvm-guest-hugetlbfs<br />
<br />
== See also ==<br />
* [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
* [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ]</div>Scienteshttps://wiki.archlinux.org/index.php?title=KVM&diff=287342KVM2013-12-09T03:36:03Z<p>Scientes: /* Hardware support */ Cortex A15 ARM</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[Category:Kernel]]<br />
[[it:KVM]]<br />
[[zh-CN:KVM]]<br />
{{Related articles start}}<br />
{{Related|QEMU}}<br />
{{Related|Libvirt}}<br />
{{Related|VirtualBox}}<br />
{{Related|Xen}}<br />
{{Related|VMware}}<br />
{{Related articles end}}<br />
'''KVM''', Kernel-based Virtual Machine, is a [[Wikipedia:hypervisor|hypervisor]] built into the Linux kernel. It is similar to [[Xen]] in purpose but much simpler to get running. Unlike native [[QEMU]], which uses emulation, KVM is a special operating mode of QEMU that uses CPU extensions ([[Wikipedia:Hardware-assisted virtualization|HVM]]) for virtualization via a kernel module.<br />
<br />
Using KVM, one can run multiple virtual machines running unmodified GNU/Linux, Windows, or any other operating system. (See [http://www.linux-kvm.org/page/Guest_Support_Status Guest Support Status] for more information.) Each virtual machine has private virtualized hardware: a network card, disk, graphics card, etc.<br />
<br />
Differences between KVM and [[Xen]], [[VMware]], or QEMU can be found at the [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ].<br />
<br />
This article does not cover features common to multiple emulators using KVM as a backend. You should see related articles for such information.<br />
<br />
== Checking support for KVM ==<br />
<br />
=== Hardware support ===<br />
<br />
KVM requires that the virtual machine host's processor has virtualization support (named VT-x for Intel processors and AMD-V for AMD processors). You can check whether your processor supports hardware virtualization with the following command:<br />
$ lscpu<br />
<br />
Your processor supports virtualization only if there is a line telling you so.<br />
<br />
You can also run:<br />
$ grep -E "(vmx|svm|0xc0f)" --color=always /proc/cpuinfo<br />
<br />
If nothing is displayed after running that command, then your processor does '''not''' support hardware virtualization, and you will '''not''' be able to use KVM.<br />
<br />
=== Kernel support ===<br />
<br />
You can check if necessary modules ({{ic|kvm}} and one of {{ic|kvm_amd}}, {{ic|kvm_intel}}) are available in your kernel with the following command (assuming your kernel is built with {{ic|CONFIG_IKCONFIG_PROC}}):<br />
$ zgrep CONFIG_KVM /proc/config.gz<br />
<br />
{{Note|Arch Linux kernels provide the appropriate [[Kernel_modules|kernel modules]] to support KVM.}}<br />
<br />
=== Loading kernel modules ===<br />
<br />
You need to load {{ic|kvm}} module and one of {{ic|kvm_amd}} and {{ic|kvm_intel}} depending on the manufacturer of the VM host's CPU. See [[Kernel modules#Loading]] and [[Kernel modules#Manual module handling]] for information about loading kernel modules.<br />
<br />
If modprobing {{Ic|kvm_intel}} or {{Ic|kvm_amd}} fails but modprobing {{Ic|kvm}} succeeds, (and {{ic|lscpu}} claims that hardware acceleration is supported), check your BIOS settings. Some vendors (especially laptop vendors) disable these processor extensions by default. To determine whether there's no hardware support or there is but the extensions are disabled in BIOS, the output from {{Ic|dmesg}} after having failed to modprobe will tell.<br />
<br />
{{Note|Newer versions of [[udev]] should load these modules automatically, so manual intervention is not required.}}<br />
<br />
== How to use KVM ==<br />
See the main article: [[QEMU]].<br />
<br />
== Tips and tricks ==<br />
<br />
{{Note|See [[QEMU#Tips and tricks]] and [[QEMU#Troubleshooting]] for general tips and tricks.}}<br />
<br />
=== Nested virtualization ===<br />
<br />
{{Expansion|Is it possible also with {{ic|kvm_amd}}?}}<br />
<br />
On host, enable nested feature for {{ic|kvm_intel}}:<br />
# modprobe -r kvm_intel<br />
# modprobe kvm_intel nested=1<br />
<br />
To make it permanent (see [[Kernel modules#Setting module options]]):<br />
{{hc|/etc/modprobe.d/modprobe.conf|<nowiki><br />
options kvm_intel nested=1<br />
</nowiki>}}<br />
<br />
Verify that feature is activated: <br />
{{hc|<nowiki>$ systool -m kvm_intel -v | grep nested</nowiki>|<nowiki><br />
nested = "Y"<br />
</nowiki>}}<br />
<br />
Run guest VM with following command:<br />
$ qemu-system-x86_64 -enable-kvm -cpu host<br />
<br />
Boot VM and check if vmx flag is present:<br />
$ grep -E "(vmx|svm)" /proc/cpuinfo<br />
<br />
=== Poor Man's Networking ===<br />
<br />
{{Merge|QEMU|This section is not KVM-specific, it's generally applicable to all QEMU VMs.}}<br />
<br />
Setting up bridged networking can be a bit of a hassle sometimes. If the sole purpose of the VM is experimentation, one strategy to connect the host and the guests is to use SSH tunneling.<br />
<br />
The basic steps are as follows:<br />
* Setup an SSH server in the host OS<br />
* (optional) Create a designated user used for the tunneling (e.g. tunneluser)<br />
* Install SSH in the VM<br />
* Setup authentication<br />
<br />
See: [[SSH]] for the setup of SSH, especially [[SSH#Forwarding_Other_Ports]].<br />
<br />
When using the default user network stack, the host is reachable at address 10.0.2.2.<br />
<br />
{{poor writing|Usage of {{ic|/etc/rc.local}} is discouraged. This should be a proper [[systemd]] service file.}}<br />
<br />
If everything works and you can SSH into the host, simply add something like the following to your {{ic|/etc/rc.local}}<br />
# Local SSH Server<br />
echo "Starting SSH tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -R 2213:127.0.0.1:22 -f<br />
# Random remote port (e.g. from another VM)<br />
echo "Starting random tunnel"<br />
sudo -u vmuser ssh tunneluser@10.0.2.2 -N -L 2345:127.0.0.1:2345 -f<br />
<br />
In this example a tunnel is created to the SSH server of the VM and an arbitrary port of the host is pulled into the VM.<br />
<br />
This is a quite basic strategy to do networking with VMs. However, it is very robust and should be quite sufficient most of the time.<br />
<br />
{{Accuracy|Isn't this option enough? I think it should have the same effect: {{ic|-redir tcp:2222:10.0.2.15:22}} (it redirects port 2222 from host to 10.0.2.15:22, where 10.0.2.15 is guest's IP address.}}<br />
<br />
=== Enabling huge pages ===<br />
<br />
{{Accuracy|With systemd, {{ic|hugetlbfs}} is mounted on {{ic|/dev/hugepages}} by default, but with mode 0755 and root's uid and gid.}}<br />
{{Merge|QEMU|{{Pkg|qemu-kvm}} no longer exists as all of its features have been merged into {{Pkg|qemu}}. After the above issue is cleared, I suggest merging this section into [[QEMU]].}}<br />
<br />
You may also want to enable hugepages to improve the performance of your virtual machine.<br />
With an up to date Arch Linux and a running KVM you probably already have everything you need. Check if you have the directory {{ic|/dev/hugepages}}. If not, create it. <br />
Now we need the right permissions to use this directory.<br />
<br />
Add to your {{ic|/etc/fstab}}:<br />
hugetlbfs /dev/hugepages hugetlbfs mode=1770,gid=78 0 0<br />
<br />
Of course the gid must match that of the {{ic|kvm}} group. The mode of {{ic|1770}} allows anyone in the group to create files but not unlink or rename each other's files. Make sure {{ic|/dev/hugepages}} is mounted properly:<br />
{{hc|# umount /dev/hugepages<br />
# mount /dev/hugepages<br />
$ mount <nowiki>|</nowiki> grep huge|<br />
2=hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,mode=1770,gid=78)<br />
}}<br />
<br />
Now you can calculate how many hugepages you need. Check how large your hugepages are:<br />
$ cat /proc/meminfo | grep Hugepagesize<br />
<br />
Normally that should be 2048 kB ≙ 2 MB. Let's say you want to run your virtual machine with 1024 MB. 1024 / 2 = 512. Add a few extra so we can round this up to 550. Now tell your machine how many hugepages you want:<br />
# echo 550 > /proc/sys/vm/nr_hugepages<br />
<br />
If you had enough free memory you should see:<br />
{{hc|$ cat /proc/meminfo <nowiki>|</nowiki> grep HugePages_Total|<br />
HugesPages_Total: 550<br />
}}<br />
<br />
If the number is smaller, close some applications or start your virtual machine with less memory (number_of_pages x 2):<br />
$ qemu-system-x86_64 -enable-kvm -m 1024 -mem-path /dev/hugepages -hda <disk_image> [...]<br />
<br />
Note the {{ic|-mem-path}} parameter. This will make use of the hugepages.<br />
<br />
Now you can check, while your virtual machine is running, how many pages are used:<br />
{{hc|$ cat /proc/meminfo <nowiki>|</nowiki> grep HugePages|<br />
HugePages_Total: 550<br />
HugePages_Free: 48<br />
HugePages_Rsvd: 6<br />
HugePages_Surp: 0<br />
}}<br />
<br />
Now that everything seems to work you can enable hugepages by default if you like. Add to your {{ic|/etc/sysctl.d/40-hugepage.conf}}:<br />
vm.nr_hugepages = 550<br />
<br />
See also:<br />
* https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt<br />
* http://wiki.debian.org/Hugepages<br />
* http://www.linux-kvm.com/content/get-performance-boost-backing-your-kvm-guest-hugetlbfs<br />
<br />
== See also ==<br />
* [http://www.linux-kvm.org/page/HOWTO KVM Howto]<br />
* [http://www.linux-kvm.org/page/FAQ#General_KVM_information KVM FAQ]</div>Scienteshttps://wiki.archlinux.org/index.php?title=Gitweb&diff=265070Gitweb2013-07-04T03:50:06Z<p>Scientes: </p>
<hr />
<div>[[Category:Version Control System]]<br />
Gitweb is the default web interface provided with [[git]] itself and is the basis for other git scripts like [[cgit]], [[gitosis]] and others.<br />
<br />
gitweb actually supports fcgi natively, so you don't need to wrap it as a cgi script http://repo.or.cz/w/alt-git.git?a=blob_plain;f=gitweb/INSTALL https://sixohthree.com/1402/running-gitweb-in-fastcgi-mode<br />
<br />
==Installation==<br />
To install gitweb you first have to install git and a webserver. For this example we use apache but you can also use others:<br />
pacman -S git apache<br />
<br />
Next you need to link the current gitweb default to your webserver location. In this example I use the default folder locations:<br />
ln -s /usr/share/gitweb /srv/http/gitweb<br />
<br />
{{Note|1=You may want to double check the server directory to make sure the symbolic links were made.}}<br />
<br />
That's it for the "installation". Next is the configuration.<br />
<br />
==Configuration==<br />
===Apache===<br />
Add the following to the end of your /etc/httpd/conf/httpd.conf<br />
<Directory "/srv/http/gitweb"><br />
DirectoryIndex gitweb.cgi<br />
Allow from all<br />
AllowOverride all<br />
Order allow,deny<br />
Options ExecCGI<br />
<Files gitweb.cgi><br />
SetHandler cgi-script<br />
</Files><br />
SetEnv GITWEB_CONFIG /etc/conf.d/gitweb.conf<br />
</Directory><br />
<br />
If using a virtualhosts configuration, add this to /etc/httpd/conf/extra/httpd-vhosts.conf<br />
<VirtualHost *:80><br />
ServerName gitserver<br />
DocumentRoot /var/www/gitweb<br />
<Directory /var/www/gitweb><br />
Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch<br />
AllowOverride All<br />
order allow,deny<br />
Allow from all<br />
AddHandler cgi-script cgi<br />
DirectoryIndex gitweb.cgi<br />
</Directory><br />
</VirtualHost><br />
<br />
You could also put the configuration in it's own config file in /etc/httpd/conf/extra/ but that's up to you to decide.<br />
<br />
===Lighttpd===<br />
Add the following to /etc/lighttpd/lighttpd.conf:<br />
server.modules += ( "mod_alias", "mod_cgi", "mod_redirect", "mod_setenv" )<br />
setenv.add-environment = ( "GITWEB_CONFIG" => "/etc/conf.d/gitweb.conf" )<br />
url.redirect += ( "^/gitweb$" => "/gitweb/" )<br />
alias.url += ( "/gitweb/" => "/usr/share/gitweb/" )<br />
$HTTP["url"] =~ "^/gitweb/" {<br />
cgi.assign = ( ".cgi" => "" )<br />
server.indexfiles = ( "gitweb.cgi" )<br />
}<br />
<br />
You may also need to add {{ic|".css" &#61;> "text/css"}} to the {{ic|mimetype.assign}} line for GitWeb to display properly.<br />
<br />
===Nginx===<br />
Consider you've symlinked {{ic|ln -s /usr/share/gitweb /var/www}}, append this location to your nginx configuration:<br />
{{hc|/etc/nginx/nginx.conf|<br />
<nowiki>location /gitweb/ {<br />
index gitweb.cgi;<br />
include fastcgi_params;<br />
gzip off;<br />
fastcgi_param GITWEB_CONFIG /etc/conf.d/gitweb.conf;<br />
if ($uri ~ "/gitweb/gitweb.cgi") {<br />
fastcgi_pass unix:/var/run/fcgiwrap.sock;<br />
}<br />
}</nowiki><br />
}}<br />
Additionally, we have to install {{ic|pacman -S fcgiwrap spawn-fcgi}} and modify the fcgiwrap service file:<br />
{{hc|/usr/lib/systemd/system/fcgiwrap.service|<br />
<nowiki>[Unit]<br />
Description=Simple server for running CGI applications over FastCGI<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
Restart=on-abort<br />
PIDFile=/var/run/fcgiwrap.pid<br />
ExecStart=/usr/bin/spawn-fcgi -s /var/run/fcgiwrap.sock -P /var/run/fcgiwrap.pid -u http -g http -- /usr/sbin/fcgiwrap<br />
ExecStop=/usr/bin/kill -15 $MAINPID<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
In the end, enable and restart the services:<br />
{{bc|systemctl enable nginx fcgiwrap<br />
systemctl start nginx fcgiwrap}}<br />
<br />
===Gitweb config===<br />
Next we need to make a gitweb config file. Open (or create if it does not exist) the file {{ic|/etc/gitweb.conf}} and place this in it:<br />
{{hc|/etc/gitweb.conf|<nowiki><br />
$git_temp = "/tmp";<br />
<br />
# The directories where your projects are. Must not end with a slash.<br />
$projectroot = "/path/to/your/repositories"; <br />
<br />
# Base URLs for links displayed in the web interface.<br />
our @git_base_url_list = qw(git://<your_server> http://git@<your_server>); <br />
</nowiki>}}<br />
<br />
To enable "blame" view (showing the author of each line in a source file), add the following line:<br />
$feature{'blame'}{'default'} = [1];<br />
<br />
Now the the configuration is done, please restart your webserver.<br />
For apache:<br />
systemctl restart httpd <br />
<br />
<br />
Or for lighttpd:<br />
systemctl restart lighttpd<br />
<br />
===Syntax highlighting===<br />
<br />
To enable syntax highlighting with Gitweb, you have to first install the {{Pkg|highlight}} package from <nowiki>[community]</nowiki>:<br />
pacman -S highlight<br />
<br />
When highlight has been installed, simply add this line to your {{ic|gitweb.conf}}:<br />
{{bc|<nowiki>$feature{'highlight'}{'default'} = [1];</nowiki>}}<br />
<br />
Save the file and highlighting should now be enabled.<br />
<br />
==Adding repositories==<br />
To add a repository go to your repository folder, make your repository like so:<br />
mkdir my_repository.git<br />
git init --bare my_repository.git/<br />
cd my_repository.git/<br />
touch git-daemon-export-ok<br />
echo "Short project's description" > .git/description<br />
<br />
Next open the {{ic|.git/config}} file and add this:<br />
[gitweb]<br />
owner = Your Name<br />
<br />
This will fill in the "Owner" field in gitweb. It's not required.<br />
<br />
I assumed that you want to have this repository as "central" repository storage where you push your commits to so the git-daemon-export-ok and --bare are here to have minimal overhead and to allow the git daemon to be used on it.<br />
<br />
That is all for making a repository. You can now see it on your http://localhost/gitweb (assuming everything went fine). You do not need to restart apache for new repositories since the gitweb cgi script simply reads your repository folder.<br />
<br />
==Thanks to...==<br />
This howto was mainly based on the awesome howto from howtoforge: http://www.howtoforge.com/how-to-install-a-public-git-repository-on-a-debian-server I only picked the parts that are needed to get it working and left the additional things out.</div>Scienteshttps://wiki.archlinux.org/index.php?title=Xorg_multiseat&diff=262414Xorg multiseat2013-06-11T20:37:51Z<p>Scientes: </p>
<hr />
<div>[[Category:X Server]]<br />
{{Expansion|Is it possible login two users without keyin user name and password?<br\>systemd makes this easier, cover systemd ways}}<br />
Multiseat is a certain setup where multiple users work simultaneously on one computer. This is achieved by having two monitors, two keyboards and two mice. The advantages are quite obvious:<br />
* Less power consumption (only one computer)<br />
* Less hardware to purchase<br />
* All the cool kids do it<br />
<br />
==Requirements==<br />
<br />
===Keyboards and mice===<br />
<br />
Any standard PS/2 or USB keyboards will suffice. Same thing for mice.<br />
<br />
===Graphics hardware===<br />
<br />
For the best possible result you'll need two graphics cards. I used an nVidia FX5500 AGP and an nVidia 6200 PCI. If you look around a bit you can certainly find new and decent PCI graphics card for a soft price.<br />
<br />
It is possible to use only one videocard which has dual heads (like most nvidia cards will have), but this has some limitations: you have to use Xephyr on the second monitor which seems quite a messy solution from what I've read, and for optimal usage both screens need the same resolution.<br />
<br />
If you have two pci-express slots, take advantage of them! That way you'll even be able to play two games at the same time. (PCI is too slow to play comfortably)<br />
<br />
===Processors and memory===<br />
<br />
If you really are working with two users on the same computer, I'd at least recommend a dual-core processor and plenty of RAM. A fast hard drive (10.000 RPM or higher) is also recommended for comfortable use.<br />
<br />
===Software===<br />
<br />
You'll need Xorg with the drivers for your graphics card (according to some sources, the closed source nvidia driver works better than the open source nv driver for this, I have t tested this myself) and the evdev (xf86-input-evdev) driver. That's all. All this can be found in the Arch Linux core and extra repositories.<br />
<br />
===Some X knowledge===<br />
<br />
If you know how X works this will be a lot easier. Before you start, I recommend generating a clean configuration with xorgconfig that works with a single screen. Read through this xorg configuration and make yourself familiar. And as usual the manpages will provide you with most of the answers. You may reference some man pages: xorg, xserver, startx, xdm, xinit.<br />
'''sudo X -configure''', '''X -showopts''' may give you some hint.<br />
<br />
==Definitions==<br />
<br />
For this article to be clear, I'll be using the following definitions:<br />
* screen: A screen is something Xorg can display its stuff on. A screen has a monitor and a graphics card assigned to it.<br />
* monitor: A physical monitor like the one you're now sitting in front of.<br />
* server layout: a definition of which screen, keyboard and mouse to use.<br />
* seat: A workplace with a physical monitor, physical keyboard and physical mouse.<br />
<br />
==Tips and tricks==<br />
<br />
* Set up ssh on your computer, so you can ssh to the machine from another computer (such as a laptop). This is very useful because you'll probably run into X not responding anymore or not giving you picture at all.<br />
* Finding out which keyboard and mouse is which: open a terminal and use cat to find out. For example, {{ic|cat /dev/input/mouse1}}. If you then move your mouse and you see all weird things happening than that is the mouse you're moving. Same goes for keyboards, which are called eventN.<br />
* Try a basic configuration first. Don't start with the fancy stuff yet, get a very basic Xorg working first.<br />
* Leave your {{ic|xorg.conf}} alone and create a new file, called {{ic|xorg.conf.multiseat}} in {{ic|/etc/X11}} to store your new multiseat configuration. After this configuration is working you can overwrite the {{ic|xorg.conf}} file with your new {{ic|xorg.conf.multiseat}}.<br />
* Create a backup of all relevant configuration files. What do you mean you'll skip this one?<br />
* Take a look at the full configuration I used at the end of this article before you start.<br />
<br />
==About evdev==<br />
<br />
evdev is an Xorg driver which can make use of the kernel event devices, which you can find in {{ic|/dev/input}}.<br />
<br />
==Setting up Xorg==<br />
<br />
The logic behind this is that you have two server layouts, each assigned with their own keyboard, mouse, video card and monitor. <br />
<br />
===The basics===<br />
<br />
First of all we'll set up the basics for xorg.<br />
<br />
{{bc|<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "false"<br />
Option "AutoEnableDevices" "false"<br />
Option "AllowMouseOpenFail" "on"<br />
Option "AllowEmptyInput" "on"<br />
Option "ZapWarning" "on"<br />
Option "HandleSpecialKeys" "off" # Zapping on<br />
Option "DRI2" "on"<br />
Option "Xinerama" "off"<br />
EndSection<br />
}}<br />
<br />
===Defining available input devices===<br />
<br />
This part of the configuration tells Xorg which input devices it has available. Input devices are keyboards and mice, but can also be, for example, touchscreens and pens.<br />
<br />
This section defines my first keyboard, called keyboard0. As you can seen it uses the evdev driver. {{ic|/dev/input/event1}} corresponds with the keyboard connected to the PS/2 port of my computer. Create a section like this for each keyboard you have. Don't forget to modify the identifier of course. Keep the identifier simple and match it with the other names. This keyboard0 will be used for screen0 together with mouse0.<br />
<br />
{{bc|<br />
Section "InputDevice"<br />
Identifier "keyboard0"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/event1"<br />
# Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd" <br />
# Option "Device" "/dev/input/by-id/usb-Tangtop_Generic_USBPS2-event-kbd"<br />
Option "xkb_rules" "evdev"<br />
Option "xkb_model" "evdev"<br />
Option "xkb_layout" "us"<br />
Option "GrabDevice" "on" # prevent send event to other X-servers<br />
# If you are using a non en_US keyboard, set the layout here.<br />
# Option "XkbLayout" "be"<br />
EndSection<br />
}}<br />
<br />
<br />
This section defines my first mouse, called mouse0. This uses the regular mouse driver. /dev/input/mouse2 corresponds with the mouse connected to the PS/2 port of my computer. Create a section like this for each mouse you have.<br />
<br />
{{bc|<br />
Section "InputDevice"<br />
Identifier "mouse0"<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2"<br />
Option "Device" "/dev/input/mouse2"<br />
EndSection<br />
# or use evdev, that could assign by id<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/by-id/usb-Tangtop_Generic_USBPS2-event-mouse"<br />
Option "GrabDevice" "on"<br />
EndSection<br />
}}<br />
<br />
===Graphics card===<br />
<br />
Now we'll set up the graphics card for each screen.<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "nvidia0"<br />
Driver "nvidia"<br />
Option "NoLogo" "1" # Remove nvidia branding at startup<br />
BusId "PCI:1:0:0"<br />
Option "ProbeAllGpus" "false" # Only required for nvidia<br />
EndSection<br />
}}<br />
<br />
This section defines my first graphics card, called nvidia0. This uses the closed source nvidia driver. Take a close look at the BusID. This option specifies which hardware card to use. You can find out the BusId's with lspci. However, you'll soon find out this doesn't always match. That's because lspci displays the device address in hexadecimal form. Xorg however uses decimal form. So you'll need to convert your address from hexadecimal form to decimal. Thus a device address of 0:0a:0 in lspci would become 0:10:0 in {{ic|xorg.conf}}.<br />
<br />
Create a section like this for every graphics card you have.<br />
<br />
===Screens===<br />
<br />
This section defines my first screen, called screen0. Pay close attention to the "monitor" option. For easy recognition I called it the model of my monitor.<br />
<br />
{{bc|<br />
Section "Screen"<br />
Identifier "screen0"<br />
Device "nvidia0"<br />
Monitor "l1730s"<br />
DefaultDepth 24<br />
Option "DPI" "100x100"<br />
<br />
Subsection "Display"<br />
Depth 24<br />
Modes "1280x1024" "1024x768"<br />
EndSubsection<br />
<br />
EndSection<br />
}}<br />
<br />
Create a section like this for every screen you have.<br />
<br />
===Monitors===<br />
<br />
This section defines my first monitor, l1730s. Pay close attention to the identifier.<br />
<br />
{{bc|<br />
Section "Monitor"<br />
Identifier "l1730s"<br />
HorizSync 30-93<br />
VertRefresh 60<br />
Option "dpms"<br />
EndSection<br />
}}<br />
<br />
Create section like this for every monitor you have.<br />
<br />
===Serverlayout===<br />
<br />
Here's the fun stuff. This is how everything is added up. This is my first seat, called seat0. Here I tell Xorg for the server layout called "seat0" to use my screen0, which is attached to nvidia0, using keyboard0 and mouse0.<br />
<br />
The AutoAddDevices option is now needed to keep HAL from automatically adding all your input devices to all the X servers.<br />
<br />
{{bc|<br />
Section "ServerLayout"<br />
Identifier "seat0"<br />
Screen "screen0" 0 0<br />
InputDevice "mouse0" "CorePointer"<br />
InputDevice "keyboard0" "CoreKeyboard"<br />
Option "Clone" "off"<br />
Option "AutoAddDevices" "off"<br />
Option "DisableModInDev" "true"<br />
Option "SingleCard" "on" # use this to simplfied isolatedevice option <br />
EndSection<br />
}}<br />
<br />
Create a section like this for every seat you have with their respective keyboards, mice and screens.<br />
<br />
==Testing==<br />
Before we start modifying our login manager, we'll first start with testing out the individual seats. If these are working, then we're good to go.<br />
<br />
I've used twm (tiny window manager) to test out if my seats work, but there's no reason you can't use KDE, gnome, or any other desktop environment or window manager. I've used this in my {{ic|~/.xinitrc}}:<br />
exec twm<br />
<br />
Use the following command to test out an individual seat:<br />
startx -- -layout seat0 -config xorg.conf.multiseat<br />
<br />
Do this for every seat you have. If they are all working correctly and the keyboard/mouse combination matches, then congratulations! You are almost finished! In case you are wondering why I didn't you use the full path to my new configuration file, that's because X doesn't allow that when running as non-root. It will search for xorg.conf.multiseat relative to {{ic|/etc/X11}}.<br />
<br />
==Setting up the loginmanager==<br />
<br />
===For KDM (KDE's Display Manager)===<br />
<br />
Open {{ic|/usr/share/config/kdm/kdmrc}} and set the following variables:<br />
<br />
{{bc|1=<br />
StaticServers=:0,:1 #In the case of two seats. If you have three this would become :0,:1,:2 and so forth.<br />
ReserveServers=:2,:3 #You can define here as many as you want, but these should always start at the highest seat + 1.<br />
}}<br />
Next you'll need to add an [X-:n-Core] for each seat (where n = the seat)<br />
{{bc|1=<br />
[X-:0-Core]<br />
ServerArgsLocal=-nolisten tcp -layout seat0<br />
<br />
[X-:1-Core]<br />
ServerArgsLocal=-nolisten tcp -layout seat1 -sharevts -novtswitch<br />
}}<br />
<br />
Add section like this for every seat you have, and do not forget to change the :0 and the -layout seat0. Note that the "-sharevts" and "-novtswitch" options should be added for all seats ''except'' the first one. Otherwise, you can end with rectangles of virtual terminals "showing through" on your primary screen.<br />
<br />
===For GDM (Gnome's Display Manager)===<br />
{{note|The following will work with GDM 2.20 but not with newer versions of GDM. GDM 2.20 is in AUR.}}<br />
<br />
Open {{ic|/etc/gdm/custom.conf}} and set the following variables (This sample demos two seats):<br />
{{bc|1=<br />
[servers]<br />
0=Standard0<br />
1=Standard1<br />
<br />
[server-Standard0]<br />
name=Standard server<br />
command=/usr/bin/X -nolisten tcp -novtswitch -sharevts -r -config xorg.conf.multiseat<br />
-layout seat0<br />
flexible=true<br />
<br />
[server-Standard1]<br />
name=Standard server<br />
command=/usr/bin/X -nolisten tcp -novtswitch -sharevts -r -config xorg.conf.multiseat<br />
-layout seat1<br />
flexible=true<br />
}}<br />
<br />
===For XDM (X Display Manager)===<br />
<br />
Open {{ic|/etc/X11/xdm/Xservers}} and set the following variables (This sample demos two seats):<br />
<br />
{{bc|<br />
# NOTE: don't add -sharevts on seat0, otherwise it may reset in about 10~20 minutes automatically.<br />
:0 local /usr/bin/X :0 vt07 -nolisten tcp -novtswitch -layout seat0 -config xorg.conf.multiseat<br />
:1 local /usr/bin/X :1 vt08 -nolisten tcp -sharevts -novtswitch -layout seat1 -config xorg.conf.multiseat<br />
}}<br />
<br />
Also if you use the Archlinux theme edit {{ic|/etc/X11/xdm/xdm-config}} for every screen:<br />
<br />
{{bc|<br />
DisplayManager._0.setup: /etc/X11/xdm/arch-xdm/Xsetup<br />
DisplayManager._0.startup: /etc/X11/xdm/arch-xdm/Xstartup<br />
DisplayManager._0.reset: /etc/X11/xdm/arch-xdm/Xreset<br />
DisplayManager._1.setup: /etc/X11/xdm/arch-xdm/Xsetup<br />
DisplayManager._1.startup: /etc/X11/xdm/arch-xdm/Xstartup<br />
DisplayManager._1.reset: /etc/X11/xdm/arch-xdm/Xreset<br />
}}<br />
<br />
===For Auto Login multiseat (without Display Manager)===<br />
<br />
edit a script /boot/twin.sh<br />
{{bc|<br />
#!/bin/bash<br />
cmd1="/bin/bash --login -c \"/usr/bin/xinit --"<br />
cmd2="-nolisten tcp -keeptty -novtswitch -config xorg.multiseat.conf"<br />
usr=(user1 user2) # FIXME: assume user1, user2 is valid user id<br />
declare -a pid<br />
while true ; do<br />
for ((i=0; i<${#usr[*]}; i++)) ; do<br />
echo "usr[$i]=${usr[$i]} pid=${pid[$i]}"<br />
if [ -z "${pid[$i]}" ] || [ ! -d "/proc/${pid[$i]}" ] ; then<br />
# echo "pid ${pid[$i]} killed, execute again" <br />
cmd3="-layout seat$i vt0"$((7+i))"\""<br />
if [ $i -gt 0 ] ; then<br />
cmd3="-sharevts $cmd3"<br />
fi<br />
#echo "cmd3=$cmd3"<br />
/bin/su ${usr[$i]} -l -c "$cmd1 :$i $cmd2 $cmd3" &<br />
pid[$i]=$!<br />
#echo "new pid=${pid[$i]}"<br />
fi<br />
done<br />
sleep 5 # check process exist per 5 second<br />
done<br />
}}<br />
<br />
Open {{ic|/etc/inittab}} and setup as follows:<br />
<br />
{{bc|<br />
#id:3:initdefault:<br />
id:5:initdefault:<br />
...<br />
x2:5:once:/root/twin.sh > /root/twin.log 2>&1<br />
}}<br />
<br />
==Troubleshooting==<br />
<br />
===My Windows key doesn't work anymore===<br />
<br />
Put this in [[Execute commands after X start|a startup file]]:<br />
xmodmap -e "add Mod4 = Super_L Super_R"<br />
<br />
===Unreliable behaviour (black picture without cursor)===<br />
<br />
If everything seems to be set up correctly, but for some reason you always get a black picture without a cursor, try setting the first initialized card in the BIOS to be the PCI card one.<br />
<br />
===Little black boxes/dots on the desktop===<br />
<br />
This is actually portions of the virtual terminals being painted on top of X. It seems to be caused by the Linux kernel framebuffer. This can be fixed by disabling the framebuffer, or by removing the "-sharevts" option from the primary seat's X args.<br />
<br />
===Multimedia keys not working===<br />
<br />
If your keyboard(s) has extra "multimedia" keys, you may find that they stopped working in your multiseat setup. This is because such keyboards are often represented as more then one "event" device. As you did above, cat each /dev/input/event* device, this time pressing multimedia keys. Once you've found the right event device, add a separate keyboard InputDevice section for it, then add that InputDevice section to the corresponding ServerLayout section with the "SendCoreEvents" option, which indicates that input from this device should be handled, despite not being the core keyboard. In the end you should have sections something like the following:<br />
<br />
{{bc|<br />
Section "InputDevice"<br />
Identifier "Keyboard0"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/event6"<br />
Option "XkbModel" "evdev"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "Keyboard0Multimedia"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/event7"<br />
Option "XkbModel" "evdev"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "Layout0"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
InputDevice "Keyboard0Multimedia" "SendCoreEvents"<br />
InputDevice "Mouse0" "CorePointer"<br />
Option "AutoAddDevices" "no"<br />
EndSection<br />
}}<br />
<br />
===The Ctrl-Alt-Fx, Alt-Fx keys mess up with virtual terminals===<br />
<br />
(Oct 2010) I follows this guide and everything works, except for Atl-F1, Atl-F2,... mess things up. Then I follow this guide https://help.ubuntu.com/community/MultiseatX (read the part for Ubuntu 10.04):<br />
<br />
{{bc|<br />
# cd /usr/bin<br />
# ln -s X X0<br />
# ln -s X X1<br />
}}<br />
<br />
Then fix in the '''/usr/share/config/kdm/kdmrc''' as follow<br />
<br />
{{bc|1=<br />
[General]<br />
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6<br />
ServerVTs=7,8<br />
StaticServers=:0,:1<br />
ReserveServers=:2,:3<br />
...<br />
<br />
[X-:0-Core]<br />
ServerVT=8<br />
ServerCmd=/usr/bin/X1<br />
ServerArgsLocal=-nolisten tcp -sharevts -novtswitch -keeptty -layout Seat1 -isolateDevice PCI:1:0:0<br />
<br />
[X-:1-Core]<br />
ServerVT=7<br />
ServerCmd=/usr/bin/X0<br />
ServerArgsLocal=-nolisten tcp -novtswitch -keeptty -layout Seat0 -isolateDevice PCI:0:2:0<br />
...<br />
}}<br />
<br />
It works for my computer: one on-board Intel card (xf86-video-intel driver), and one Nvidia card (xf86-video-nouveau driver). You can check if the parameters are passed correctly by:<br />
<br />
{{bc|<nowiki><br />
$ ps aux | grep 'PCI' | grep -Ev 'grep'<br />
root 16993 1.6 1.3 32900 26772 ? S 08:09 0:19 /usr/bin/X0 :1 vt7 -nolisten tcp -novtswitch -keeptty -layout Seat0 -isolateDevice PCI:0:2:0 -auth /var/run/xauth/A:1-ES6CCb<br />
root 17124 5.9 0.5 18996 11980 ? S 08:09 1:09 /usr/bin/X1 :0 vt8 -nolisten tcp -sharevts -novtswitch -keeptty -layout Seat1 -isolateDevice PCI:1:0:0 -auth /var/run/xauth/A:0-Wgiyza<br />
<br />
</nowiki>}}<br />
<br />
The '''ServerVT=7''', '''ServerVT=8''' would be pass to as '''vt7''', '''vt8'''<br />
<br />
==Final configuration==<br />
<br />
===/etc/X11/xorg.conf===<br />
<br />
This is my full xorg.conf with multiseat that works:<br />
{{bc|<br />
Section "Module"<br />
Load "dbe"<br />
<br />
SubSection "extmod"<br />
Option "omit xfree86-dga"<br />
EndSubSection<br />
<br />
Load "type1"<br />
Load "speedo"<br />
Load "freetype"<br />
Load "glx"<br />
EndSection<br />
<br />
<br />
Section "Files"<br />
RgbPath "/usr/share/X11/rgb"<br />
<br />
FontPath "/usr/share/fonts/misc"<br />
FontPath "/usr/share/fonts/75dpi"<br />
FontPath "/usr/share/fonts/100dpi"<br />
FontPath "/usr/share/fonts/TTF"<br />
FontPath "/usr/share/fonts/Type1"<br />
FontPath "/usr/share/fonts/msfonts"<br />
FontPath "/usr/share/fonts/misc2"<br />
FontPath "/usr/share/fonts/local"<br />
FontPath "/usr/local/share/fonts"<br />
EndSection<br />
<br />
<br />
Section "ServerFlags"<br />
# Option "DontZap"<br />
Option "AllowMouseOpenFail" "true"<br />
# Option "DefaultServerLayout" "alltogether"<br />
Option "Xinerama" "0"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "keyboard0"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/event1"<br />
Option "XkbModel" "evdev"<br />
Option "XkbLayout" "be"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "keyboard1"<br />
Driver "evdev"<br />
Option "Device" "/dev/input/event5"<br />
Option "XkbModel" "evdev"<br />
Option "XkbLayout" "be"<br />
EndSection<br />
<br />
<br />
Section "InputDevice"<br />
Identifier "mouse0"<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2" # Auto detect<br />
Option "Device" "/dev/input/mouse2"<br />
Option "ZAxisMapping" "4 5"<br />
EndSection<br />
<br />
Section "InputDevice"<br />
Identifier "mouse1"<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2"<br />
Option "Device" "/dev/input/mouse1"<br />
EndSection<br />
<br />
<br />
Section "Device"<br />
Identifier "nvidia0"<br />
Driver "nvidia"<br />
Option "RenderAccel" "true"<br />
Option "TripleBuffer" "True"<br />
Option "NoLogo" "1"<br />
BusId "PCI:1:0:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia1"<br />
Driver "nvidia"<br />
Option "RenderAccel" "true"<br />
Option "TripleBuffer" "True"<br />
Option "NoLogo" "1"<br />
BusId "PCI:0:10:0"<br />
EndSection<br />
<br />
<br />
Section "Screen"<br />
Identifier "screen0"<br />
Device "nvidia0"<br />
Monitor "l1730s"<br />
DefaultDepth 24<br />
Option "DPI" "100x100"<br />
<br />
Subsection "Display"<br />
Depth 24<br />
Modes "1280x1024" "1024x768"<br />
EndSubsection<br />
<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "screen1"<br />
Device "nvidia1"<br />
Monitor "cpdm151"<br />
DefaultDepth 24<br />
Option "DPI" "100x100"<br />
<br />
Subsection "Display"<br />
Depth 24<br />
Modes "1024x768" "800x600"<br />
EndSubsection<br />
<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "seat0"<br />
Screen "screen0" 0 0<br />
InputDevice "mouse0" "CorePointer"<br />
InputDevice "keyboard0" "CoreKeyboard"<br />
Option "AutoAddDevices" "off"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "seat1"<br />
Screen "screen1" 0 0<br />
InputDevice "mouse1" "CorePointer"<br />
InputDevice "keyboard1" "CoreKeyboard"<br />
Option "AutoAddDevices" "off"<br />
EndSection<br />
<br />
Section "Extensions"<br />
Option "Composite" "Disable"<br />
Option "RENDER" "Enable"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "l1730s"<br />
HorizSync 30-93<br />
VertRefresh 60<br />
Option "dpms"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "cpdm151"<br />
Option "dpms"<br />
HorizSync 30-61<br />
VertRefresh 60<br />
EndSection<br />
}}<br />
<br />
===/opt/kde/share/config/kdm/kdmrc===<br />
<br />
This is my kdmrc:<br />
<br />
{{bc|1=<br />
[General]<br />
ConfigVersion=2.3<br />
ConsoleTTYs=vc/1,vc/2,vc/3,vc/4,vc/5,vc/6<br />
PidFile=/var/run/kdm.pid<br />
ReserveServers=:2,:3<br />
ServerVTs=-7<br />
StaticServers=:0,:1<br />
<br />
[Shutdown]<br />
BootManager=Grub<br />
HaltCmd=/sbin/halt<br />
RebootCmd=/sbin/reboot<br />
<br />
[X-*-Core]<br />
AllowNullPasswd=false<br />
AllowRootLogin=false<br />
AllowShutdown=Root<br />
Authorize=true<br />
AutoReLogin=false<br />
ClientLogFile=.xsession-errors-%s<br />
Reset=/opt/kde/share/config/kdm/Xreset<br />
Resources=/opt/kde/share/config/kdm/Xresources<br />
Session=/opt/kde/share/config/kdm/Xsession<br />
SessionsDirs=/etc/X11/sessions,/usr/share/xsessions,/opt/kde/share/apps/kdm/sessions<br />
Setup=/opt/kde/share/config/kdm/Xsetup<br />
Startup=/opt/kde/share/config/kdm/Xstartup<br />
<br />
[X-*-Greeter]<br />
AllowConsole=true<br />
AntiAliasing=true<br />
AuthComplain=true<br />
BackgroundCfg=/opt/kde/share/config/kdm/backgroundrc<br />
ColorScheme=<br />
DefaultUser=<br />
EchoMode=OneStar<br />
FaceSource=PreferUser<br />
FailFont=Tahoma,11,-1,5,75,0,0,0,0,0<br />
FocusPasswd=false<br />
ForgingSeed=1097313140<br />
GUIStyle=<br />
GreetFont=Tahoma,11,-1,5,75,0,0,0,0,0<br />
GreetString=Arch Linux %r (%h)<br />
GreeterPos=50,50<br />
HiddenUsers=root<br />
Language=en_US<br />
LogoArea=None<br />
LogoPixmap=<br />
MaxShowUID=65000<br />
MinShowUID=500<br />
PreselectUser=None<br />
SelectedUsers=<br />
ShowUsers=NotHidden<br />
SortUsers=true<br />
StdFont=Tahoma,11,-1,5,50,0,0,0,0,0<br />
UseBackground=false<br />
UserCompletion=false<br />
UserList=true<br />
<br />
[X-:*-Core]<br />
AllowNullPasswd=true<br />
AllowRootLogin=true<br />
AllowShutdown=All<br />
NoPassEnable=false<br />
NoPassUsers=<br />
<br />
[X-:*-Greeter]<br />
AllowClose=true<br />
DefaultUser=glenn<br />
FocusPasswd=true<br />
LoginMode=DefaultLocal<br />
PreselectUser=Previous<br />
<br />
[X-:0-Core]<br />
AutoLoginAgain=false<br />
AutoLoginDelay=0<br />
AutoLoginEnable=false<br />
AutoLoginLocked=false<br />
AutoLoginUser=glenn<br />
ClientLogFile=.xsession-errors<br />
ServerArgsLocal=-nolisten tcp -layout seat0 -sharevts -novtswitch <br />
<br />
[X-:1-Core]<br />
ServerArgsLocal=-nolisten tcp -layout seat1 -sharevts -novtswitch <br />
<br />
[Xdmcp]<br />
Enable=false<br />
Willing=/opt/kde/share/config/kdm/Xwilling<br />
Xaccess=/opt/kde/share/config/kdm/Xaccess<br />
}}<br />
<br />
==Related problems==<br />
<br />
===PulseAudio===<br />
If two users want to use the sound card simultaneously, it is necessary to use a sound server, [[PulseAudio]] being most prevalent. Usually, the PulseAudio server runs only for active user and does not allow for multiple user instances. Solution to this problem is using the system-wide PulseAudio server. Although this approach is discouraged by its authors, it is probably most applicable setup.<br />
<br />
;Configuring for system-wide PulseAudio<br />
* Create user pulse and put him into group audio (PulseAudio drops root privileges and changes to user pulse. Group membership allows for device access.)<br />
* Create group pulse-access and put users, who will play sound locally into it (Group membership is used for access control for local access to PA daemon.)<br />
* In /etc/pulse/default.pa state explicitly the access rights<br />
{{bc|1=<br />
load-module module-native-protocol-unix auth-group=pulse-access auth-group-enable=1<br />
}}<br />
<br />
Start PA as system-wide, under root: {{bc|pulseaudio --system}}<br />
<br />
In {{ic|/var/run/pulse}} should appear files for communication with daemon, namely pid and native. <br />
<br />
;User access<br />
You can check communication with system daemon as non-root by e.g. {{ic|pactl -s "unix:/var/run/pulse/native" list}}.<br />
<br />
It is possible to enable automatic connection to local daemon in /etc/pulse/client.conf<br />
{{bc|1=<br />
auto-connect-localhost = yes<br />
}}<br />
<br />
The users should be able to connect to PA server. All the cons for system-wide daemon become essentially pros, e.g. ability to control volume of other users streams in pavucontrol.<br />
<br />
;Troubleshooting<br />
It is possible to enable the http interface to PA for debugging in /etc/pulse/default.pa<br />
{{ic|load-module module-http-protocol-tcp}} and then connect to it at http://localhost:4714/<br />
<br />
==See also==<br />
*[https://bbs.archlinux.org/viewtopic.php?id=105450 The original Arch Forums thread].<br />
<br />
*The arckwiki page [[Multi-pointer X]] explains how to setup two separate pair of devices on the same session.</div>Scienteshttps://wiki.archlinux.org/index.php?title=Systemd&diff=193219Systemd2012-04-08T01:40:02Z<p>Scientes: /* Installation */ not a systemd problem</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category: Daemons and system services (English)]]<br />
[[Category:Boot process (English)]]<br />
[[fr:Systemd]]<br />
{{i18n|Systemd}}<br />
<br />
'''systemd''' is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.<br />
<br />
See [http://0pointer.de/blog/projects/systemd.html Lennart's blog story] for a longer introduction, the two [http://0pointer.de/blog/projects/systemd-update.html status] [http://0pointer.de/blog/projects/systemd-update-2.html updates] since then, and the [http://0pointer.de/blog/projects/why.html most recent summary]. Also see the [http://en.wikipedia.org/wiki/Systemd Wikipedia article] and the [http://freedesktop.org/wiki/Software/systemd project web page].<br />
<br />
== Installation ==<br />
To try out systemd on Arch you need to:<br />
<br />
* install {{Pkg|systemd}} (and its dependencies) from [extra]<br />
* add {{Ic|1=init=/bin/systemd}} to your kernel cmdline in your bootloader<br />
<br />
:{{Note|1=If you are using grub2, kernel parameters are added in {{Ic|/etc/default/grub}} - {{Ic|1=GRUB_CMDLINE_LINUX="..."}}}}<br />
:{{Tip|1=systemd can be installed side-by-side with the regular Arch Linux initscripts, and they can be toggled by adding/removing the {{Ic|1=init=/bin/systemd}} kernel parameter.}}<br />
<br />
* To take advantage of the systemd way of starting services, you might also want the {{Pkg|systemd-arch-units}} package.<br />
<br />
{{Warning|udev and many other pieces of software expect {{ic|/usr}} to be mounted and available at bootup. If your {{Ic|/usr}} is on a separate partition, you will need to make accommodations to mount it from the initramfs and unmount it from a pivoted root on shutdown. Systemd warns you that you are breaking your system: [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken separate-usr-is-broken]}}<br />
<br />
== Native systemd configuration files ==<br />
=== Add a hostname ===<br />
{{hc|/etc/hostname|myhostname}}<br />
<br />
=== Console and keymap settings ===<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
{{hc|/etc/vconsole.conf|<nowiki><br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni</nowiki>}}<br />
<br />
=== OS info ===<br />
{{ic|/etc/os-release}} contains data that is defined by the operating system vendor and should not be changed by the administrator.<br />
{{hc|/etc/os-release|<nowiki><br />
NAME=Archlinux<br />
ID=arch<br />
PRETTY_NAME=Arch GNU/Linux<br />
ANSI_COLOR=1;34</nowiki>}}<br />
<br />
=== Locale settings ===<br />
Read {{ic|man locale.conf}} for more options <br />
{{hc|/etc/locale.conf|<nowiki><br />
LANG=en_US.utf8<br />
LC_COLLATE=C</nowiki>}}<br />
<br />
=== Configure kernel modules to load during boot ===<br />
systemd uses {{ic|/etc/modules-load.d/}} to configure kernel modules to load during boot in a static list. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored. Example:<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<nowiki><br />
# Load virtio-net.ko at boot<br />
virtio-net</nowiki>}}<br />
See also [[Modprobe#Options]]<br />
<br />
=== Configure kernel modules blacklist ===<br />
Systemd uses {{ic|/etc/modprobe.d/}} to configure the blacklisting of kernel modules. Each configuration file is named in the style of {{ic|/etc/modprobe.d/<program>.conf}}. Empty lines and lines whose first non-whitespace character is # or ; are ignored. Example:<br />
{{hc|/etc/modprobe.d/sound.conf|<nowiki><br />
blacklist snd_hda_intel</nowiki>}}<br />
or<br />
{{hc|/etc/modprobe.d/sound.conf|<nowiki><br />
install snd_hda_intel /bin/false</nowiki>}}<br />
See also [[Modprobe#Blacklisting]]<br />
<br />
=== Describe temporary files ===<br />
Systemd-tmpfiles uses the configuration files in {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/<program>.conf}}.<br />
<br />
=== Systemd Journal ===<br />
Since version 38 systemd has an own logging system, the journal.<br />
<br />
By default, running a syslog daemon is no longer required. To read the log, use:<br />
{{bc|$ systemd-journalctl}}<br />
The journal writes to {{ic|/run/systemd/journal}}, meaning logs will poof on reboot. For non-volatile logs, create {{ic|/var/log/journal}}:<br />
{{bc|# mkdir /var/log/journal}}<br />
<br />
====Journald in conjunction with a classic syslog daemon====<br />
Compatibility with classic syslog implementations is provided via a<br />
socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded.<br />
To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). For syslog-ng change {{ic|/etc/syslog-ng/syslog-ng.conf}} source section to:<br />
{{bc|<nowiki><br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};</nowiki>}}<br />
<br />
Syslog-ng's stock .service file needs to be changed for this socket to be created correctly ([http://mailman.archlinux.org/pipermail/arch-general/2012-February/025082.html arch-general post]). Copy the native .service file to {{ic|/etc/systemd/system}}:<br />
{{bc|# cp /usr/lib/systemd/system/syslog-ng.service /etc/systemd/system/}}<br />
and append the line {{ic|1=Alias=syslog.service}}:<br />
{{hc|/etc/systemd/system/syslog-ng.service|<nowiki><br />
[Unit]<br />
Description=System Logger Daemon<br />
<br />
[Service]<br />
Sockets=syslog.socket<br />
ExecStartPre=-/bin/systemctl stop systemd-kmsg-syslogd.service<br />
ExecStart=/usr/sbin/syslog-ng -F<br />
ExecReload=/bin/kill -HUP $MAINPID<br />
Sockets=syslog.socket<br />
StandardOutput=null<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
Alias=syslog.service</nowiki>}}<br />
<br />
and enable (or reenable) syslog-ng:<br />
{{bc|# systemctl enable syslog-ng.service}}<br />
<br />
By default, journald is configured to read from {{ic|/proc/kmsg}}, but this will collide with a syslog<br />
implementation doing the same ([http://lists.freedesktop.org/archives/systemd-devel/2012-January/004310.html systemd-devel post]). Disable reading /proc/kmsg by systemd-journald in {{ic|/etc/systemd/systemd-journald.conf}}:<br />
ImportKernel=no<br />
<br />
=== Static network ===<br />
Create {{ic|/etc/conf.d/network}} file with following content:<br />
address=<br />
netmask=<br />
broadcast=<br />
gateway=<br />
Change a values as you need.<br />
<br />
Then create network@.service file in {{ic|/etc/systemd/system/}}<br />
<br />
[Unit]<br />
Description=Network Connectivity<br />
Wants=network.target<br />
Before=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
EnvironmentFile=/etc/conf.d/network<br />
ExecStart=/sbin/ip link set dev %I up<br />
ExecStart=/sbin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev %I<br />
ExecStart=/sbin/ip route add default via ${gateway}<br />
ExecStop=/sbin/ip addr flush dev %I<br />
ExecStop=/sbin/ip link set dev %I down<br />
<br />
[Install]<br />
Alias=multi-user.target.wants/network@%I.service<br />
<br />
Start service:<br />
# systemctl start network@eth0.service<br />
<br />
Add to start at boot:<br />
# ln -sf /etc/systemd/system/network@.service /etc/systemd/system//multi-user.target.wants/network@eth0.service<br />
<br />
Replace eth0 with other device name if needed.<br />
<br />
=== Remote filesystem mounts ===<br />
If you have NFS mounts listed in {{ic|/etc/fstab}} then systemd will attempt to mount them but will typically do so too early (before networking has been configured). To get the timing correct we need to tell systemd explicitly that the mount depends on networking and on rpc.statd. To do this, create a file under {{ic|/etc/systemd/system}} named {{ic|<mount-unit-name>.mount}} with contents as follows.<br />
<br />
[Unit]<br />
Description=<mountpoint><br />
Wants=network.target rpc-statd.service<br />
After=network.target rpc-statd.service <br />
<br />
[Mount]<br />
What=<server>:<share><br />
Where=<mountpoint><br />
Type=nfs<br />
StandardOutput=syslog<br />
StandardError=syslog<br />
<br />
In the above<br />
*mount-unit-name is the full path to the mountpoint in an escaped format. For example, a mount unit for {{ic|/usr/local}} must be named {{ic|usr-local.mount}}.<br />
*mountpoint is the local mountpoint<br />
*server:share specify the remote filesystem in the same manner as for {{ic|/etc/fstab}}<br />
<br />
See systemd.unit(5) and systemd.mount(5) for further details.<br />
<br />
A similar approach will probably be required for other remote filesystem types such as nfs4 and cifs.<br />
<br />
Alternatively, you can mark these entries in {{ic|/etc/fstab}} with the option ''comment=systemd.automount''. Make sure that if you also include 'defaults' as a mount option, that you override the implicit 'auto' with 'noauto'. This will cause the device to be mounted on first access, similar to [[Autofs]].<br />
<br />
== Using systemd ==<br />
<br />
*systemctl: used to introspect and control the state of the systemd system and service manager<br />
*systemd-cgls: recursively shows the contents of the selected Linux control group hierarchy in a tree<br />
*systemadm: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd.<br />
<br />
View the man pages for more details. <br />
<br />
Listing running services<br />
<br />
{{bc|$ systemctl}}<br />
<br />
or<br />
<br />
{{bc|$ systemctl list-units}}<br />
<br />
The available services or units can be seen in {{ic|/lib/systemd/system}} and {{ic|/etc/systemd/system}} (the latter takes precedence).<br />
<br />
Activates a service immediately:<br />
<br />
{{bc|# systemctl start <service>}}<br />
<br />
Deactivates a service immediately:<br />
<br />
{{bc|# systemctl stop <service>}}<br />
<br />
Restarts a service:<br />
<br />
{{bc|# systemctl restart <service>}}<br />
<br />
Reloads a service:<br />
<br />
{{bc|# systemctl reload <service>}}<br />
<br />
Shows status of a service including whether it is running or not:<br />
<br />
{{bc|# systemctl status <service>}}<br />
<br />
Enables a service to be started on bootup:<br />
<br />
{{bc|# systemctl enable <service>}}<br />
<br />
Disables a service to not start during bootup:<br />
<br />
{{bc|# systemctl disable <service>}}<br />
<br />
Refer to {{Ic|man systemctl}} for more details. <br />
<br />
Notice that you need to use the full name of a service file. E.g., in order to restart the avahi daemon, issue:<br />
<br />
{{bc|# systemctl restart avahi-daemon.service}}<br />
<br />
Shut down and reboot the system <br />
<br />
{{bc|# systemctl reboot}}<br />
<br />
Shut down and power-off the system<br />
<br />
{{bc|# systemctl poweroff}}<br />
<br />
Shut down and halt the system<br />
<br />
{{bc|# systemctl halt}}<br />
<br />
== Runlevels/targets ==<br />
Systemd has a concept of ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose. Some ''targets'' are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are systemd ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command. <br />
<br />
=== Get current runlevel/targets ===<br />
Runlevel command still works with systemd. You can continue using that however runlevels is a legacy concept in systemd and is emulated via 'targets' and multiple targets can be active at the same time. So the equivalent in systemd terms is<br />
{{bc|1=# systemctl list-units --type=target}}<br />
<br />
=== Create custom target ===<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd ''target'' as {{ic|/etc/systemd/system/$YOURTARGET}} that takes one of the existing runlevels as a base (you can look at {{ic|/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/$YOURTARGET.wants}}, and then symlink the additional services that you want to enable into that directory. (The service unit files that you symlink live in {{ic|/lib/systemd/system}}).<br />
<br />
=== Targets table ===<br />
{| border="1"<br />
!SystemVinit Runlevel!!Systemd Target!!Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current runlevels ===<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
{{bc|# systemctl isolate runlevel5.target}}<br />
Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:<br />
{{bc|# systemctl isolate graphical.target}}<br />
This will only change the current runlevel, and has no effect on the next boot.<br />
<br />
=== Change default runlevel/target to boot into ===<br />
The standard target is default.target, which is aliased by default to graphical.target (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your GRUB kernel line:<br />
* systemd.unit=multi-user.target (which roughly corresponds to the old runlevel 3),<br />
* systemd.unit=rescue.target (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change default.target. This can be done using systemctl:<br />
{{bc|# systemctl enable multi-user.target}}<br />
<br />
The effect of this command is outputted by systemctl; a symlink to the new default target is made at /etc/systemd/system/default.target. This works if and only if<br />
[Install]<br />
Alias=default.target<br />
is in the target's configuration file. Currently, multi-user.target and graphical.target both have it.<br />
<br />
== Running DEs under systemd ==<br />
<br />
=== Using display manager ===<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for gdm, kdm and slim, but there is not one for xdm.<br />
<br />
{{bc|# systemctl enable kdm.service}}<br />
<br />
This should work out of the box. If not, you might have a default.target set manually or from a older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and systemd will use its stock default.target (i.e. graphical.target).<br />
<br />
{{bc|# rm /etc/systemd/system/default.target}}<br />
<br />
On KDE start an error message will appear saying "console-kit-daemon.unit" could not be found. To solve this problem, install {{ic|systemd-arch-units}}.<br />
<br />
If /etc/locale.conf is used for setting the locale, add an entry to {{ic|/etc/environment}}<br />
{{hc|/etc/environment|<nowiki><br />
LANG=en_US.utf8</nowiki>}}<br />
<br />
=== Using service file ===<br />
If you are only looking for a simple way to start X directly without a display manager, you can create a service file similar to this:<br />
<br />
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|<nowiki><br />
[Unit]<br />
Description=Direct login to X<br />
Requires=dev-tty7.device<br />
After=dev-tty7.device systemd-user-sessions.service<br />
<br />
[Service]<br />
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"<br />
<br />
[Install]<br />
WantedBy=graphical.target<br />
</nowiki>}}<br />
<br />
== Arch integration ==<br />
<br />
Integration with Arch's classic configuration is accomplished via the {{ic|initscripts-systemd}} package. This is an optional package which can be used to ease the transition from sysVinit to systemd.<br />
<br />
{{ic|/etc/inittab}} is not used at all.<br />
<br />
{{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} can be run at startup and shutdown by enabling rc-local.service.<br />
<br />
=== rc.conf ===<br />
Some variables in {{ic|/etc/rc.conf}} are respected by this glue work. For a pure systemd setup it is recommended to use the native systemd configuration files (such as {{ic|/etc/locale.conf}}, {{ic|/etc/vconsole.conf}}, {{ic|/etc/hostname}}, {{ic|/etc/modules-load.d/*.conf}}) which will take precedence over {{ic|/etc/rc.conf}}.<br />
<br />
Supported variables:<br />
* LOCALE<br />
* KEYMAP<br />
* CONSOLEFONT<br />
* CONSOLEMAP<br />
* HOSTNAME<br />
* MODULES<br />
* DAEMONS: Ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by {{ic|systemctl disable arch-daemons.target}}<br />
<br />
Not supported variables and systemd configuration:<br />
* TIMEZONE: Please symlink {{Ic|/etc/localtime}} to your zoneinfo file manually.<br />
* HARDWARECLOCK: Use {{ic|hwclock --systohc --utc}} to set your hardware clock to utc, localtime is not supported, see [[Systemd#Q: Why does systemd not support the RTC being in localtime?|FAQ]].<br />
* USELVM: use lvm.service provided by systemd-arch-units instead.<br />
* USECOLOR<br />
<br />
=== Initscripts package ===<br />
{{ic|initscripts-systemd}} contains unit files and scripts that are needed to emulate Arch's initscripts.<br />
<br />
{{warning|Unless you require the functionality from lvm.service or dmraid.service, usage of this package is not recommended. In particular, arch-persistent-settings.service and arch-daemons.target are unsupported as a long term solution and will be removed in the future. When ever possible, use native systemd configuration files instead.}}<br />
<br />
Most people will not need all (if any) of these units, and they can be easily disabled by doing<br />
{{bc|# systemctl disable <unitfile>}}<br />
if you determine that you do not want a particular unit.<br />
<br />
The plan is to remove most of the functionality from this package as soon as it is handled elsewhere (mostly in udev/systemd/kernel).<br />
<br />
The following is a brief description of the functionality of each of them. Alternative solutions are provided as a migration plan away from the functionality provided by this package.<br />
<br />
==== lvm.service ====<br />
Copies Arch's handling of LVM. Only needed if you use non-root LVM. In the future systemd will probably deal with this natively (in a much cleaner and more robust way).<br />
<br />
==== rc-local.service ====<br />
Runs /etc/rc-local (resp., /etc/rc-local.shutdown) on boot (resp., shutdown).<br />
<br />
==== arch-daemons.target ====<br />
Parses the DAEMONS array in {{ic|/etc/rc.conf}} and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used; otherwise, the script in {{ic|/etc/rc.d/}} is used to control the unit.<br />
<br />
Alternative: use native unit files from the [http://www.archlinux.org/packages/community/any/systemd-arch-units/ systemd-arch-units] package<br />
<br />
==== arch-persistent-settings.service ====<br />
This is run at shutdown. Its aim is to make sure that any Arch Linux settings are applied on the next boot. In particular:<br />
* Sets the timezone based on {{ic|/etc/rc.conf}}. Alternative: Create {{ic|/etc/localtime}} as a symlink to your timezone file in {{ic|/usr/share/zoneinfo}}.<br />
* Updates modle blacklists based on {{ic|/etc/rc.conf}} (see {{ic|/etc/modprobe.d/rc.conf}}). Alternative: Create a differently named copy of this file in {{ic|/etc/modprobe.d}}.<br />
* Updates list of modules to be loaded based on {{ic|/etc/rc.conf}} (see {{ic|/etc/modules-load.d/rc.conf}}). Alternative: Create a differently named copy of this file in {{ic|/etc/modules-load.d}}.<br />
<br />
== Helping out ==<br />
Currently, systemd is mostly at feature parity with Arch's initscripts. However, a lot more testing is needed. If you would like to help out, you can fork the [https://github.com/falconindy/initscripts-systemd initscripts-systemd] or [http://github.com/falconindy/systemd-arch-units systemd-arch-units] git repos and submit pull requests for your additions.<br />
<br />
If you have any questions, ask in the [https://bbs.archlinux.org/viewtopic.php?id=96316&p=1 thread] in the Arch forums.<br />
<br />
== FAQ ==<br />
For an up-to-date list of known issues, look at the upstream [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].<br />
<br />
{{FAQ<br />
|question=Why are my console fonts ugly?<br />
|answer=If no font is set in {{ic|/etc/vconsole.conf}} (or alternatively {{ic|/etc/rc.conf}}), then a standard font will be used. The standard font is chosen due to it supporting a wide range of character sets. Set your preferred font to fix the issue.}}<br />
<br />
{{FAQ<br />
|question=Why do I get log messages on my console?<br />
|answer=You must set the kernel loglevel yourself. Historically, {{ic|/etc/rc.sysinit}} did this for us and set dmesg loglevel to '3', which was a reasonably quiet loglevel. Either add 'loglevel=3' or 'quiet' to your kernel cmdline.}}<br />
<br />
{{FAQ<br />
|question=Why does systemd not support the RTC being in localtime?<br />
|answer=In principle, there is nothing stopping you from adding some unit files that will allow the RTC to be in localtime, but there are a few reasons why we have not (and probably will not) implement it by default:<br />
<br />
* The reason for allowing the RTC to be in localtime was to allow dualboot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx who uses localtime]). However, for some time now, Windows has been able to deal with the RTC being in UTC by setting the following registry key<br />
:{{bc|HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal}}<br />
:This needs to be a DWORD key with a value of 1.<br />
:{{Warning|On recent systems (Windows 7, Vista SP2) this setting prevents Windows from being able to update the system clock at all, [http://social.msdn.microsoft.com/forums/en-US/tabletandtouch/thread/0b872d8a-69e9-40a6-a71f-45de90c6e243/ and earlier versions do not work correctly when resuming from suspend or hibernate]. In addition, recent systems [http://support.microsoft.com/kb/2687252 may become unresponsive during Daylight Saving Time (DST) changeover if RealTimeIsUniversal is set].}}<br />
<br />
* Dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]).<br />
* Recent kernels set the system time from the RTC directly on boot without using 'hwclock', the kernel will always assume that the RTC is in UTC. This means that if the RTC is in localtime, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is possibly the reason for certain weird bugs (time going backwards is rarely a good thing).}}<br />
<br />
{{FAQ<br />
|question=How do I make a custom unit file?<br />
|answer=The unit files in {{ic|/etc/systemd/system}} take precedence over the ones in {{ic|/lib/systemd/system}}. To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from {{ic|/lib}} to {{ic|/etc}} and make your changes there.}}<br />
<br />
{{FAQ<br />
|question=How do I change the number of gettys running by default?<br />
|answer=To add another getty:<br />
<br />
Simply place another symlink for instantiating another getty in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service<br />
# systemctl daemon-reload<br />
# systemctl start getty@tty9.service</nowiki>}}<br />
<br />
To remove a getty:<br />
<br />
Simply remove the getty symlinks you want to get rid of in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service<br />
# systemctl daemon-reload<br />
# systemctl stop getty@tty5.service getty@tty6.service</nowiki>}}<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only 1 getty will be launched by default. If you switch to another tty, a getty will be launched there (socket-activation style). You can still force additional agetty processes to start using the above methods.}}}}<br />
<br />
{{FAQ<br />
|question=How do I get more verbose output during boot?<br />
|answer=By default systemd does not give much (if any) output during boot. Firstly, lots of output from services running in parallel would be very messy, and secondly, boot is supposed to be so fast that status messages would slow it down.<br />
<br />
If you append the kernel parameter "verbose" to your kernel line in GRUB, you will get lots of output during boot. However, this is only really meant as a debugging tool as it is not very useful during normal use. Any messages are logged to the system log and if you want to find out about the status of your system<br />
{{bc|$ systemctl}}<br />
is your friend.}}<br />
<br />
{{FAQ<br />
|question=What kernel options do I need to enable in my kernel in case I do not use the official Arch kernel?<br />
|answer=Kernels prior to 2.6.39 are unsupported.<br />
<br />
This is a partial list of required/recommended options, there might be more:<br />
<br />
{{bc|<nowiki><br />
CONFIG_DEVTMPFS=y<br />
CONFIG_CGROUPS=y<br />
CONFIG_AUTOFS4_FS=[y|m]<br />
CONFIG_IPV6=[y|m], optional, but highly recommended<br />
CONFIG_RTC_DRV_CMOS=y, optional, but highly recommended<br />
CONFIG_FANOTIFY=y, optional, required for systemd readahead.<br />
CONFIG_UEVENT_HELPER_PATH should be empty, if you want to use systemd without initramfs<br />
CONFIG_AUDIT=y optional, but recommended<br />
CONFIG_TMPFS_POSIX_ACL=y recommended, if you want pam_systemd.so to setup your "seats"<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y<br />
</nowiki>}}<br />
<br />
{{Note|Schedulers such as BFS which avoid cgroup facilities are unsupported by systemd.}}}}<br />
<br />
{{FAQ<br />
|question=What other units does a unit depend on?<br />
|answer=For example, if you want to figure out which services a target like multi-user.target pulls in, use something like this: <br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service netfs.service}}<br />
<br />
Instead of "Wants" you might also try "WantedBy", "Requires", "RequiredBy", "Conflicts", "ConflictedBy", "Before", "After" for the respective types of dependencies and their inverse.}}<br />
<br />
== Optimization ==<br />
=== Less output ===<br />
Change 'verbose' to 'quiet' on the kernel line in GRUB. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
=== Early start ===<br />
One central feature of systemd is dbus and socket activation, this causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like console-kit) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
{{bc|# systemctl enable console-kit-daemon.service}}<br />
<br />
This will cause systemd to start console-kit as soon as possible, without causing races with the socket or dbus activation.<br />
<br />
=== Automount ===<br />
The default setup will fsck and mount all filesystems before starting most daemons and services. If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is being fsck'ed. This can be achieved by adding the following options to the fstab entry of your {{ic|/home}} partition<br />
<br />
comment=systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
=== /etc/mtab ===<br />
{{note|As of filesystem-2011.12, /etc/mtab is now symlinked to /proc/self/mounts.}} <br />
<br />
systemd requires that {{ic|/etc/mtab}} be a symlink to {{ic|/proc/self/mounts}}, or the following warning will be printed:<br />
<br />
''/etc/mtab is not a symlink or not pointing to /proc/self/mounts. This is not supported anymore. Please make sure to replace this file by a symlink to avoid incorrect or misleading mount(8) output.''<br />
<br />
Replace the file with a symlink with {{ic|ln}}:<br />
<br />
{{bc|# ln -fs /proc/self/mounts /etc/mtab}}<br />
<br />
Without doing this, features such as automounting through {{ic|/etc/fstab}} will be unavailable.<br />
<br />
=== Disabling native mount ===<br />
With v12 or later, you can disable the native mount and fsck facility in {{ic|/etc/systemd/system.conf}}.<br />
MountAuto=no<br />
SwapAuto=no<br />
{{Note|These options are enabled by default.}}<br />
<br />
=== Readahead ===<br />
systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:<br />
<br />
{{bc|<nowiki># systemctl enable systemd-readahead-collect.service<br />
# systemctl enable systemd-readahead-replay.service</nowiki>}}<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
=== User sessions ===<br />
systemd can divide user sessions into cgroups. Add "session optional pam_systemd.so" to your relevant {{ic|/etc/pam.d}} files (e.g., login for tty logins, sshd for remote access, kde for password kdm logins, kde-np for automatic kdm logins).<br />
<br />
Before:<br />
{{hc|$ systemd-cgls systemd:/system/getty@.service|<br />
systemd:/system/getty@.service:<br />
├ tty5<br />
│ └ 904 /sbin/agetty tty5 38400<br />
├ tty2<br />
│ ├ 13312 /bin/login --<br />
│ └ 15765 -zsh<br />
[…]}}<br />
After:<br />
{{hc|$ systemd-cgls systemd:/user/example/|<br />
systemd:/user/example/:<br />
├ 4<br />
│ ├ 902 /bin/login --<br />
│ └ 16016 -zsh<br />
[…]}}<br />
<br />
== See also==<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official Web Site]<br />
*[http://0pointer.de/public/systemd-man/ Manual Pages]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://bbs.archlinux.org/viewtopic.php?pid=792280 Discussion on the bbs.archlinux.org]<br />
*[http://en.gentoo-wiki.com/wiki/Systemd About systemd in Gentoo Wiki]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug Systemd problems]<br />
*[https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs Background information about systemd journal]</div>Scientes