https://wiki.archlinux.org/api.php?action=feedcontributions&user=Oliva&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:39:45ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Android_tethering&diff=309922Android tethering2014-04-10T14:36:19Z<p>Oliva: removed unnecessary usb debug requirement</p>
<hr />
<div>[[fr:Modem attache Android]]<br />
[[Category:Networking]]<br />
[[Category:Mobile devices]]<br />
Tethering is a way to have internet access on your PC through your smartphone using its network connection. USB tethering and Wi-Fi access point tethering are natively supported since Android Froyo (2.2). In older versions of the Android OS, most unofficial ROMs have this option enabled.<br />
<br />
== Wi-Fi access point ==<br />
Using an Android phone as a Wi-Fi access point (using 3G) has been accessible by default since Froyo (Android 2.2) without needing to root the phone. Moreover, this method will discharge the battery rapidly and tends to cause intense heating, unlike USB.<br />
See : '''menu/wireless & networks/Internet tethering/Wi-Fi access point'''<br />
<br />
== USB tethering ==<br />
<br />
===Tools Needed===<br />
* Root access to the phone (for old Android versions, Froyo (Android 2.2) and beyond can do it natively)<br />
* USB connection cable from your phone to PC<br />
<br />
=== Procedure ===<br />
* Disconnect your computer from any wireless or wired networks<br />
* Connect the phone to your computer using the USB cable (the USB connection mode -- Phone Portal, Memory Card or Charge only -- is not important, but please note that you will not be able to change the USB mode during tethering)<br />
* Enable the tethering option from your phone. This is usually done from {{ic|Settings --> Wireless & Networks --> Internet tethering}} (or {{ic|Tethering & portable hotspot}}, for more recent versions)<br />
* Make sure that the USB interface is recognized by the system by using the following command:<br />
: {{bc|$ ip link}}<br />
: You should be able to see a {{ic|usb0}} or {{ic|enp?s??u?}} device listed like this (notice the enp0s20u3 device).<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default <br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000<br />
link/ether ##:##:##:##:##:## brd ff:ff:ff:ff:ff:ff<br />
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000<br />
link/ether ##:##:##:##:##:## brd ff:ff:ff:ff:ff:ff<br />
5: enp0s20u3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000<br />
link/ether ##:##:##:##:##:## brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
{{Note|Take care to use the device name from your own system in the following commands.}}<br />
<br />
{{Warning|The name may change depending on the usb port you use. You may want to [[Network configuration#Change_device_name|change the device name]] to create a unique name for your device regardless of the usb port.}}<br />
<br />
* The final step is to [[Network configuration#Configure the IP address|configure a network connection]] on this interface.<br />
<br />
==USB tethering with OpenVPN==<br />
This method works for any old Android version and requires neither root access nor modifications in the phone (it is also suitable for Android 2.2 and later, but no longer required).<br />
<br />
It does not require changes to your browser. In fact, all network traffic is transparently handled for any PC application (except ICMP pings). It is somewhat CPU intensive on the phone at high usage rates (a 500 kBytes/sec data transfer rate may take more than 50% of phone CPU on a powerful Acer Liquid).<br />
<br />
===Tools Needed===<br />
For Arch, you need to [[pacman|install]] the {{pkg|openvpn}} package. It is also required to have the Android SDK installed (which can be obtained [http://developer.android.com/sdk/index.html here] or from the AUR). On the phone, you need the [http://code.google.com/p/azilink/ azilink] application, which is a Java-based NAT that will communicate with OpenVPN on your computer.<br />
<br />
====Configuring the phone connection in Arch Linux====<br />
<br />
Once you have installed the Android SDK, in order to use the provided tools your phone must be properly set up in [[udev]] and your Linux user needs to be granted rights. Otherwise you may need root privileges to use the Android SDK, which is not recommended. To perform this configuration, turn on USB debugging on the phone (usually in Settings -> Applications -> Development -> USB debugging), connect it to the PC by the USB cable and run the {{ic|lsusb}} command. The device should be listed. Example output for the Acer Liquid phone:<br />
<br />
Bus 001 Device 006: ID '''0502''':3202 Acer, Inc. <br />
<br />
Then, create the following file, replacing ''ciri'' by your own Linux user name, and '''0502''' by the vendor ID of your own phone:<br />
<br />
{{hc|/etc/udev/rules.d/51-android.rules|<nowiki><br />
SUBSYSTEM=="usb", ATTR(idVendor)=="0502", MODE="0666" OWNER="ciri"<br />
</nowiki>}}<br />
<br />
As root run the {{ic|udevadm control restart}} command (or reboot your computer) to make the change effective.<br />
<br />
Now run in your linux PC the {{ic|adb shell}} command from the Android SDK as plain (non root) user: you should get a unix prompt ''in your phone''.<br />
<br />
===Procedure===<br />
Run the AziLink application in the phone and select "About" at the bottom to receive instructions, which basically are:<br />
<br />
# You will have to enable USB debugging on the phone if it was not already enabled (usually in Settings -> Applications -> Development -> USB debugging).<br />
# Connect the phone with the USB cable to the PC.<br />
# Run AziLink and make sure that the '''Service active''' option at the top is checked.<br />
# Run the following commands in your Linux PC:<br />
: {{bc|$ adb forward tcp:41927 tcp:41927}}<br />
: {{bc|# openvpn AziLink.ovpn}}<br />
<br />
{{hc|AziLink.ovpn|<nowiki><br />
dev tun<br />
remote 127.0.0.1 41927 tcp-client<br />
ifconfig 192.168.56.2 192.168.56.1<br />
route 0.0.0.0 128.0.0.0<br />
route 128.0.0.0 128.0.0.0<br />
socket-flags TCP_NODELAY<br />
keepalive 10 30<br />
dhcp-option DNS 192.168.56.1<br />
</nowiki>}}<br />
<br />
===Troubleshooting===<br />
<br />
====DNS====<br />
You may need to manually update the contents of [[resolv.conf]] to<br />
<br />
{{hc|/etc/resolv.conf|<br />
nameserver 192.168.56.1<br />
}}<br />
<br />
====NetworkManager====<br />
If you're running NetworkManager, you may need to stop it before running OpenVPN.<br />
<br />
==Tethering via Bluetooth==<br />
<br />
Android (from at least 4.0 onwards, possibly earlier) can provide a Bluetooth personal-area network (PAN) in access point mode.<br />
<br />
NetworkManager can perform this action and handle the network initialisation itself; consult its documentation for more details. <br />
<br />
Alternatively: pair and ensure you can connect your computer and Android device, as described on [[Bluetooth]], then, substituting the address of the device (here given as {{ic|AA_BB_CC_DD_EE_FF}}), do:<br />
<br />
{{bc|<nowiki>$ dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF org.bluez.Network1.Connect string:'nap'</nowiki>}}<br />
<br />
This will create a network interface {{ic|bnep0}}. Finally, [[Network configuration#Configure the IP address|configure a network connection]] on this interface; Android offers DHCP by default.<br />
<br />
==Tethering with SOCKS proxy==<br />
<br />
With this method tethering is achieved by port forwarding from the phone to the PC. This is suitable only for browsing. For Firefox, you should set '''network.proxy.socks_remote_dns''' to '''true''' in '''about:config''' ( address bar )<br />
<br />
===Tools Needed===<br />
* {{AUR|android-sdk}}, {{AUR|android-sdk-platform-tools}}, and {{AUR|android-udev}} packages from AUR<br />
* USB connection cable from your phone to PC<br />
* Either [http://graha.ms/androidproxy/ Tetherbot] or [https://code.google.com/p/proxoid/ Proxoid]<br />
<br />
===Instructions===<br />
====Tetherbot====<br />
Follow the instructions under '''Using the Socks Proxy''' on [http://graha.ms/androidproxy/].<br />
<br />
====Proxoid====<br />
Follow the instructions demonstrated in the following [http://androidcommunity.com/forums/f23/android-usb-tethering-for-linux-using-proxoid-24875/ link]</div>Olivahttps://wiki.archlinux.org/index.php?title=Talk:Android_tethering&diff=309921Talk:Android tethering2014-04-10T14:36:12Z<p>Oliva: </p>
<hr />
<div>net-toools has been depracated. Is there any chance someone would be able to update this to reflect usage of iproute2.<br />
<br />
https://www.archlinux.org/news/deprecation-of-net-tools/<br />
<br />
== Reverse tethering ==<br />
<br />
It would be nice to add a section about reverse tethering (PC gives internet connection to phone), but I have not come across a uniform way of doing it.<br />
[[User:Commontime|Commontime]] ([[User talk:Commontime|talk]])<br />
<br />
== USB debug mode ==<br />
<br />
USB debugging is not at all necessary for simple tethering via USB. Why was this even added until now?<br />
--[[User:Oliva|Oliva]] ([[User talk:Oliva|talk]]) 14:36, 10 April 2014 (UTC)</div>Olivahttps://wiki.archlinux.org/index.php?title=Migrate_installation_to_new_hardware&diff=240020Migrate installation to new hardware2012-12-12T14:36:26Z<p>Oliva: grammar mistakes</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[Category:System recovery]]<br />
{{Stub}}<br />
This page summarizes some hints and ideas (especially handy commands) useful when moving an Arch Linux system to new hardware. The goal is to achieve the same ArchLinux installation, as far as software and configuration is concerned, but also to clean config files and to update to more recent techniques.<br />
<br />
Basically, there are two ways:<br />
# ''Bottom to Top'': Install a fresh Arch Linux system on the new hardware, and try to install and configure all packages from the old.<br />
# ''Top to Bottom'': Bitwise copy the old partitions to the new system, trying to get the kernel working without forgetting some tweaks.<br />
Which way you choose depends heavily on how the new system differs from your old and how exactly you want to reproduce the system.<br />
{{Warning|Some of the following instructions can be dangerous: you are advised to backup all of your important data on the old system before continuing.}}<br />
<br />
== Bottom to Top ==<br />
=== On the old system ===<br />
==== What software? ====<br />
$ pacman -Qqe | grep -vx "$(pacman -Qqm)" > Packages<br />
$ pacman -Qqm > Packages.aur<br />
gives you a nice list of explicitly installed packages. Don't forget the software ''not'' installed through pacman.<br />
<br />
==== Copy to some backup space. ====<br />
* You can consider backing up /var/cache/pacman/pkg if you do not go from x86 to x86_64<br />
* /etc should be backed up, in order to peek if necessary.<br />
<br />
=== On the new system ===<br />
==== Wiki articles ==== <br />
* Read some Wiki articles concerning new hardware, for examples your new [[SSD]].<br />
* Stick to the well-written installation guidelines here in this wiki. Since you are experienced, the [[Quick_Arch_Linux_Install]] could be enough. <br />
* Try to configure as much as possible sticking to ''current'' wiki articles and forum posts. <br />
<br />
==== Copy from backup space ====<br />
* Copy the pacman cache to var/cache/pacman/pkg<br />
* Don't forget to edit /etc/pacman.d/mirrorlist<br />
<br />
==== Install software ====<br />
As root, grab a cup of coffee and execute:<br />
# xargs -a Packages pacman -S --noconfirm --needed<br />
<br />
== Top to Bottom ==<br />
{{Expansion}}<br />
*See these forum threads:<br />
**https://bbs.archlinux.org/viewtopic.php?id=71038<br />
**https://bbs.archlinux.org/viewtopic.php?pid=543214<br />
<br />
=== Move the system to the new HDDs ===<br />
{{Note|If you are planning to keep the hard drive where the system is already installed, you can skip this section.}}<br />
*connect origin and destination HDDs to the same pc (either the old or the new one) and copy the filesystem(s)<br />
*copy the filesystem(s) using temporary storage devices (external HDDs, DVDs...)<br />
*transfer over network (using a live system on the new pc?)<br />
*consider that you might need adapters (PATA->SATA, USB-HDD-Cases, etc.) and choose a fast connection (or prepare for long copy times)<br />
*command for making an identical copy of the original filesystem: see [[Disk Cloning]]<br />
<br />
==== Update fstab ====<br />
*using /dev paths: this should change depending on how the new drives are connected to the mainboard, on the BIOS and on the new partitions scheme<br />
*using fs labels: should be safe<br />
*using UUIDs<br />
<br />
=== Reconfigure the bootloader ===<br />
*because of:<br />
**new HDD and partitions configuration<br />
**new BIOS configuration<br />
*GRUB allows to edit entries with 'e'<br />
*use a live system?<br />
*update framebuffer mode (if new gpu)<br />
<br />
=== Regenerate kernel image ===<br />
*initially the Fallback image could work<br />
*regenerate image<br />
**mkinitcpio -p linux<br />
<br />
=== Update the graphic drivers ===<br />
*if changed driver (e.g. from ATI to NVIDIA) can uninstall the old drivers<br />
<br />
=== Reconfigure audio ===<br />
*alsamixer volume<br />
**save settings<br />
<br />
=== Reconfigure network ===<br />
*if need to change hostname:<br />
**/etc/rc.conf<br />
**/etc/hosts<br />
**other apps using hostname: synergy, nut (network ups tools)<br />
***"{{Ic|# grep -Ri 'hostname' /etc}}" should give some hints on the files to be updated<br />
<br />
== See also ==<br />
*[[Disk Cloning]]<br />
*[[Migrating Between Architectures Without Reinstalling]]<br />
*[[Moving an existing install into (or out of) a virtual machine]]</div>Olivahttps://wiki.archlinux.org/index.php?title=Systemd&diff=232198Systemd2012-10-28T16:48:41Z<p>Oliva: replaced daemon list with new page</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Systemd/Services}}<br />
{{Article summary wiki|Systemd FAQ}}<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<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|control groups]], 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|sysvinit]].''<br />
<br />
{{Note|1=For a detailed explanation as to why Arch has moved to systemd, see [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 this forum post].}}<br />
<br />
See also the [[Wikipedia:Systemd|Wikipedia article]].<br />
<br />
== Things to consider before you switch ==<br />
<br />
* It is highly recommended to switch to the new '''initscripts''' configuration system described in the [[rc.conf|rc.conf article]]. Once you have this configuration established, you will have done most of the work needed to make the switch to systemd.<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about systemd.<br />
* Note the fact that systemd has a '''journal''' system that replaces '''syslog''', although the two can co-exist. See the [[#Journald_in_conjunction_with_a_classic_syslog_daemon|section on the journal]] below.<br />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<br />
Systemd can be installed side-by-side with the regular Arch Linux {{Pkg|initscripts}} package, and they can be toggled by adding/removing the {{ic|1=init=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== Mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and SysVinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration format (there should be warnings at boot) to the [[#Native configuration|native systemd configuration files]], and reboot to verify that initscipts work as expected.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively (see [[#Initscripts emulation]] below). If the legacy support for {{ic|DAEMONS}} in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
{{Warning|In case you have daemons in the {{ic|DAEMONS}} array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
{{Warning|Systemd is an asynchronous starting process, compared to the sequential {{ic|DAEMONS}} startup. In particular, {{ic|network}} being a legacy service, may start too late to enable interfaces which are required by other services. You are advised to move to [[netcfg]] or [[NetworkManager]] before embarking to systemd. }}<br />
<br />
=== Mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents (see [[#Initscripts emulation]] below).<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation.<br />
# [[#Using Units|Enable daemons]] formerly listed in {{ic|/etc/rc.conf}} with {{ic|systemctl enable ''daemonname''}}. For a translation of the daemons from {{ic|/etc/rc.conf}} to systemd services, see: [[Daemon/List|List of Daemons]] and [[Systemd/Services|Services]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so that systemd starts the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry from the kernel parameters in your bootloader as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== Pure systemd installation ===<br />
<br />
Finally, it is possible to remove initscripts and sysvinit entirely and use only systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation.<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove {{pkg|initscripts}} from your system.<br />
<br />
=== Supplementary information ===<br />
<br />
Adding your user to [[Users and Groups|groups]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) is '''not''' necessary for most use cases with systemd. The groups can even cause some functionality to break. For example, the audio group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via udisks. See [[xinitrc#Preserving the session]] for details on avoiding breaking sessions with {{ic|xorg-xinit}} ([https://bugs.archlinux.org/task/32206 FS#32206]). Also see [[Systemd#Replacing ConsoleKit with systemd-logind]].<br />
<br />
{{Note|ConsoleKit implemented the same ACL-based device permissions and polkit permissions for local sessions before.}}<br />
<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
<br />
== Native configuration ==<br />
<br />
{{Note|You may need to create these files. All files should have '''644''' permissions and '''root:root''' ownership.}}<br />
<br />
=== Hostname ===<br />
<br />
The hostname is configured in {{ic|/etc/hostname}}. To set the hostname, do:<br />
<br />
# hostnamectl set-hostname '''myhostname'''<br />
<br />
See {{ic|man 5 hostname}} and {{ic|man 1 hostnamectl}} for details.<br />
<br />
=== Locale ===<br />
<br />
The default system locale is configured in {{ic|/etc/locale.conf}}. To set the default locale, do:<br />
<br />
# localectl set-locale LANG="de_DE.utf8"<br />
<br />
{{Note|Before you set the default locale, you first need to enable locales available to the system by uncommenting them in {{ic|/etc/locale.gen}} and then executing {{ic|locale-gen}} as root. The locale set via {{ic|localectl}} must be one of the '''uncommented''' locales in {{ic|/etc/locale.gen}}.}}<br />
<br />
See {{ic|man 1 localectl}} and {{ic|man 5 locale.conf}} for details.<br />
<br />
* For more information, see [[Locale]].<br />
<br />
=== Virtual console ===<br />
<br />
The virtual console (keyboard mapping, console font and console map) is configured in {{ic|/etc/vconsole.conf}}:<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<br />
<br />
{{Note|As of {{pkg|systemd-194}}, the built-in ''kernel'' font and the ''us'' keymap are used if {{ic|1=KEYMAP=}} and {{ic|1=FONT=}} are empty or not set.}}<br />
<br />
Another way to set the keyboard mapping (keymap) is doing:<br />
<br />
# localectl set-keymap de<br />
<br />
This has the advantage that it will also set the same keymap for use in X11.<br />
<br />
See {{ic|man 1 localectl}} and {{ic|man 5 vconsole.conf}} for details.<br />
<br />
* For more information, see [[Fonts#Console fonts|console fonts]] and [[KEYMAP|keymaps]].<br />
<br />
=== Time zone ===<br />
<br />
The time zone is configured by creating an appropriate /etc/localtime symlink, pointing to a zoneinfo file under {{ic|/usr/share/zoneinfo/}}. To do this automatically:<br />
<br />
# timedatectl set-timezone America/Toronto<br />
<br />
See {{ic|man 1 timedatectl}} and {{ic|man 5 localtime}} for more details.<br />
<br />
=== Hardware clock ===<br />
<br />
Systemd will use '''UTC''' for the hardware clock by default.<br />
<br />
{{Tip|It is advised to have a [[NTP|Network Time Protocol daemon]] running to keep the system time synchronized with Internet time and the hardware clock.}}<br />
<br />
==== Hardware clock in localtime ====<br />
<br />
If you want to change the hardware clock to use local time ('''STRONGLY DISCOURAGED''') do:<br />
<br />
# timedatectl set-local-rtc true<br />
<br />
If you want to revert to the hardware clock being in UTC, do:<br />
<br />
# timedatectl set-local-rtc false<br />
<br />
Be warned that, if the hardware clock is set to localtime, 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]). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
One reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). However, Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC_in_Windows|registry fix]]. There, it is recommended that Windows are changed to use UTC, rather than Linux to use localtime.<br />
<br />
* For more information, see [[Time]].<br />
<br />
=== Kernel modules ===<br />
<br />
Today, all necessary module loading is handled automatically by [[udev]], so that, if you don't want/need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any config file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.<br />
<br />
==== Extra modules to load at boot ====<br />
<br />
Extra kernel modules to be loaded during boot are configured as a static list in files under {{ic|/etc/modules-load.d/}}. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. Configuration files simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See {{ic|man 5 modules-load.d}} for more details.<br />
<br />
==== Blacklisting ====<br />
<br />
Module blacklisting works the same way as with {{Pkg|initscripts}} since it is actually handled by {{Pkg|kmod}}. See [[Kernel modules#Blacklisting|Module Blacklisting]] for details.<br />
<br />
=== Filesystem mounts ===<br />
<br />
The default setup will automatically fsck and mount filesystems before starting services that need them to be mounted. For example, systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore, local and remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
See {{ic|man 5 systemd.mount}} for details.<br />
<br />
==== Automount ====<br />
<br />
* 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 />
noauto,x-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 />
* The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the {{ic|noauto,x-systemd.automount}} parameters. In addition, you can use the {{ic|1=x-systemd.device-timeout=#}} option to specify a timeout in case the network resource is not available.<br />
<br />
* If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. Systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
==== LVM ====<br />
<br />
If you have LVM volumes not activated during initramfs run, enable {{ic|lvm.service}} (provided by the {{pkg|lvm2}} package):<br />
<br />
# systemctl enable lvm<br />
<br />
Similarly, if you have LVM on encrypted devices mounted later during boot (eg. from {{ic|/etc/crypttab}}), enable {{ic|lvm-on-crypt.service}} (also provided by the {{pkg|lvm2}} package):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== Power management ===<br />
<br />
Systemd handles some power-related ACPI events. They can be configured via the following options from {{ic|/etc/systemd/logind.conf}}:<br />
<br />
* {{ic|HandlePowerKey}}: specifies which action is invoked when the power key is pressed.<br />
* {{ic|HandleSuspendKey}}: specifies which action is invoked when the suspend key is pressed.<br />
* {{ic|HandleHibernateKey}}: specifies which action is invoked when the hibernate key is pressed.<br />
* {{ic|HandleLidSwitch}}: specifies which action is invoked when the lid is closed.<br />
<br />
The specified action can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.<br />
<br />
If these options are not configured, systemd will use its defaults: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
On systems which run no graphical setup or only a simple window manager like [[i3]] or [[awesome]], this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
In the current version of systemd, the {{ic|Handle}} options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Warning|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. New versions are on the way that will include this functionality.}}<br />
<br />
{{Note|Systemd can also use other suspend backends (such as [[Uswsusp]] or [[TuxOnIce]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate.}}<br />
<br />
==== Sleep hooks ====<br />
<br />
Systemd does not use [[pm-utils]] to put the machine to sleep when using {{ic|systemctl suspend}} or {{ic|systemctl hibernate}}, therefore [[pm-utils]] hooks including any [[Pm-utils#Creating_your_own_hooks|custom hooks]] created will not be run. However, systemd provides a similar mechanism to run custom scripts on these events. Systemd runs all executables in {{ic|/usr/lib/systemd/system-sleep/}} and passes two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: either {{ic|suspend}} or {{ic|hibernate}}, depending on what has been invoked<br />
<br />
In contrast to [[pm-utils]], systemd will run these scripts concurrently and not one after another.<br />
<br />
The output of your script will be logged by {{ic|systemd-suspend.service}} or {{ic|systemd-hibernate.service}} so you can see its output in the [[Systemd#Systemd Journal|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Note that you can also use {{ic|sleep.target}}, {{ic|suspend.target}} or {{ic|hibernate.target}} to hook units into the sleep state logic instead of using scripts.<br />
<br />
Example:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac}}<br />
<br />
See {{ic|man 7 systemd.special}} and {{ic|man 8 systemd-sleep}} for details.<br />
<br />
=== Temporary files ===<br />
<br />
Systemd-tmpfiles uses configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{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}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/var/run/samba}} to exist and to have the correct permissions. The corresponding tmpfile looks like this:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
However, tmpfiles may also be used to write values into certain files on boot. For example, if you use {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
The tmpfiles method is recommended in this case since systemd doesn't actually support {{ic|/etc/rc.local}}.<br />
<br />
See {{ic|man 5 tmpfiles.d}} for details.<br />
<br />
=== Units ===<br />
<br />
A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd. The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.<br />
<br />
See {{ic|man 5 systemd.unit}} for details.<br />
<br />
== Transitioning from initscripts to systemd ==<br />
<br />
=== Initscripts emulation ===<br />
<br />
Integration with Arch's classic configuration is provided by the {{Pkg|initscripts}} package. When {{Pkg|initscripts}} are installed in parallel with systemd, with the system running on systemd, systemd will do the following:<br />
<br />
# Parse the {{ic|DAEMONS}} array of /etc/rc.conf and start all listed daemons at boot<br />
# Execute /etc/rc.local during boot<br />
# Execute /etc/rc.local.shutdown during shutdown<br />
<br />
Initscripts emulation is simply meant as a transitional measure to ease users' move to systemd, and '''will eventually go away'''. Native systemd does not rely on {{ic|rc.conf}} centralised configuration, so it is recommended to use [[#Native configuration|native systemd configuration files]], which will take precedence over {{ic|/etc/rc.conf}}.<br />
<br />
{{Note|If you disabled {{keypress|Ctrl+Alt+Del}} to reboot in {{ic|/etc/inittab}}, you will have to reconfigure this setting for systemd by running {{ic|systemctl mask ctrl-alt-del.target}} as root.}}<br />
<br />
=== Moving away from the DAEMONS array ===<br />
<br />
For a pure systemd setup, you should remove the {{ic|/etc/rc.conf}} file entirely and enable services only via {{ic|systemctl}}. For each {{ic|<service_name>}} in the {{ic|DAEMONS}} array in {{ic|/etc/rc.conf}}, run:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Tip|For a list of commonly used daemons with their initscripts and systemd equivalents, see [[Daemon#List of Daemons|this table]].}}<br />
<br />
If {{ic|<service_name>.service}} does not exist:<br />
<br />
* Most probably, systemd uses a different name. For example, {{ic|cronie.service}} replaces the {{ic|crond}} init daemon; {{ic|alsa-store.service}} and {{ic|alsa-restore.service}} replace the {{ic|alsa}} init daemon. Another important instance is the {{ic|network}} daemon, which is replaced with another set of service files (see [[Configuring Network]] for more details.)<br />
* Otherwise, a service file may not be available for systemd. In that case, you'll need to keep {{ic|rc.conf}} to start the service during boot up.<br />
<br />
{{Tip|You may look inside a package that contains daemon start scripts for service names. For instance:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Corresponding systemd daemon service<br />
[...]<br />
}}<br />
<br />
* Finally, some services do not need to be explicitly enabled by the user. For instance, {{ic|dbus.service}} will automatically be enabled when {{ic|dbus-core}} is installed. Check the list of available services and their state using the {{ic|systemctl}} command.<br />
<br />
=== Comparison table between legacy and native configuration ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Configuration<br />
! scope="col"| Configuration file(s)<br />
! scope="col"| Legacy [https://projects.archlinux.org/initscripts.git/tree/rc.conf?id=97f0cd6751e8d22c14d7492cdc2186cf41157ba6 rc.conf] section<br />
|-<br />
| align="center"|Hostname<br />
| align="left"|{{ic|/etc/hostname}}<br />
{{ic|/etc/hosts}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|-<br />
| align="center"|Console font and keymap<br />
| align="left"|{{ic|/etc/vconsole.conf}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Locale<br />
| align="left"|{{ic|/etc/locale.conf}}<br />
{{ic|/etc/locale.gen}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Time zone<br />
| align="left"|{{ic|/etc/localtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Hardware clock<br />
| align="left"|{{ic|/etc/adjtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Kernel modules<br />
| align="left"|{{ic|/etc/modules-load.d/}}<br />
| align="center"|{{ic|HARDWARE}}<br />
|}<br />
<br />
== Administrative commands ==<br />
<br />
* {{ic|systemctl}}: used to introspect and control the state of the systemd system and service manager.<br />
* {{ic|systemd-cgls}}: recursively shows the contents of the selected Linux control group hierarchy in a tree<br />
* {{ic|systemadm}}: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd (provided by the {{AUR|systemd-ui-git}} package from the [[AUR]]).<br />
<br />
View the man pages for more details.<br />
<br />
{{Tip|You can use all of the following {{ic|systemctl}} commands with the {{ic|-H <user>@<host>}} switch to control a systemd instance on a remote machine. This will use [[SSH]] to connect to the remote systemd instance.}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ systemctl --failed<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see list installed unit files by:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Using units ===<br />
<br />
Units can be, for example, services ({{ic|.service}}), mount points ({{ic|.mount}}), devices ({{ic|.device}}) or sockets ({{ic|.socket}}).<br />
<br />
When using {{ic|systemctl}}, you generally have to specify the complete name of the unit file, including its suffix, for example {{ic|sshd.socket}}. There are however a few shortforms when specifying the unit in the following {{ic|systemctl}} commands:<br />
<br />
* If you don't specify the suffix, systemctl will assume {{ic|.service}}. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are treated equivalent.<br />
* Mount points will automatically be translated into the appropriate {{ic|.mount}} unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similiar to mount points, devices are automatically translated into the appropriate {{ic|.device}} unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note|If services do not have an {{ic|Install}} section, it usually means they are called automatically by other services. But if you need to install them manually, use the following command, replacing {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ systemctl help <unit><br />
<br />
=== Power management ===<br />
<br />
If you are in a local {{ic|systemd-logind}} or [[ConsoleKit]] user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password (see also [[#Replacing_ConsoleKit_with_systemd-logind|Replacing ConsoleKit with systemd-logind]]).<br />
<br />
Shut down and reboot the system:<br />
<br />
$ systemctl reboot<br />
<br />
Shut down and power-off/shutdown the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Put your system into hibernation:<br />
<br />
$ systemctl hibernate<br />
<br />
== Writing custom .service files ==<br />
<br />
=== Handling dependencies ===<br />
<br />
With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit {{ic|A}} requires the unit {{ic|B}} to be running before {{ic|A}} is started. In that case add {{ic|1=Requires=B}} and {{ic|1=After=B}} to the {{ic|[Unit]}} section of {{ic|A}}. If the dependency is optional, add {{ic|1=Wants=B}} and {{ic|1=After=B}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, {{ic|network.target}} is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since {{ic|network.target}} is started anyway.<br />
<br />
=== Type ===<br />
<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
<br />
* {{ic|1=Type=simple}}: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so systemd can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: This is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=}} as well so that systemd still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: Identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by {{ic|libsystemd-daemon.so}}.<br />
* {{ic|1=Type=dbus}}: The service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
=== Replacing provided unit files ===<br />
<br />
The unit files in {{ic|/etc/systemd/system/}} take precedence over the ones in {{ic|/usr/lib/systemd/system/}}.<br />
To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from {{ic|/usr/lib/}} to {{ic|/etc/}} and make your changes there. Alternatively you can use {{ic|.include}} to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:<br />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Tip|You can use {{ic|systemd-delta}} to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
=== Syntax highlighting for units within Vim ===<br />
<br />
Syntax highlighting for systemd unit files within [[Vim]] can be enabled by installing {{AUR|vim-systemd}} from the [[Arch User Repository|AUR]].<br />
<br />
== Targets ==<br />
<br />
Systemd uses ''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 with the possibility of having multiple ones active at the same time. 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 targets ===<br />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
# systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<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/<your target>}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/<your target>.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
! SysV 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 target ===<br />
<br />
In systemd targets are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default target to boot into ===<br />
<br />
The standard target is {{ic|default.target}}, which is aliased by default to {{ic|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 bootloader:<br />
<br />
{{Tip|The {{ic|.target}} extension can be left out.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change {{ic|default.target}}. This can be done using {{ic|systemctl}}:<br />
<br />
# systemctl enable multi-user.target<br />
<br />
The effect of this command is outputted by {{ic|systemctl}}; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
is in the target's configuration file. Currently, {{ic|multi-user.target}} and {{ic|graphical.target}} both have it.<br />
<br />
== Journal ==<br />
<br />
Since version 38, systemd has its own logging system, the journal. Therefore, running a syslog daemon is no longer required. To read the log, use:<br />
<br />
# journalctl<br />
<br />
By default (when {{ic|Storage&#61;}} is set to {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), the journal writes to {{ic|/var/log/journal/}}. If the directory {{ic|/var/log/journal/}} does not exist (e.g. if you or some program delete it), systemd will '''not''' create it automatically, but instead write its logs to {{ic|/run/systemd/journal}}. This means that logs will be lost on reboot.<br />
<br />
=== Filtering output ===<br />
<br />
{{ic|journalctl}} allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages by a specific executable:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# journalctl -u netcfg<br />
<br />
See {{ic|man journalctl}} and {{ic|systemd.journal-fields}} for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. E.g. with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with a classic syslog daemon ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. 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]). The {{pkg|syslog-ng}} package in the repositories automatically provides the necessary configuration.<br />
<br />
# systemctl enable syslog-ng<br />
<br />
== Running DEs under systemd ==<br />
<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]] and [[LightDM]].<br />
<br />
# systemctl enable kdm<br />
<br />
This should work out of the box. If not, you might have a {{ic|default.target}} set manually or from a older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|<br />
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and systemd will use its stock {{ic|default.target}} (i.e. {{ic|graphical.target}}).<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
=== Replacing ConsoleKit with systemd-logind ===<br />
<br />
{{Note|Starting with {{Pkg|polkit}} 0.107-4 (currently in [testing]), [[ConsoleKit]] can be completely replaced by {{ic|systemd-logind}}, even when using a display manager.}}<br />
<br />
An easy method to be able to remove [[ConsoleKit]] is to [[Automatic_login_to_virtual_console#With_systemd|automatically login to a virtual console]] and [[Start_X_at_Boot|start X from there]]. It is important that, as mentioned in the latter article, the X server is started on the same virtual console that you log in to, otherwise systemd can not keep track of the user session. You can then simply remove {{ic|ck-launch-session}} from your {{ic|~/.xinitrc}}.<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. To see if your user session is properly set up, check if the following command contains {{ic|1=Active=yes}}. All {{Pkg|polkit}} actions like suspending the system or mounting external drives with [[Udisks]] should then work automatically.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Optimization ==<br />
<br />
=== Analyzing the boot process ===<br />
<br />
==== Using systemd-analyze ====<br />
<br />
Systemd provides a tool called {{ic|systemd-analyze}} that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install {{Pkg|python2-dbus}} and {{Pkg|python2-cairo}} to use it.<br />
<br />
To see how much time was spent in kernel-/userspace on boot, simply use:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|To see how much time was spent in the initramfs, add the {{ic|timestamp}} hook to your {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} and as root, rebuild your initramfs with {{ic|mkinitcpio -p linux}} }}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process graphically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Using bootchart ====<br />
<br />
You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2}} package from [[AUR]] comes with an undocumented systemd service. After you've installed bootchart2 do:<br />
<br />
# systemctl enable bootchart<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Enabling readahead ===<br />
<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 />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
=== Forcing early start for services ===<br />
<br />
One central feature of systemd is [[D-Bus]] 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 [[UPower]]) 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 />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
=== Less output during boot ===<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. 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 />
=== Creating shell shortcuts ===<br />
<br />
Systemd daemon management requires a bit more text entry to accomplish tasks such as start, stopped, enabling, checking status, etc. The following functions can be added to one's {{ic|~/.bashrc}} file to help streamline interactions with systemd and to improve the overall experience.<br />
<br />
{{bc|<br />
# simplified systemd command, for instance "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $1<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $1<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $1<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $1<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $1<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $1<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $1<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $1<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $1<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $1<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $1<br />
}<br />
fi<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Shutdown/reboot takes terribly long ===<br />
<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. Systemd waits some time for each service to exit before trying to kill it. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
== See also ==<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official Web Site]<br />
*[http://0pointer.de/public/systemd-man/ Manual Pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations]<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://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 />
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Booting up: Tools and tips for systemd, a Linux init tool. In The H]<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]<br />
*[http://0pointer.de/blog/projects/why.html most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]</div>Olivahttps://wiki.archlinux.org/index.php?title=MPlayer&diff=214933MPlayer2012-07-26T15:10:26Z<p>Oliva: replaced wrong key for subtitle visibility</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[cs:MPlayer]]<br />
[[el:MPlayer]]<br />
[[fr:MPlayer]]<br />
[[it:MPlayer]]<br />
[[ru:MPlayer]]<br />
[[uk:MPlayer]]<br />
[[zh-CN:MPlayer]]<br />
'''MPlayer''' is a popular movie player for GNU/Linux. It has support for pretty much every video and audio format out there and is hence very versatile, even though most people use it for viewing videos.<br />
<br />
==Installation==<br />
The {{Pkg|mplayer}} package is available in [extra]:<br />
# pacman -S mplayer<br />
<br />
Alternatively, the latest development version can be installed from the [[AUR]] ({{AUR|mplayer-svn}}).<br />
<br />
You may also want to try [http://www.mplayer2.org/ mplayer2], a fork of mplayer, also available there ({{AUR|mplayer2-git}}). It has several improvements over the original mplayer, see: [http://www.mplayer2.org/differences/ mplayer2 vs mplayer]<br />
<br />
==Additional installation tips==<br />
<br />
===Frontends/GUIs===<br />
There are several GUIs for MPlayer.<br />
* Qt: {{Pkg|smplayer}} is in the extra repository. The smplayer-themes package provides themes for it.<br />
* Qt: {{AUR|umplayer}} is in the AUR - like smplayer with some neat features like downloading youtube videos from within it.<br />
* GTK+: {{AUR|pymp}} and {{Pkg|gnome-mplayer}} are in the AUR and community repos, respectively.<br />
* gmplayer: this GUI is no longer included in the mplayer package. There is an alternative mplayer package (mplayer-x) in AUR in which the gmplayer GUI is enabled.<br />
<br />
===Browser integration===<br />
<br />
If you want to let MPlayer control video viewing in your favorite web browser, install the following:<br />
<br />
====Firefox====<br />
<br />
# pacman -S gecko-mediaplayer<br />
<br />
{{Note| Depends on gnome-mplayer, which provides a complete frontend to MPlayer.}}<br />
<br />
====Konqueror====<br />
{{AUR|kmplayer}} is in the [[AUR]].<br />
<br />
{{Note| Also provides a complete frontend to MPlayer.}}<br />
<br />
==Usage==<br />
<br />
===Configuration===<br />
System-wide configuration is located in {{ic|/etc/mplayer/mplayer.conf}}, whereas the user-local settings are stored in {{ic|~/.mplayer/config}}. The file {{ic|/etc/mplayer/example.conf}} is a good starting point.<br />
<br />
An example configuration: <br />
<br />
{{hc|/etc/mplayer/example.conf|2=<br />
<br />
# default configuration that applies to every file<br />
[default]<br />
# use X11 for video output<br />
vo=xv<br />
# use also for audio output<br />
ao=alsa<br />
# ao=oss # Use OSS4<br />
# multithreaded decoding of H264/MPEG-1/2 (valid: 1-8)<br />
lavdopts=threads=2<br />
# prefer using six channels audio<br />
channels = 6<br />
# scale the subtitles to the 3% of the screen size<br />
subfont-text-scale = 3<br />
# never use font config<br />
nofontconfig = 1<br />
# add black borders so the movies have the same aspect ratio of the monitor<br />
# for wide screen monitors<br />
vf-add=expand=::::1:16/9:16<br />
# for non wide screen traditional monitors<br />
#vf-add=expand=::::1:4/3:16<br />
<br />
#profile for up-mixing two channels audio to six channels<br />
# use -profile 2chto6ch to activate<br />
[2chto6ch]<br />
af-add=pan=6:1:0:.4:0:.6:2:0:1:0:.4:.6:2<br />
<br />
#profile to down-mixing six channels audio to two channels<br />
# use -profile 6chto2ch to activate<br />
[6chto2ch]<br />
af-add=pan=2:0.7:0:0:0.7:0.5:0:0:0.5:0.6:0.6:0:0<br />
<br />
# Disable screensaver.<br />
heartbeat-cmd="xscreensaver-command -deactivate &" # stop xscreensaver<br />
stop-xscreensaver="yes" # stop gnome-screensaver<br />
}}<br />
<br />
===Keybindings===<br />
<br />
:''This is a list of the most basic MPlayer keys.''<br />
<br />
{|<br />
! width=50 align=left | Key<br />
! align=left | Description<br />
|-<br />
| p<br />
| Toggle pause/play.<br />
|-<br />
| Space<br />
| Toggle pause/play.<br />
|-<br />
|-<br />
| Backspace<br />
| Return to menu when using dvdnav.<br />
|-<br />
| Left<br />
| Seek backward ten seconds.<br />
|-<br />
| Right<br />
| Seek forward ten seconds.<br />
|-<br />
| Down<br />
| Seek backward one minute.<br />
|-<br />
| Up<br />
| Seek forward one minute.<br />
|-<br />
| <<br />
| Go back in the playlist.<br />
|-<br />
| ><br />
| Go forward in the playlist.<br />
|-<br />
| m<br />
| Mute the sound.<br />
|-<br />
| 0<br />
| Volume up.<br />
|-<br />
| 9<br />
| Volume down.<br />
|-<br />
| f<br />
| Toggle fullscreen mode.<br />
|-<br />
| o<br />
| Toggle OSD state.<br />
|-<br />
| v<br />
| Toggle subtitle visibility.<br />
|-<br />
| {{ic|I}}<br />
| Show filename.<br />
|-<br />
| 1, 2<br />
| Adjust contrast.<br />
|-<br />
| 3, 4<br />
| Adjust brightness.<br />
|-<br />
| j<br />
| Cycle through the available subtitles.<br />
|-<br />
| #<br />
| Cycle through the available audio tracks.<br />
|}<br />
<br />
== Tips and Tricks ==<br />
===Automatic Resuming Where You Left Off===<br />
<br />
The [[AUR]] contains an elegant perl wrapper-script which will allow autoresuming from the point at which playback was stopped {{AUR|mplayer-resumer}}.<br />
<br />
Usage is trivial: simply call the wrapper-script in place of mplayer.<br />
Example:<br />
$ mplayer-resumer [options] [path/]filename<br />
<br />
If this script is restarted within $tdiff (default 5 seconds) then it will delete the file used to keep track of the videos resume position.<br />
<br />
'''RATIONALE'''<br />
<br />
Watching 90% of a video and stopping causes you to return to the beginning again the next time you watch it. Remembering where you were in the video and resuming at that position is a much nicer behavior for the user. By default, mplayer spits out timecode information that tells you where you are in the video, to the tenth of a second. MPlayer also supports a seek feature on the command-line. We can make use of these features to write an mplayer wrapper that will remember the last position in a video file and resume to it on playback.<br />
<br />
'''DESIGN LIMITATION'''<br />
<br />
If the video file to be played is on a read-only filesystem, or otherwise lives in a location that cannot be written to, resume will fail. This is because the current implementation uses a file parallel to the video file to store the timecode.<br />
<br />
===Enabling VDPAU (modern nVidia cards only)===<br />
<br />
For a complete list of VDPAU capable hardware, see [[http://en.wikipedia.org/wiki/PureVideo#Table_of_PureVideo_.28HD.29_GPUs this table]]. Ensure the ''nvidia'' driver is installed and consider one of the following two methods to automatically enable vdpau for playback.<br />
<br />
==== 1. Using a conf file ====<br />
Append the following to either the system-wide or user-specific config files<br />
<br />
vo=vdpau,<br />
vc=ffh264vdpau,ffmpeg12vdpau,ffodivxvdpau,ffwmv3vdpau,ffvc1vdpau,<br />
<br />
{{Note|The trailing commas are important! They tell MPlayer to fall back on other drivers and codecs should the specified ones not be found.}}<br />
{{Warning|The ffodivxvdpau is only supported by the most recent series of nVidia hardware. Consider omitting it based on your specific hardware. See [[NVIDIA#Enabling_Pure_Video_HD_.28VDPAU.2FVAAPI.29|the NVIDIA page]] for more information.}}<br />
<br />
==== 2. Using a wrapper script ====<br />
<br />
The [[AUR]] contains a trivial bash script called {{AUR|mplayer-vdpau-auto}} that detects which vc to use and when to use vo=vdpau.<br />
<br />
===Translucent Video with radeon and Composite enabled===<br />
<br />
To get translucent video output in X you have to enable textured video in mplayer:<br />
<br />
$ mplayer -vo xv:adaptor=1 <File><br />
<br />
Or add the following line to {{ic|~/.mplayer/config}}:<br />
<br />
vo=xv:adaptor=1<br />
<br />
You can use xvinfo to check which video modes your graphic card supports.<br />
<br />
=== SMPlayer No Video Issue ===<br />
<br />
SMPlayer may have trouble opening mp4 (and probably flv) videos. If it plays only audio without video here is the fix:<br />
Open your {{Ic|~/.mplayer/config}} file and add<br />
<br />
[extension.mp4]<br />
demuxer=mov<br />
<br />
If problem persists after doing so, it is because of smplayer is keeping settings for that specific file. Deleting file settings of smplayer will fix this.<br />
<br />
$ rm -rf ~/.config/smplayer/file_settings<br />
<br />
=== SMPlayer fails to resume playback after pause ===<br />
<br />
SMPlayer might stop playing a video after pausing it if your audio output driver is set wrong. If PulseAudio is used start mplayer with the "-ao pulse" argument or edit your {{Ic|~/.mplayer/config}} file and add<br />
<br />
ao=pulse<br />
<br />
In SMPlayer you have to change your "Output-driver" under "General" - "Audio" in the options.<br />
<br />
===Transparent SMPlayer in Gnome with Composite enabled===<br />
<br />
Have you noticed the transparent screen of smplayer when you are using compiz and maybe cairo-dock? Well it's ridiculous that when you open your videos using SMplayer you can just hear audio and no video! Here's how you fix this: [copy paste into terminal]<br />
<br />
sudo bash -c "cat > /usr/bin/smplayer.helper" <<EOF<br />
export XLIB_SKIP_ARGB_VISUALS=1<br />
exec smplayer.real "$@"<br />
EOF<br />
sudo chmod 755 /usr/bin/smplayer.helper<br />
sudo mv /usr/bin/smplayer{,.real}<br />
sudo ln -sf smplayer.helper /usr/bin/smplayer<br />
<br />
If you don't use sudo then just use "su" to login as root and do the above!<br />
<br />
===Watching streamed video===<br />
If you want to play a video stream (e.g *.asx link) use:<br />
<br />
$ mplayer -playlist link-to-stream.asx <br />
<br />
To play the stream, as these are playlists of streams and won't be playable by omitting the -playlist option.<br />
<br />
===Play mplayer with dvdnav support===<br />
If you want to use mplayer with dvdnav support to enable the menus of a dvd then use the following syntax:<br />
<br />
$ mplayer -nocache dvdnav://<br />
<br />
===Seek forward/backward in a downloading file===<br />
If you want to be able to seek forward and backward in a video file which is still downloading whilst watching it, add the following to your config file. <br />
<br />
idx=yes<br />
<br />
===Increase the total volume===<br />
If the maximal volume provided by the sound settings is not loud enough, you can increase the volume by mplayer itself. Activate softvol and set a maximal level which has to range between 10 and 10000.<br />
<br />
softvol=1<br />
softvol-max=600<br />
<br />
===Stream mplayer audio to jackd===<br />
<br />
Edit {{ic|~/.mplayer/config}} and add:<br />
<br />
ao=jack<br />
<br />
=== MPlayer fails to open files with spaces ===<br />
<br />
If you try to open a file with spaces (The Movie) and mplayer fails. Saying that it could not open the file (file:///The%20Movie), where all spaces are converted to %20. <br />
<br />
Then edit {{ic|/usr/share/applications/mplayer.desktop}} to change the following line from:<br />
<br />
Exec=mplayer %U<br />
<br />
To:<br />
<br />
Exec=mplayer "%F"<br />
<br />
If you have a frontend/GUI enter GUI name in Exec=gui_name "%F".<br />
<br />
==External links==<br />
* [http://www.mplayerhq.hu/ Official MPlayer website]<br />
* [http://www.keyxl.com/aaa2fa5/302/MPlayer-keyboard-shortcuts.htm List of shortcut keys]</div>Olivahttps://wiki.archlinux.org/index.php?title=Bluez&diff=203427Bluez2012-06-02T07:38:26Z<p>Oliva: Redirected page to Bluetooth</p>
<hr />
<div>#REDIRECT [[Bluetooth]]</div>Oliva