https://wiki.archlinux.org/api.php?action=feedcontributions&user=Anthony25&feedformat=atomArchWiki - User contributions [en]2024-03-29T01:30:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=AMDGPU&diff=536101AMDGPU2018-08-19T11:36:24Z<p>Anthony25: Fixes rendering issues with "Add a workaround for freezes on GPU with large VRAM"</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:AMDGPU]]<br />
[[ru:AMDGPU]]<br />
{{Related articles start}}<br />
{{Related|AMD Catalyst}}<br />
{{Related|ATI}}<br />
{{Related|Xorg}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
'''amdgpu''' is the open source graphics driver for the latest AMD Radeon graphics cards.<br />
<br />
At the moment there is support for [https://www.x.org/wiki/RadeonFeature/ Volcanic Islands (VI) and newer] and experimental support for [https://www.phoronix.com/scan.php?page=news_item&px=AMD-AMDGPU-Released Sea Islands (CI)] and [https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-SI-Experimental-Code Southern Islands (SI)] cards. AMD has absolutely no plans for supporting the pre-GCN GPUs.<br />
<br />
Owners of unsupported AMD/ATI video cards may use the [[ATI|Radeon open source]] or [[AMD Catalyst|AMD's proprietary]] driver instead.<br />
<br />
== Selecting the right driver ==<br />
<br />
Depending on the card you have, find the right driver in [[Xorg#AMD]]. This page has instructions for '''AMDGPU''' and '''AMDGPU PRO'''.<br />
<br />
== Installation ==<br />
<br />
{{Note|If coming from the proprietary Catalyst driver, see [[AMD Catalyst#Uninstallation]] first.}}<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repostory.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), install the {{Pkg|xf86-video-amdgpu}} package.<br />
* For [[Vulkan]] support, install the {{Pkg|vulkan-radeon}} package. Optionally install the {{Pkg|lib32-vulkan-radeon}} package for 32-bit application support.<br />
<br />
Support for [[#Enabling video acceleration|accelerated video decoding]] is provided by {{Pkg|libva-mesa-driver}} and {{Pkg|lib32-libva-mesa-driver}} or {{Pkg|libva-vdpau-driver}} for VA-API and {{Pkg|mesa-vdpau}} and {{Pkg|lib32-mesa-vdpau}} packages for VDPAU.<br />
<br />
=== Enable Southern Islands (SI) and Sea Islands (CIK) support ===<br />
The {{Pkg|linux}} package enables AMDGPU support for cards of the Southern Islands (SI) and Sea Islands (CIK). When building or compiling a [[kernel]], {{ic|1=CONFIG_DRM_AMDGPU_SI=Y}} and/or {{ic|1=CONFIG_DRM_AMDGPU_CIK=Y}} should be be set in the config.<br />
<br />
Even when AMDGPU support for SI/CIK has been enabled by the kernel, the [[radeon]] driver may be used instead of the AMDGPU driver.<br />
<br />
To make sure the {{ic|amdgpu}} is loaded first use the following [[Mkinitcpio#MODULES]] array, e.g. {{ic|1=MODULES=(amdgpu radeon)}}.<br />
<br />
==== Set required module parameters ====<br />
<br />
To enable full support for SI/CIK when using the {{ic|amdgpu}}, set the following [[kernel parameters]] to prevent the {{ic|radeon}} module from being used [http://www.phoronix.com/scan.php?page=article&item=linux-413-gcn101&num=1]:<br />
<br />
{{hc|$ dmesg|2=<br />
[..] amdgpu 0000:01:00.0: CIK support provided by radeon.<br />
[..] amdgpu 0000:01:00.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override.<br />
}}<br />
<br />
The flags depend on the cards GCN version: <br />
* Southern Islands (SI): {{ic|1=radeon.si_support=0 amdgpu.si_support=1}}<br />
* Sea Islands (CIK): {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1}}<br />
<br />
=== AMD DC ===<br />
AMD DC (display code), introduced in {{Pkg|linux}} 4.15-4.17, is a new display stack that brings support for atomic mode-setting and HDMI/DP audio.<br />
For more info about AMDGPU-DC, see [https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-Accepted this article].<br />
<br />
If you are on GCN 1.1 or newer with AMDGPU and want to use DC, set {{ic|1=amdgpu.dc=1}} as [[kernel parameter]].<br />
<br />
=== AMDGPU PRO ===<br />
{{Warning|Arch Linux is officially not supported.}}<br />
{{Note|<br />
*To use the proprietary OpenCL component without AMDGPU PRO, [[install]] {{AUR|opencl-amd}} instead.<br />
*A [[downgrade]] of the {{pkg|linux}} (4.9) and [[Xorg]] (1.18) packages is required to use AMDGPU PRO 17.10.<br />
}}<br />
<br />
AMD provides a proprietary, binary userland driver called ''AMDGPU PRO'', which works on top of the open-source AMDGPU kernel driver. The driver provides OpenGL, [[OpenCL]], [[Vulkan]] and [[VDPAU]] support (although this is also supported by the open-source driver). For some workloads it provides better performance than the open-source driver ([https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-Deus-MD example benchmark]), while for others it is true the contrary ([https://openbenchmarking.org/prospect/1610315-TA-AMDGPUPRO08/998ba9b677230564e0fbca342a8e1b9a7e85b6ab example benchmark]).<br />
<br />
See the [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx release notes] and the [https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/855699-amd-representative-says-their-vulkan-linux-driver-will-be-here-soon/page6 announcement at the Phoronix forum] for more information.<br />
<br />
A patched version of the official AMDGPU PRO driver is available as {{AUR|amdgpu-pro}} in [[AUR]].<br />
<br />
== Loading ==<br />
<br />
The {{ic|amdgpu}} kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure to [[#Enable Southern Islands (SI) and Sea Islands (CIK) support]] when needed.<br />
* Make sure you have the latest {{Pkg|linux-firmware}} package installed. This driver requires the latest firmware for each model to successfully boot.<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since {{ic|amdgpu}} requires [[KMS]].<br />
* Check that you have not disabled {{ic|amdgpu}} by using any [[Kernel_modules#Blacklisting|kernel module blacklisting]].<br />
<br />
=== Enable early KMS ===<br />
<br />
{{Tip|If you have problems with the resolution, [[Kernel mode setting#Forcing modes and EDID]] may help.}}<br />
<br />
[[Kernel mode setting]] (KMS) is supported by the amdgpu driver, is mandatory and enabled by default. <br />
<br />
KMS is typically initialized after the [[Arch boot process#initramfs|initramfs stage]]. It is possible, however, to enable KMS during the initramfs stage. To do this, add the {{ic|amdgpu}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES=(amdgpu radeon)<br />
<br />
Now, regenerate the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
The change takes effect at the next reboot.<br />
<br />
== Xorg configuration ==<br />
<br />
[[Xorg]] will automatically load the driver and it will use your monitor's EDID to set the native resolution. Configuration is only required for tuning the driver.<br />
<br />
If you want manual configuration, create {{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}}, and add the following:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
EndSection<br />
}}<br />
<br />
Using this section, you can enable features and tweak the driver settings.<br />
<br />
== Performance tuning ==<br />
=== Enabling video acceleration ===<br />
<br />
See [[Hardware video acceleration]].<br />
<br />
=== Driver options ===<br />
The following options apply to {{ic|/etc/X11/xorg.conf.d/'''20-amdgpu.conf'''}}.<br />
<br />
Please read {{man|4|amdgpu}} first before setting driver options.<br />
<br />
'''DRI''' sets the maximum level of DRI to enable. Valid values are ''2'' for DRI2 or ''3'' for DRI3. The default is ''3'' for DRI3 if the Xorg version is >= 1.18.3, otherwise DRI2 is used:<br />
<br />
Option "DRI" "3" <br />
<br />
'''TearFree''' controls tearing prevention using the hardware page flipping mechanism. If this option is set, the default value of the property is set to ''auto'', which means that TearFree is on for outputs with rotation or other RandR transforms:<br />
<br />
Option "TearFree" "true"<br />
<br />
== Enable GPU display scaling ==<br />
<br />
{{Move|xrandr|Not specific to AMDGPU.|section=Moving "Enable GPU display scaling" to xrandr}}<br />
<br />
To avoid the usage of the scaler which is built in the display, and use the GPU own scaler instead, when not using the native resolution of the monitor, execute:<br />
$ xrandr --output "<output>" --set "scaling mode" "<scaling mode>"<br />
Possible values for {{ic|"scaling mode"}} are: {{ic|None, Full, Center, Full aspect}}<br />
<br />
* To show the available outputs and settings, execute:<br />
$ xrandr --prop<br />
<br />
* To set {{ic|1=scaling mode = Full aspect}} for just every available output, execute:<br />
$ for output in $(xrandr --prop | grep -E -o -i "^[A-Z\-]+-[0-9]+"); do xrandr --output "$output" --set "scaling mode" "Full aspect"; done<br />
<br />
== Troubleshooting ==<br />
<br />
=== Xorg or applications won't start ===<br />
<br />
* "(EE) AMDGPU(0): [DRI2] DRI2SwapBuffers: drawable has no back or front?" error after opening glxgears, can open Xorg server but OpenGL apps crash.<br />
* "(EE) AMDGPU(0): Given depth (32) is not supported by amdgpu driver" error, Xorg won't start.<br />
<br />
Setting the screen's depth under Xorg to 16 or 32 will cause problems/crash. To avoid that, you should use a standard screen depth of 24 by adding this to your "screen" section:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-screen.conf|<br />
Section "Screen"<br />
Identifier "Screen"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
=== Screen artifacts and frequency problem ===<br />
<br />
If you have screen artifacts when setting your screen frequency up to 120+Hz your "Memory Clock" and "GPU Clock" are certainly too low to handle the screen request.<br />
<br />
A workaround [https://bugs.freedesktop.org/show_bug.cgi?id=96868#c13] is saving {{ic|high}} or {{ic|low}} in {{ic|/sys/class/drm/card0/device/power_dpm_force_performance_level}}.<br />
<br />
There is a GUI solution [https://github.com/marazmista/radeon-profile] where you can manage the "power_dpm" with {{aur|radeon-profile-git}} and {{aur|radeon-profile-daemon-git}}.<br />
<br />
=== Screen flickering ===<br />
<br />
If you experience flickering [https://bugzilla.kernel.org/show_bug.cgi?id=199101] add {{ic|1=amdgpu.dc=0}} to your kernel parameters.<br />
<br />
=== R9 390 series Poor Performance and/or Instability ===<br />
<br />
If you experience issues [https://bugs.freedesktop.org/show_bug.cgi?id=91880] with a AMD R9 390 series graphics card, set {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1}} as [[kernel parameters]] to force DPM support.<br />
<br />
=== Freezes with "[drm] IP block:gmc_v8_0 is hung!" kernel error ===<br />
<br />
If you experience freezes and kernel crashes during a GPU intensive task with the kernel error " [drm] IP block:gmc_v8_0 is hung!" [https://bugs.freedesktop.org/show_bug.cgi?id=102322], a workaround is to set {{ic|1=amggpu.vm_update_mode=3}} as [[kernel parameters]] to force the GPUVM page tables update to be done using the CPU. Downsides are listed here [https://bugs.freedesktop.org/show_bug.cgi?id=102322#c15].</div>Anthony25https://wiki.archlinux.org/index.php?title=AMDGPU&diff=536100AMDGPU2018-08-19T11:32:54Z<p>Anthony25: Add a workaround for freezes on GPU with large VRAM</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:AMDGPU]]<br />
[[ru:AMDGPU]]<br />
{{Related articles start}}<br />
{{Related|AMD Catalyst}}<br />
{{Related|ATI}}<br />
{{Related|Xorg}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
'''amdgpu''' is the open source graphics driver for the latest AMD Radeon graphics cards.<br />
<br />
At the moment there is support for [https://www.x.org/wiki/RadeonFeature/ Volcanic Islands (VI) and newer] and experimental support for [https://www.phoronix.com/scan.php?page=news_item&px=AMD-AMDGPU-Released Sea Islands (CI)] and [https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-SI-Experimental-Code Southern Islands (SI)] cards. AMD has absolutely no plans for supporting the pre-GCN GPUs.<br />
<br />
Owners of unsupported AMD/ATI video cards may use the [[ATI|Radeon open source]] or [[AMD Catalyst|AMD's proprietary]] driver instead.<br />
<br />
== Selecting the right driver ==<br />
<br />
Depending on the card you have, find the right driver in [[Xorg#AMD]]. This page has instructions for '''AMDGPU''' and '''AMDGPU PRO'''.<br />
<br />
== Installation ==<br />
<br />
{{Note|If coming from the proprietary Catalyst driver, see [[AMD Catalyst#Uninstallation]] first.}}<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repostory.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), install the {{Pkg|xf86-video-amdgpu}} package.<br />
* For [[Vulkan]] support, install the {{Pkg|vulkan-radeon}} package. Optionally install the {{Pkg|lib32-vulkan-radeon}} package for 32-bit application support.<br />
<br />
Support for [[#Enabling video acceleration|accelerated video decoding]] is provided by {{Pkg|libva-mesa-driver}} and {{Pkg|lib32-libva-mesa-driver}} or {{Pkg|libva-vdpau-driver}} for VA-API and {{Pkg|mesa-vdpau}} and {{Pkg|lib32-mesa-vdpau}} packages for VDPAU.<br />
<br />
=== Enable Southern Islands (SI) and Sea Islands (CIK) support ===<br />
The {{Pkg|linux}} package enables AMDGPU support for cards of the Southern Islands (SI) and Sea Islands (CIK). When building or compiling a [[kernel]], {{ic|1=CONFIG_DRM_AMDGPU_SI=Y}} and/or {{ic|1=CONFIG_DRM_AMDGPU_CIK=Y}} should be be set in the config.<br />
<br />
Even when AMDGPU support for SI/CIK has been enabled by the kernel, the [[radeon]] driver may be used instead of the AMDGPU driver.<br />
<br />
To make sure the {{ic|amdgpu}} is loaded first use the following [[Mkinitcpio#MODULES]] array, e.g. {{ic|1=MODULES=(amdgpu radeon)}}.<br />
<br />
==== Set required module parameters ====<br />
<br />
To enable full support for SI/CIK when using the {{ic|amdgpu}}, set the following [[kernel parameters]] to prevent the {{ic|radeon}} module from being used [http://www.phoronix.com/scan.php?page=article&item=linux-413-gcn101&num=1]:<br />
<br />
{{hc|$ dmesg|2=<br />
[..] amdgpu 0000:01:00.0: CIK support provided by radeon.<br />
[..] amdgpu 0000:01:00.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override.<br />
}}<br />
<br />
The flags depend on the cards GCN version: <br />
* Southern Islands (SI): {{ic|1=radeon.si_support=0 amdgpu.si_support=1}}<br />
* Sea Islands (CIK): {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1}}<br />
<br />
=== AMD DC ===<br />
AMD DC (display code), introduced in {{Pkg|linux}} 4.15-4.17, is a new display stack that brings support for atomic mode-setting and HDMI/DP audio.<br />
For more info about AMDGPU-DC, see [https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-Accepted this article].<br />
<br />
If you are on GCN 1.1 or newer with AMDGPU and want to use DC, set {{ic|1=amdgpu.dc=1}} as [[kernel parameter]].<br />
<br />
=== AMDGPU PRO ===<br />
{{Warning|Arch Linux is officially not supported.}}<br />
{{Note|<br />
*To use the proprietary OpenCL component without AMDGPU PRO, [[install]] {{AUR|opencl-amd}} instead.<br />
*A [[downgrade]] of the {{pkg|linux}} (4.9) and [[Xorg]] (1.18) packages is required to use AMDGPU PRO 17.10.<br />
}}<br />
<br />
AMD provides a proprietary, binary userland driver called ''AMDGPU PRO'', which works on top of the open-source AMDGPU kernel driver. The driver provides OpenGL, [[OpenCL]], [[Vulkan]] and [[VDPAU]] support (although this is also supported by the open-source driver). For some workloads it provides better performance than the open-source driver ([https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-Deus-MD example benchmark]), while for others it is true the contrary ([https://openbenchmarking.org/prospect/1610315-TA-AMDGPUPRO08/998ba9b677230564e0fbca342a8e1b9a7e85b6ab example benchmark]).<br />
<br />
See the [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx release notes] and the [https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/855699-amd-representative-says-their-vulkan-linux-driver-will-be-here-soon/page6 announcement at the Phoronix forum] for more information.<br />
<br />
A patched version of the official AMDGPU PRO driver is available as {{AUR|amdgpu-pro}} in [[AUR]].<br />
<br />
== Loading ==<br />
<br />
The {{ic|amdgpu}} kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure to [[#Enable Southern Islands (SI) and Sea Islands (CIK) support]] when needed.<br />
* Make sure you have the latest {{Pkg|linux-firmware}} package installed. This driver requires the latest firmware for each model to successfully boot.<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since {{ic|amdgpu}} requires [[KMS]].<br />
* Check that you have not disabled {{ic|amdgpu}} by using any [[Kernel_modules#Blacklisting|kernel module blacklisting]].<br />
<br />
=== Enable early KMS ===<br />
<br />
{{Tip|If you have problems with the resolution, [[Kernel mode setting#Forcing modes and EDID]] may help.}}<br />
<br />
[[Kernel mode setting]] (KMS) is supported by the amdgpu driver, is mandatory and enabled by default. <br />
<br />
KMS is typically initialized after the [[Arch boot process#initramfs|initramfs stage]]. It is possible, however, to enable KMS during the initramfs stage. To do this, add the {{ic|amdgpu}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES=(amdgpu radeon)<br />
<br />
Now, regenerate the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
The change takes effect at the next reboot.<br />
<br />
== Xorg configuration ==<br />
<br />
[[Xorg]] will automatically load the driver and it will use your monitor's EDID to set the native resolution. Configuration is only required for tuning the driver.<br />
<br />
If you want manual configuration, create {{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}}, and add the following:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
EndSection<br />
}}<br />
<br />
Using this section, you can enable features and tweak the driver settings.<br />
<br />
== Performance tuning ==<br />
=== Enabling video acceleration ===<br />
<br />
See [[Hardware video acceleration]].<br />
<br />
=== Driver options ===<br />
The following options apply to {{ic|/etc/X11/xorg.conf.d/'''20-amdgpu.conf'''}}.<br />
<br />
Please read {{man|4|amdgpu}} first before setting driver options.<br />
<br />
'''DRI''' sets the maximum level of DRI to enable. Valid values are ''2'' for DRI2 or ''3'' for DRI3. The default is ''3'' for DRI3 if the Xorg version is >= 1.18.3, otherwise DRI2 is used:<br />
<br />
Option "DRI" "3" <br />
<br />
'''TearFree''' controls tearing prevention using the hardware page flipping mechanism. If this option is set, the default value of the property is set to ''auto'', which means that TearFree is on for outputs with rotation or other RandR transforms:<br />
<br />
Option "TearFree" "true"<br />
<br />
== Enable GPU display scaling ==<br />
<br />
{{Move|xrandr|Not specific to AMDGPU.|section=Moving "Enable GPU display scaling" to xrandr}}<br />
<br />
To avoid the usage of the scaler which is built in the display, and use the GPU own scaler instead, when not using the native resolution of the monitor, execute:<br />
$ xrandr --output "<output>" --set "scaling mode" "<scaling mode>"<br />
Possible values for {{ic|"scaling mode"}} are: {{ic|None, Full, Center, Full aspect}}<br />
<br />
* To show the available outputs and settings, execute:<br />
$ xrandr --prop<br />
<br />
* To set {{ic|1=scaling mode = Full aspect}} for just every available output, execute:<br />
$ for output in $(xrandr --prop | grep -E -o -i "^[A-Z\-]+-[0-9]+"); do xrandr --output "$output" --set "scaling mode" "Full aspect"; done<br />
<br />
== Troubleshooting ==<br />
<br />
=== Xorg or applications won't start ===<br />
<br />
* "(EE) AMDGPU(0): [DRI2] DRI2SwapBuffers: drawable has no back or front?" error after opening glxgears, can open Xorg server but OpenGL apps crash.<br />
* "(EE) AMDGPU(0): Given depth (32) is not supported by amdgpu driver" error, Xorg won't start.<br />
<br />
Setting the screen's depth under Xorg to 16 or 32 will cause problems/crash. To avoid that, you should use a standard screen depth of 24 by adding this to your "screen" section:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-screen.conf|<br />
Section "Screen"<br />
Identifier "Screen"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
=== Screen artifacts and frequency problem ===<br />
<br />
If you have screen artifacts when setting your screen frequency up to 120+Hz your "Memory Clock" and "GPU Clock" are certainly too low to handle the screen request.<br />
<br />
A workaround [https://bugs.freedesktop.org/show_bug.cgi?id=96868#c13] is saving {{ic|high}} or {{ic|low}} in {{ic|/sys/class/drm/card0/device/power_dpm_force_performance_level}}.<br />
<br />
There is a GUI solution [https://github.com/marazmista/radeon-profile] where you can manage the "power_dpm" with {{aur|radeon-profile-git}} and {{aur|radeon-profile-daemon-git}}.<br />
<br />
=== Screen flickering ===<br />
<br />
If you experience flickering [https://bugzilla.kernel.org/show_bug.cgi?id=199101] add {{ic|1=amdgpu.dc=0}} to your kernel parameters.<br />
<br />
=== R9 390 series Poor Performance and/or Instability ===<br />
<br />
If you experience issues [https://bugs.freedesktop.org/show_bug.cgi?id=91880] with a AMD R9 390 series graphics card, set {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1}} as [[kernel parameters]] to force DPM support.<br />
<br />
<br />
=== Freezes with "[drm] IP block:gmc_v8_0 is hung!" kernel error ===<br />
<br />
If you experience freezes and kernel crashes during a GPU intensive task with the kernel error " [drm] IP block:gmc_v8_0 is hung!" [https://bugs.freedesktop.org/show_bug.cgi?id=102322], a workaround is to set {{amggpu.vm_update_mode=3}} as [[kernel parameters]] to force the GPUVM page tables update to be done using the CPU. Downsides are listed here [https://bugs.freedesktop.org/show_bug.cgi?id=102322#c15].</div>Anthony25https://wiki.archlinux.org/index.php?title=Chroot&diff=471745Chroot2017-03-24T13:52:29Z<p>Anthony25: Mount with `-o bind` instead of `--rbind`</p>
<hr />
<div>[[Category:System recovery]]<br />
[[es:Change root]]<br />
[[fa:تغییر ریشه]]<br />
[[fr:Chroot]]<br />
[[ja:Change Root]]<br />
[[ro:Chroot]]<br />
[[ru:Change root]]<br />
[[zh-hans:Change root]]<br />
{{Related articles start}}<br />
{{Related|Install bundled 32-bit system in Arch64}}<br />
{{Related|proot}}<br />
{{Related|Linux Containers}}<br />
{{Related|systemd-nspawn}}<br />
{{Related articles end}}<br />
[[Wikipedia:Chroot|Chroot]] is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. This modified environment is called a ''chroot jail''.<br />
<br />
== Reasoning ==<br />
<br />
Changing root is commonly done for performing system maintenance on systems where booting and/or logging in is no longer possible. Common examples are:<br />
<br />
* Reinstalling the [[bootloader]].<br />
* Rebuilding the [[mkinitcpio|initramfs image]].<br />
* Upgrading or [[downgrading packages]].<br />
* Resetting a [[Password recovery|forgotten password]].<br />
<br />
See also [[Wikipedia:Chroot#Limitations]].<br />
<br />
== Requirements ==<br />
<br />
* Root privilege.<br />
<br />
* Another Linux environment, e.g. a LiveCD or USB flash media, or from another existing Linux distribution.<br />
<br />
* Matching architecture environments; i.e. the chroot from and chroot to. The architecture of the current environment can be discovered with: {{ic|uname -m}} (e.g. i686 or x86_64).<br />
<br />
* Kernel modules loaded that are needed in the chroot environment.<br />
<br />
* Swap enabled if needed: {{bc|# swapon /dev/sd''xY''}}<br />
<br />
* Internet connection established if needed.<br />
<br />
== Usage ==<br />
<br />
{{Note|<br />
*Some [[systemd]] tools such as ''localectl'' and ''timedatectl'' can not be used inside a chroot, as they require an active [[dbus]] connection. [https://github.com/systemd/systemd/issues/798#issuecomment-126568596]<br />
*The file system that will serve as the new root ({{ic|/}}) of your chroot must be accessible (i.e., decrypted, mounted).}}<br />
<br />
There are two main options for using chroot, described below.<br />
<br />
=== Using arch-chroot ===<br />
<br />
The bash script {{ic|arch-chroot}} is part of the {{Pkg|arch-install-scripts}} package. Before it runs {{ic|/usr/bin/chroot}}, the script mounts api filesystems like {{ic|/proc}} and makes {{ic|/etc/resolv.conf}} available from the chroot.<br />
<br />
==== Enter a chroot ====<br />
<br />
Run arch-chroot with the new root directory as first argument:<br />
<br />
# arch-chroot ''/location/of/new/root''<br />
<br />
For example, in the [[installation guide]] this directory would be {{ic|/mnt}}:<br />
<br />
# arch-chroot /mnt<br />
<br />
To exit the chroot simply use:<br />
<br />
# exit<br />
<br />
==== Run a single command and exit ====<br />
<br />
To run a command from the chroot, and exit again append the command to the end of the line:<br />
<br />
# arch-chroot ''/location/of/new/root'' ''mycommand''<br />
<br />
For example, to run {{ic|mkinitcpio -p linux}} for a chroot located at {{ic|/mnt/arch}} do:<br />
<br />
# arch-chroot /mnt/arch mkinitcpio -p linux<br />
<br />
=== Using chroot ===<br />
<br />
{{Warning|When using {{ic|--rbind}}, some subdirectories of {{ic|dev/}} and {{ic|sys/}} will not be unmountable. Attempting to unmount with {{ic|umount -l}} in this situation will break your session, requiring a reboot. If possible, use {{ic|-o bind}} instead.}}<br />
<br />
In the following example ''/location/of/new/root'' is the directory where the new root resides.<br />
<br />
First, mount the temporary api filesystems:<br />
<br />
# cd ''/location/of/new/root''<br />
# mount -t proc proc proc/<br />
# mount -o bind /sys sys/<br />
# mount -o bind /dev dev/<br />
<br />
And optionally:<br />
<br />
# mount -o bind /run run/<br />
<br />
Next, in order to use an internet connection in the chroot environment copy over the DNS details:<br />
<br />
# cp /etc/resolv.conf etc/resolv.conf<br />
<br />
Finally, to change root into ''/location/of/new/root'' using a bash shell:<br />
<br />
# chroot ''/location/of/new/root'' /bin/bash<br />
<br />
{{Note|If you see the error:<br />
* {{ic|chroot: cannot run command '/usr/bin/bash': Exec format error}}, it is likely that the architectures of the host environment and chroot environment do not match.<br />
* {{ic|chroot: '/usr/bin/bash': permission denied}}, remount with the exec permission: {{ic|mount -o remount,exec /mnt/arch}}.<br />
}}<br />
<br />
After chrooting it may be necessary to load the local bash configuration:<br />
<br />
# source /etc/profile<br />
# source ~/.bashrc<br />
<br />
{{Tip|Optionally, create a unique prompt to be able to differentiate your chroot environment:<br />
{{bc|1=# export PS1="(chroot) $PS1"}}<br />
}}<br />
<br />
When finished with the chroot, you can exit it via:<br />
<br />
# exit<br />
<br />
Then unmount the temporary file systems:<br />
<br />
# cd /<br />
# umount --recursive ''/location/of/new/root''<br />
<br />
{{Note|If there is an error mentioning something like: {{ic|umount: /path: device is busy}} this usually means that either: a program (even a shell) was left running in the chroot or that a sub-mount still exists. Quit the program and use {{ic|mount | grep /mnt/arch}} to find and {{ic|umount}} sub-mounts). It may be tricky to {{ic|umount}} some things and one can hopefully have {{ic|umount --force}} work, as a last resort use {{ic|umount --lazy}} which just releases them. In either case to be safe, {{ic|reboot}} as soon as possible if these are unresolved to avoid future, possible conflicts.}}<br />
<br />
== Run graphical applications from chroot ==<br />
<br />
If you have an [[X server]] running on your system, you can start graphical applications from the chroot environment.<br />
<br />
To allow the chroot environment to connect to an X server, open a virtual terminal inside the X server (i.e. inside the desktop of the user that is currently logged in), then run the [[xhost]] command, which gives permission to anyone to connect to the user's X server:<br />
<br />
$ xhost +local:<br />
<br />
Then, to direct the applications to the X server from chroot, set the DISPLAY environment variable inside the chroot to match the DISPLAY variable of the user that owns the X server. So for example, run <br />
<br />
$ echo $DISPLAY<br />
<br />
as the user that owns the X server to see the value of DISPLAY. If the value is ":0" (for example), then in the chroot environment run<br />
<br />
# export DISPLAY=:0<br />
<br />
== Without root privileges ==<br />
<br />
Chroot requires root privileges, which may not be desirable or possible for the user to obtain in certain situations. There are, however, various ways to simulate chroot-like behavior using alternative implementations.<br />
<br />
=== Proot ===<br />
<br />
[[Proot]] may be used to change the apparent root directory and use {{ic|mount --bind}} without root privileges. This is useful for confining applications to a single directory or running programs built for a different CPU architecture, but it has limitations due to the fact that all files are owned by the user on the host system. Proot provides a {{ic|--root-id}} argument that can be used as a workaround for some of these limitations in a similar (albeit more limited) manner to ''fakeroot''.<br />
<br />
=== Fakechroot ===<br />
<br />
{{Pkg|fakechroot}} is a library shim which intercepts the chroot call and fakes the results. It can be used in conjunction with {{Pkg|fakeroot}} to simulate a chroot as a regular user. <br />
<br />
# fakechroot fakeroot chroot ~/my-chroot bash<br />
<br />
== See also ==<br />
<br />
* [https://help.ubuntu.com/community/BasicChroot Basic Chroot]</div>Anthony25https://wiki.archlinux.org/index.php?title=PostgreSQL&diff=457024PostgreSQL2016-11-17T20:11:09Z<p>Anthony25: Warn about options like data_directory, hba_file and ident_file</p>
<hr />
<div>[[Category:Database management systems]]<br />
[[Category:Web server]]<br />
[[it:PostgreSQL]]<br />
[[ja:PostgreSQL]]<br />
[[ru:PostgreSQL]]<br />
[[zh-CN:PostgreSQL]]<br />
{{Related articles start}}<br />
{{Related|PhpPgAdmin}}<br />
{{Related articles end}}<br />
[http://www.postgresql.org/ PostgreSQL] is an open source, community driven, standard compliant object-relational database system.<br />
<br />
This document describes how to set up PostgreSQL. It also describes how to configure PostgreSQL to be accessible from a remote client. Among other applications, PostgreSQL can be substituted for MySQL as part of the [[LAMP]] web stack.<br />
<br />
== Installing PostgreSQL ==<br />
<br />
[[Install]] the {{Pkg|postgresql}} package. Then [[Users_and_groups#Other_examples_of_user_management|set a password]] for the newly created ''postgres'' user.<br />
<br />
Then, switch to the default PostgreSQL user ''postgres'' by executing the following command:<br />
*If you have {{Pkg|sudo}} and your username is in {{ic|sudoers}}:<br />
:{{bc|$ sudo -i -u postgres}}<br />
*Otherwise:<br />
:{{bc|<nowiki><br />
$ su<br />
# su - postgres<br />
</nowiki>}}<br />
<br />
{{Note|Commands that should be run as the postgres user are prefixed by {{ic|[postgres]$}} in this article.}}<br />
<br />
Before PostgreSQL can function correctly, the database cluster must be initialized:<br />
<br />
[postgres]$ initdb --locale $LANG -E UTF8 -D '/var/lib/postgres/data'<br />
<br />
Where:<br />
* the ''--locale'' is the one defined in the file {{ic|/etc/locale.conf}};<br />
* the ''-E'' is the default encoding of the database that will be created in the future;<br />
* and ''-D'' is the default location where the database cluster must be stored.<br />
<br />
A bunch of lines should now appear on the screen with several ending by ''... ok'':<br />
{{bc|<br />
The files belonging to this database system will be owned by user "postgres".<br />
This user must also own the server process.<br />
<br />
The database cluster will be initialized with locale "en_GB.UTF-8".<br />
The default text search configuration will be set to "english".<br />
<br />
Data page checksums are disabled.<br />
<br />
fixing permissions on existing directory /var/lib/postgres/data ... ok<br />
creating subdirectories ... ok<br />
selecting default max_connections ... 100<br />
selecting default shared_buffers ... 128MB<br />
selecting dynamic shared memory implementation ... posix<br />
creating configuration files ... ok<br />
creating template1 database in /var/lib/postgres/data/base/1 ... ok<br />
initializing pg_authid ... ok<br />
[...]}}<br />
<br />
If this is the kind of lines you see, then the process succeeded. In that case return to the regular user using {{ic|exit}}.<br />
<br />
Then as root, [[start]] and enable {{ic|postgresql.service}}.<br />
<br />
{{Tip|If you change the root to something other than {{ic|/var/lib/postgres}}, you will have to edit the service file. If the root is under {{ic|home}}, make sure to set {{ic|ProtectHome}} to false.}}<br />
<br />
{{Warning|If the database resides on a [[Btrfs]] file system, you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the directory before creating any database. If the database resides on a [[ZFS]] file system, you should consult [[ZFS#Database]] before creating any database.}}<br />
<br />
== Create your first database/user ==<br />
<br />
{{Tip|If you create a PostgreSQL user with the same name as your Linux username, it allows you to access the PostgreSQL database shell without having to specify a user to login (which makes it quite convenient).}}<br />
<br />
Become the postgres user. Add a new database user using the [http://www.postgresql.org/docs/current/static/app-createuser.html createuser] command:<br />
<br />
[postgres]$ createuser --interactive<br />
<br />
Create a new database over which the above user has read/write privileges using the [http://www.postgresql.org/docs/current/static/app-createdb.html createdb] command (execute this command from your login shell if the database user has the same name as your Linux user, otherwise add {{ic|-U ''database-username''}} to the following command):<br />
<br />
$ createdb myDatabaseName<br />
<br />
== Familiarize with PostgreSQL ==<br />
<br />
=== Access the database shell ===<br />
<br />
Become the postgres user. Start the primary database shell, [http://www.postgresql.org/docs/current/static/app-psql.html psql], where you can do all your creation of databases/tables, deletion, set permissions, and run raw SQL commands. Use the {{ic|-d}} option to connect to the database you created (without specifying a database, {{ic|psql}} will try to access a database that matches your username).<br />
<br />
[postgres]$ psql -d myDatabaseName<br />
<br />
Some helpful commands:<br />
<br />
Get help:<br />
=> \help<br />
Connect to a particular database:<br />
=> \c <database><br />
List all users and their permission levels:<br />
=> \du<br />
Show summary information about all tables in the current database:<br />
=> \dt<br />
Exit/quit the {{ic|psql}} shell:<br />
=> \q or CTRL+d<br />
<br />
There are of course many more meta-commands, but these should help you get started. To see all meta-commands run: <br />
=> \?<br />
<br />
== Optional configuration ==<br />
<br />
=== Configure PostgreSQL to be accessible from remote hosts ===<br />
<br />
The PostgreSQL database server configuration file is {{ic|postgresql.conf}}. This file is located in the data directory of the server, typically {{ic|/var/lib/postgres/data}}. This folder also houses the other main configuration files, including the {{ic|pg_hba.conf}}.<br />
<br />
{{Note|By default, this folder will not be browsable or searchable by a regular user. This is why {{ic|find}} and {{ic|locate}} are not finding the configuration files.}}<br />
<br />
Edit the file {{ic|/var/lib/postgres/data/postgresql.conf}}. In the connections and authentications section, add the {{ic|listen_addresses}} line to your needs:<br />
<br />
listen_addresses = 'localhost,''my_local_ip_address'''<br />
#You can use '*' to listen on all local addresses<br />
Take a careful look at the other lines.<br />
<br />
Host-based authentication is configured in {{ic|/var/lib/postgres/data/pg_hba.conf}}. This file controls which hosts are allowed to connect. Note that the defaults '''allow any local user to connect as any database user''', including the database superuser. Add a line like the following:<br />
<br />
# IPv4 local connections:<br />
host all all ''my_remote_client_ip_address''/32 md5<br />
<br />
where {{ic|my_remote_client_ip_address}} is the IP address of the client.<br />
<br />
See the documentation for [http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html pg_hba.conf].<br />
<br />
After this you should [[restart]] {{ic|postgresql.service}} for the changes to take effect.<br />
<br />
{{Note|PostgreSQL uses port {{ic|5432}} by default for remote connections. Make sure this port is open and able to receive incoming connections.}}<br />
<br />
For troubleshooting take a look in the server log file:<br />
<br />
$ journalctl -u postgresql<br />
<br />
=== Configure PostgreSQL authenticate against PAM ===<br />
<br />
PostgreSQL offers a number of authentication methods. If you would like to allow users to authenticate with their system password, additional steps are necessary. First you need to enable [[PAM]] for the connection.<br />
<br />
For example, the same configuration as above, but with PAM enabled:<br />
<br />
# IPv4 local connections:<br />
host all all ''my_remote_client_ip_address''/32 pam<br />
<br />
The PostgreSQL server is however running without root privileges and will not be able to access {{ic|/etc/shadow}}. We can work around that by allowing the postgres group to access this file:<br />
<br />
setfacl -m g:postgres:r /etc/shadow<br />
<br />
=== Change default data directory ===<br />
<br />
The default directory where all your newly created databases will be stored is {{ic|/var/lib/postgres/data}}. To change this, follow these steps:<br />
<br />
Create the new directory and make the postgres user its owner:<br />
<br />
# mkdir -p /pathto/pgroot/data<br />
# chown -R postgres:postgres /pathto/pgroot<br />
<br />
Become the postgres user, and initialize the new cluster:<br />
<br />
[postgres]$ initdb -D /pathto/pgroot/data<br />
<br />
Some variables need to be overridden in the configuration, as described in [[Systemd#Editing provided units]]. First, run:<br />
# systemctl edit postgresql.service<br />
<br />
Systemctl will open a drop-in configuration file in your editor. Write the following in that file:<br />
<br />
[Service]<br />
Environment=PGROOT=''/pathto/pgroot/''<br />
PIDFile=''/pathto/pgroot/''data/postmaster.pid<br />
<br />
If you want to use {{ic|/home}} directory for default directory or for tablespaces, add one more line in this file:<br />
<br />
ProtectHome=false<br />
<br />
=== Change default encoding of new databases to UTF-8 ===<br />
<br />
{{Note|If you ran {{ic|initdb}} with {{ic|-E UTF8}} these steps are not required.}}<br />
<br />
When creating a new database (e.g. with {{ic|createdb blog}}) PostgreSQL actually copies a template database. There are two predefined templates: {{ic|template0}} is vanilla, while {{ic|template1}} is meant as an on-site template changeable by the administrator and is used by default. In order to change the encoding of a new database, one of the options is to change on-site {{ic|template1}}. To do this, log into PostgreSQL shell ({{ic|psql}}) and execute the following:<br />
<br />
First, we need to drop {{ic|template1}}. Templates cannot be dropped, so we first modify it so it is an ordinary database:<br />
<br />
UPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';<br />
<br />
Now we can drop it:<br />
<br />
DROP DATABASE template1;<br />
<br />
The next step is to create a new database from {{ic|template0}}, with a new default encoding:<br />
<br />
CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE';<br />
<br />
Now modify {{ic|template1}} so it is actually a template:<br />
<br />
UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1';<br />
<br />
Optionally, if you do not want anyone connecting to this template, set {{ic|datallowconn}} to {{ic|FALSE}}:<br />
<br />
UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template1';<br />
<br />
{{Note|This last step can create problems when upgrading via {{ic|pg_upgrade}}.}}<br />
<br />
Now you can create a new database:<br />
<br />
[postgres]$ createdb blog<br />
<br />
If you log back in to {{ic|psql}} and check the databases, you should see the proper encoding of your new database:<br />
<br />
\l<br />
<br />
returns<br />
List of databases<br />
Name | Owner | Encoding | Collation | Ctype | Access privileges<br />
-----------+----------+-----------+-----------+-------+----------------------<br />
blog | postgres | UTF8 | C | C |<br />
postgres | postgres | SQL_ASCII | C | C |<br />
template0 | postgres | SQL_ASCII | C | C | =c/postgres<br />
: postgres=CTc/postgres<br />
template1 | postgres | UTF8 | C | C |<br />
<br />
== Administration tools ==<br />
<br />
* {{App|[[phpPgAdmin]]|Web-based administration tool for PostgreSQL.|http://phppgadmin.sourceforge.net|{{Pkg|phppgadmin}}}}<br />
* {{App|pgAdmin|GUI-based administration tool for PostgreSQL.|http://www.pgadmin.org/|{{Pkg|pgadmin3}}}}<br />
<br />
== Setup HHVM to work with PostgreSQL ==<br />
{{Out of date|hhvm-pgsql fails to compile against HHVM 3.7.0, but upstream has not resolved the problem yet. See https://github.com/PocketRent/hhvm-pgsql/issues/82|section=Setting up HHVM}}<br />
$ git clone https://github.com/PocketRent/hhvm-pgsql.git<br />
$ cd hhvm-pgsql<br />
If you do not use a nightly build, then run this command (verified on HHVM 3.6.1) to avoid compile errors:<br />
$ git checkout tags/3.6.0<br />
Then build the extension (if you do not need an improved support for Hack language, then remove -DHACK_FRIENDLY=ON):<br />
$ hphpize<br />
$ cmake -DHACK_FRIENDLY=ON .<br />
$ make<br />
Then copy the built extension:<br />
# cp pgsql.so /etc/hhvm/<br />
Add to /etc/hhvm/server.ini:<br />
<pre>extension_dir = /etc/hhvm<br />
hhvm.extensions[pgsql] = pgsql.so</pre><br />
<br />
== Upgrading PostgreSQL ==<br />
<br />
Upgrading minor PostgreSQL versions (i.e. {{ic|9.2, 9.3, 9.4, 9.5, 9.6}}) requires some extra maintenance.<br />
<br />
{{Tip|If you already migrated from 9.2 to 9.3 and you want to migrate from 9.3 to 9.4, change versions before executing commands. If {{ic|/var/lib/postgres/data-9.2}} already exists and you just copy-paste all commands, {{ic|pg_upgrade}} will complain about the wrong version of the database, because your version 9.3 database will be stored in {{ic|/var/lib/postgres/data-9.2/data/}}.}}<br />
<br />
=== Quick guide ===<br />
<br />
If you had custom settings in configuration files like {{ic|pg_hba.conf}} and {{ic|postgresql.conf}}, merge them into the new ones. If you have set options such as {{ic|data_directory}}, {{ic|hba_file}} or {{ic|ident_file}} in your {{ic|postgresql.conf}}, please temporally unset them before the migration.<br />
<br />
{{hc<br />
|upgrade_pg.sh<br />
|<nowiki><br />
## Set the old version that we want to upgrade from.<br />
export FROM_VERSION=9.5<br />
<br />
pacman -S --needed postgresql-old-upgrade<br />
chown postgres:postgres /var/lib/postgres/<br />
su - postgres -c "mv /var/lib/postgres/data /var/lib/postgres/data-${FROM_VERSION}"<br />
su - postgres -c 'mkdir /var/lib/postgres/data'<br />
su - postgres -c "initdb --locale $LANG -E UTF8 -D /var/lib/postgres/data"<br />
su - postgres -c "pg_upgrade -b /opt/pgsql-${FROM_VERSION}/bin/ -B /usr/bin/ -d /var/lib/postgres/data-${FROM_VERSION} -D /var/lib/postgres/data"<br />
</nowiki>}}<br />
<br />
==== Troubleshooting ====<br />
<br />
If the {{ic|pg_upgrade}} step fails with the following messages,<br />
<br />
; cannot write to log file pg_upgrade_internal.log<br />
; Failure, exiting<br />
<br />
: Make sure you are in a directory that the postgres user has enough rights to write the log file to ({{ic|/tmp}} for example), or use {{ic|su - postgres}} instead of {{ic|sudo -u postgres}}.<br />
<br />
: If you are in a directory that postgres user has enough rights to write the log file to however you still get this error then make sure {{ic|/var/lib/postgres}} is owned by postgres<br />
<br />
; LC_COLLATE error that says that old and new values are different<br />
<br />
: Figure out what the old locale was, {{ic|C}} or {{ic|en_US.UTF-8}} for example, and force it when calling {{ic|initdb}}.<br />
: {{bc|<nowiki>sudo -u postgres LC_ALL=C initdb -D /var/lib/postgres/data</nowiki>}}<br />
<br />
; There seems to be a postmaster servicing the old cluster.<br />
; Please shutdown that postmaster and try again.<br />
<br />
: Make sure postgres is not running. If you still get the error, then chances are there is an old PID file you need to clear out.<br />
<br />
: Find the old pid in old pg data,<br />
: {{bc|<nowiki><br />
$ sudo -u postgres ls -l /var/lib/postgres/data-9.X<br />
total 88<br />
-rw------- 1 postgres postgres 4 Mar 25 2012 PG_VERSION<br />
drwx------ 8 postgres postgres 4096 Jul 17 00:36 base<br />
drwx------ 2 postgres postgres 4096 Jul 17 00:38 global<br />
drwx------ 2 postgres postgres 4096 Mar 25 2012 pg_clog<br />
-rw------- 1 postgres postgres 4476 Mar 25 2012 pg_hba.conf<br />
-rw------- 1 postgres postgres 1636 Mar 25 2012 pg_ident.conf<br />
drwx------ 4 postgres postgres 4096 Mar 25 2012 pg_multixact<br />
drwx------ 2 postgres postgres 4096 Jul 17 00:05 pg_notify<br />
drwx------ 2 postgres postgres 4096 Mar 25 2012 pg_serial<br />
drwx------ 2 postgres postgres 4096 Jul 17 00:53 pg_stat_tmp<br />
drwx------ 2 postgres postgres 4096 Mar 25 2012 pg_subtrans<br />
drwx------ 2 postgres postgres 4096 Mar 25 2012 pg_tblspc<br />
drwx------ 2 postgres postgres 4096 Mar 25 2012 pg_twophase<br />
drwx------ 3 postgres postgres 4096 Mar 25 2012 pg_xlog<br />
-rw------- 1 postgres postgres 19169 Mar 25 2012 postgresql.conf<br />
-rw------- 1 postgres postgres 48 Jul 17 00:05 postmaster.opts<br />
-rw------- 1 postgres postgres 80 Jul 17 00:05 postmaster.pid # <-- This is the problem<br />
</nowiki>}}<br />
<br />
: Move the old pid to temporary directory,<br />
<br />
: {{bc|<nowiki><br />
$ sudo -u postgres mv /var/lib/postgres/data-9.X/postmaster.pid /tmp<br />
</nowiki>}}<br />
<br />
; <nowiki>ERROR: could not access file "$libdir/postgis-2.0": No such file or directory</nowiki><br />
<br />
: Retrieve {{ic|postgis-2.0.so}} from {{Pkg|postgis}} for version postgresql 9.X () and copy it to {{ic|/opt/pgsql-9.X/lib}} and make sure the privileges are readable by postgres user.<br />
<br />
; <nowiki>Your installation references loadable libraries that are missing from the new installation.</nowiki><br />
; <nowiki>could not load library "$libdir/postgis-2.2":</nowiki><br />
; <nowiki>ERROR: incompatible library "/usr/lib/postgresql/postgis-2.2.so": version mismatch</nowiki><br />
; <nowiki>DETAIL: Server is version 9.6, library is version 9.5.</nowiki><br />
<br />
: You can manually compile the previous version of PostGIS against the new version of PostgreSQL, use it for the upgrade process, then install the new version back. <br />
<br />
: In this example we upgrade from the old '''PostgreSQL 9.5 + PostGIS 2.2''' to the new '''PostgreSQL 9.6 + PostGIS 2.3''':<br />
<br />
: {{bc|<nowiki><br />
# Uninstall PostGIS 2.3.<br />
sudo pacman -R postgis<br />
<br />
# Download and compile PostGIS 2.2 against PostgreSQL 5.6. The latest sources can be found at http://postgis.net/source/<br />
wget http://download.osgeo.org/postgis/source/postgis-2.2.3.tar.gz<br />
tar -xvf postgis-2.2.3.tar.gz<br />
cd postgis-2.2.3<br />
./configure<br />
make <br />
<br />
# Copy just the files we need to upgrade the database.<br />
sudo cp postgis/postgis-2.2.so /usr/lib/postgresql<br />
sudo cp raster/rt_pg/rtpostgis-2.2.so /usr/lib/postgresql <br />
sudo cp topology/postgis_topology-2.2.so /usr/lib/postgresql<br />
<br />
# Run pg_upgrade as described above. It should now finish successfully.<br />
[...]<br />
<br />
# Remove PostGIS 2.2.<br />
sudo rm /usr/lib/postgresql/postgis-2.2.so<br />
sudo rm /usr/lib/postgresql/rtpostgis-2.2.so<br />
sudo rm /usr/lib/postgresql/postgis_topology-2.2.so<br />
<br />
# Install PostGIS 2.3 back again.<br />
sudo pacman -S postgis<br />
</nowiki>}}<br />
<br />
; Your installation references loadable libraries that are missing from the new installation.<br />
; You can add these libraries to the new installation, or remove the functions using them from the old installation.<br />
; A list of problem libraries is in the file:<br />
; loadable_libraries.txt<br />
<br />
; Could not load library "$libdir/pg_upgrade_support"<br />
; <nowiki>ERROR: could not access file "$libdir/pg_upgrade_support": No such file or directory</nowiki><br />
<br />
: It means you have leftovers from old failed pg_upgrade attempts that you never completed. So you'll need to start postgres with old data and<br />
: in each database execute {{ic|DROP SCHEMA IF EXISTS binary_upgrade CASCADE;}}<br />
<br />
=== Detailed instructions ===<br />
<br />
{{Note|Official PostgreSQL [http://www.postgresql.org/docs/current/static/upgrading.html upgrade documentation] should be followed.}}<br />
<br />
{{Warning|The following instructions could cause data loss. '''Use at your own risk'''.}}<br />
<br />
It is recommended to add the following to your {{ic|/etc/pacman.conf}} file:<br />
<br />
IgnorePkg = postgresql postgresql-libs<br />
<br />
This will ensure you do not accidentally upgrade the database to an incompatible version. When an upgrade is available, pacman will notify you that it is skipping the upgrade because of the entry in {{ic|pacman.conf}}. Minor version upgrades (e.g. 9.0.3 to 9.0.4) are safe to perform. However, if you do an accidental upgrade to a different major version (e.g. 9.0.x to 9.1.x), you might not be able to access any of your data. Always check the PostgreSQL home page (http://www.postgresql.org/) to be sure of what steps are required for each upgrade. For a bit about why this is the case, see the [http://www.postgresql.org/support/versioning versioning policy].<br />
<br />
There are two main ways to upgrade your PostgreSQL database. Read the official documentation for details.<br />
<br />
For those wishing to use {{ic|pg_upgrade}}, a {{Pkg|postgresql-old-upgrade}} package is available in the [[official repositories]] that will always run one major version behind the real PostgreSQL package. This can be installed side-by-side with the new version of PostgreSQL. <br />
<br />
When you are ready, upgrade the following packages: {{Pkg|postgresql}}, {{Pkg|postgresql-libs}}, and {{Pkg|postgresql-old-upgrade}}. Note that the data directory does not change from version to version, so before running {{ic|pg_upgrade}}, it is necessary to rename your existing data directory and migrate into a new directory. The new database must be initialized, as described near the top of this page.<br />
<br />
# systemctl stop postgresql<br />
# su - postgres -c 'mv /var/lib/postgres/data /var/lib/postgres/olddata'<br />
# su - postgres -c 'initdb --locale en_US.UTF-8 -E UTF8 -D /var/lib/postgres/data'<br />
<br />
The upgrade invocation will likely look something like the following. '''Do not run this command blindly without understanding what it does!''' Reference the [http://www.postgresql.org/docs/current/static/pgupgrade.html upstream pg_upgrade documentation] for details.<br />
<br />
# su - postgres -c 'pg_upgrade -d /var/lib/postgres/olddata/ -D /var/lib/postgres/data/ -b /opt/pgsql-9.4/bin/ -B /usr/bin/'<br />
<br />
==== Manual dump and reload ====<br />
<br />
You could also do something like this (after the upgrade and install of {{Pkg|postgresql-old-upgrade}}).<br />
<br />
{{Note|Below are the commands for PostgreSQL 9.4. You can find similar commands in {{ic|/opt/}} for PostgreSQL 9.2.}}<br />
<br />
# systemctl stop postgresql<br />
# /opt/pgsql-9.4/bin/pg_ctl -D /var/lib/postgres/olddata/ start<br />
# /opt/pgsql-9.4/bin/pg_dumpall >> old_backup.sql<br />
# /opt/pgsql-9.4/bin/pg_ctl -D /var/lib/postgres/olddata/ stop<br />
# systemctl start postgresql<br />
# psql -f old_backup.sql postgres<br />
<br />
== Troubleshooting ==<br />
<br />
=== Improve performance of small transactions ===<br />
<br />
If you are using PostgresSQL on a local machine for development and it seems slow, you could try turning [http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT synchronous_commit off] in the configuration. Beware of the [http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT caveats], however.<br />
<br />
{{hc|/var/lib/postgres/data/postgresql.conf|<nowiki>synchronous_commit = off</nowiki>}}<br />
<br />
=== Prevent disk writes when idle ===<br />
<br />
PostgreSQL periodically updates its internal "statistics" file. By default, this file is stored on disk, which prevents disks from spinning down on laptops and causes hard drive seek noise. It is simple and safe to relocate this file to a memory-only file system with the following configuration option:<br />
<br />
{{hc|/var/lib/postgres/data/postgresql.conf|<nowiki>stats_temp_directory = '/run/postgresql'</nowiki>}}<br />
<br />
=== Cannot connect to database through pg_connect() ===<br />
<br />
Install {{Pkg|php-pgsql}} and edit the {{ic|php.ini}} file uncommenting the lines {{ic|extension<nowiki>=</nowiki>pdo_pgsql.so}} and {{ic|extension<nowiki>=</nowiki>pgsql.so}}, then restart {{ic|httpd}}.</div>Anthony25https://wiki.archlinux.org/index.php?title=Ipset&diff=407547Ipset2015-10-30T21:27:38Z<p>Anthony25: /* Blocking With PeerGuardian and Other Blocklists */</p>
<hr />
<div>[[Category:Firewalls]]<br />
{{Related articles start}}<br />
{{Related|Firewalls}}<br />
{{Related|Iptables}}<br />
{{Related articles end}}<br />
{{Stub|}}<br />
[http://ipset.netfilter.org/ ipset] is a companion application for the [[iptables]] Linux [[firewall]]. It allows you to setup rules to quickly and easily block a set of IP addresses, among other things.<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{pkg|ipset}} from the [[official repositories]].<br />
<br />
== Configuration ==<br />
<br />
=== Blocking a list of addresses ===<br />
<br />
Start by creating a new "set" of network addresses. This creates a new "hash" set of "net" network addresses named "myset".<br />
<br />
# ipset create myset hash:net<br />
<br />
Add any IP address that you'd like to block to the set.<br />
<br />
# ipset add myset 14.144.0.0/12<br />
# ipset add myset 27.8.0.0/13<br />
# ipset add myset 58.16.0.0/15<br />
<br />
Finally, configure [[iptables]] to block any address in that set. This command will add a rule to the top of the "INPUT" chain to "-m" match the set named "myset" from ipset (--match-set) when it's a "src" packet and "DROP", or block, it.<br />
<br />
# iptables -I INPUT -m set --match-set myset src -j DROP<br />
<br />
=== Making ipset persistent ===<br />
<br />
ipset you have created is stored in memory and will be gone after reboot. To make the ipset persistent you have to do the followings:<br />
<br />
First save the ipset to /etc/ipset.conf:<br />
<br />
# ipset save > /etc/ipset.conf<br />
<br />
Then [[enable]] {{ic|ipset.service}}, which works similarly to {{ic|iptables.service}} for restoring [[Iptables#Configuration_and_usage|iptables rules]].<br />
<br />
=== Blocking With PeerGuardian and Other Blocklists ===<br />
<br />
The pg2ipset tool by the author of maeyanie.com, coupled with the ipset-update.sh script can be used with cron to automatically update various blocklists. Currently, by default country blocking, tor exit node blocking, and pg2 list blocking from Bluetack are implemented. The pg2ipset binary can be found on [https://aur.archlinux.org/packages/pg2ipset-git/ AUR], and the script ipset-update.sh on github: https://github.com/ilikenwf/pg2ipset.<br />
<br />
== Other Commands ==<br />
<br />
To view the sets:<br />
<br />
# ipset list<br />
<br />
To delete a set named "myset":<br />
<br />
# ipset destroy myset<br />
<br />
To delete all sets:<br />
<br />
# ipset destroy<br />
<br />
Please see the man page for ipset for further information.</div>Anthony25https://wiki.archlinux.org/index.php?title=Talk:Rutorrent_with_lighttpd&diff=389614Talk:Rutorrent with lighttpd2015-08-01T20:30:09Z<p>Anthony25: Merge with the global rutorrent wiki</p>
<hr />
<div>Hello,<br />
Does this wiki should not be merged with the global RUTorrent one ?</div>Anthony25https://wiki.archlinux.org/index.php?title=User_talk:Anthony25&diff=389613User talk:Anthony252015-08-01T20:28:36Z<p>Anthony25: Blanked the page</p>
<hr />
<div></div>Anthony25https://wiki.archlinux.org/index.php?title=User_talk:Anthony25&diff=389612User talk:Anthony252015-08-01T20:27:54Z<p>Anthony25: Merge with the global rutorrent wiki</p>
<hr />
<div>Hello,<br />
Does this wiki should not be merged with the global RUTorrent one ?</div>Anthony25https://wiki.archlinux.org/index.php?title=NFS/Troubleshooting&diff=338108NFS/Troubleshooting2014-09-29T19:28:59Z<p>Anthony25: /* Server threads */</p>
<hr />
<div>[[Category:Networking]]<br />
[[ar:NFS]]<br />
[[de:Network File System]]<br />
[[es:NFS]]<br />
[[fr:NFS]]<br />
[[it:NFSv4]]<br />
[[zh-CN:NFS]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related articles end}}<br />
<br />
Dedicated article for common problems and solutions.<br />
<br />
== Server-side issues ==<br />
<br />
=== exportfs: /etc/exports:2: syntax error: bad option list ===<br />
<br />
Delete all space from the option list in {{ic|/etc/exports}}<br />
<br />
=== Group/GID permissions issues ===<br />
<br />
If NFS shares mount fine, and are fully accessible to the owner, but not to group members; check the number of groups that user belongs to. NFS has a limit of 16 on the number of groups a user can belong to. If you have users with more than this, you need to enable the {{ic|--manage-gids}} start-up flag for {{ic|rpc.mountd}} on the NFS server.<br />
<br />
{{hc|/etc/conf.d/nfs-server.conf|2=<br />
# Options for rpc.mountd.<br />
# If you have a port-based firewall, you might want to set up<br />
# a fixed port here using the --port option.<br />
# See rpc.mountd(8) for more details.<br />
<br />
MOUNTD_OPTS="--manage-gids"<br />
}}<br />
<br />
=== "Permission denied" when trying to write files ===<br />
<br />
* If you need to mount shares as root, and have full r/w access from the client, add the no_root_squash option to the export in {{ic|/etc/exports}}:<br />
/var/cache/pacman/pkg 192.168.1.0/24(rw,no_subtree_check,no_root_squash)<br />
<br />
=== "RPC: Program not registered" when showmount -e command issued ===<br />
<br />
Make sure that {{ic|nfsd.service}}, {{ic|rpc-mountd.service}}, {{ic|rpc-idmapd.service}} and {{ic|rpcbind.service}} are running on the server site, see [[systemd]]. If they are not, start and enable them.<br />
<br />
== Client-side issues ==<br />
<br />
=== mount.nfs4: No such device ===<br />
<br />
Check that you have loaded the {{ic|nfs}} module<br />
lsmod | grep nfs<br />
and if previous returns empty or only nfsd-stuff, do<br />
# modprobe nfs<br />
<br />
=== mount.nfs4: access denied by server while mounting ===<br />
<br />
NFS shares have to reside in /srv - check your {{ic|/etc/exports}} file and if necessary create the proper folder structure as described in the [[NFS#File_system]] page.<br />
<br />
Check that the permissions on your client's folder are correct. Try using 755.<br />
<br />
or try "exportfs -rav" reload {{ic|/etc/exports}} file.<br />
<br />
=== Unable to connect from OS X clients ===<br />
<br />
When trying to connect from a OS X client, you will see that everything is ok at logs, but MacOS X refuses to mount your NFS share. You have to add {{ic|insecure}} option to your share and re-run {{ic|exportfs -r}}.<br />
<br />
=== Unreliable connection from OS X clients ===<br />
<br />
OS X's NFS client is optimized for OS X Servers and might present some issues with Linux servers. If you are experiencing slow performance, frequent disconnects and problems with international characters edit the default mount options by adding the line {{ic|<nowiki>nfs.client.mount.options = intr,locallocks,nfc</nowiki>}} to {{ic|/etc/nfs.conf}} on your Mac client. More information about the mount options can be found [https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/mount_nfs.8.html#//apple_ref/doc/man/8/mount_nfs here].<br />
<br />
=== Intermittent client freezes when copying large files ===<br />
<br />
If you copy large files from your client machine to the NFS server, the transfer speed is ''very'' fast, but after some seconds the speed drops and your client machine intermittently locks up completely for some time until the transfer is finished.<br />
<br />
Try adding <tt>sync</tt> as a mount option on the client (e.g. in <tt>/etc/fstab</tt>) to fix this problem.<br />
<br />
=== mount.nfs: Operation not permitted ===<br />
<br />
After updating to ''nfs-utils'' 1.2.1-2 or higher, mounting NFS shares stopped working. Henceforth, ''nfs-utils'' uses NFSv4 per default instead of NFSv3. The problem can be solved by using either mount option {{ic|1='vers=3'}} or {{ic|1='nfsvers=3'}} on the command line: <br />
# mount.nfs ''remote target'' ''directory'' -o ...,vers=3,...<br />
# mount.nfs ''remote target'' ''directory'' -o ...,nfsvers=3,...<br />
or in {{ic|/etc/fstab}}:<br />
''remote target'' ''directory'' nfs ...,vers=3,... 0 0<br />
''remote target'' ''directory'' nfs ...,nfsvers=3,... 0 0<br />
<br />
== Performance issues ==<br />
<br />
This [http://nfs.sourceforge.net/nfs-howto/ar01s05.html NFS Howto page] has some useful information regarding performance. Here are some further tips:<br />
<br />
=== Diagnose the problem ===<br />
<br />
* '''Htop''' should be your first port of call. The most obvious symptom will be a maxed-out CPU.<br />
* Press F2, and under "Display options", enable "Detailed CPU time". Press F1 for an explanation of the colours used in the CPU bars. In particular, is the CPU spending most of its time responding to IRQs, or in Wait-IO (wio)?<br />
<br />
=== Server threads ===<br />
<br />
'''Symptoms:''' Nothing seems to be very heavily loaded, but some operations on the client take a long time to complete for no apparent reason.<br />
<br />
If your workload involves lots of small reads and writes (or if there are a lot of clients), there may not be enough threads running on the server to handle the quantity of queries. To check if this is the case, run the following command on one or more of the clients:<br />
<br />
{{hc|# nfsstat -rc|<br />
Client rpc stats:<br />
calls retrans authrefrsh<br />
113482 0 113484<br />
}}<br />
<br />
If the {{ic|retrans}} column contains a number larger than 0, the server is failing to respond to some NFS requests, and the number of threads should be increased.<br />
<br />
To increase the number of threads on the server, edit the file {{ic|/etc/conf.d/nfs-server.conf}} and set the value in the {{ic|NFSD_OPTS}} variable. <br />
For example, to set the number of threads to 32:<br />
{{hc|/etc/conf.d/nfs-server.conf|<br />
NFSD_OPTS&#61;"32"<br />
}}<br />
<br />
The default number of threads is 8. Try doubling this number until {{ic|retrans}} remains consistently at zero. Don't be afraid of increasing the number quite substantially. 256 threads may be quite reasonable, depending on the workload. You will need to restart the NFS server daemon each time you modify the configuration file. Bear in mind that the client statistics will only be reset to zero when the client is rebooted.<br />
<br />
Use '''htop''' (disable the hiding of kernel threads) to keep an eye on how much work each nfsd thread is doing. If you reach a point where the {{ic|retrans}} values are non-zero, but you can see {{ic|nfsd}} threads on the server doing no work, something different is now causing your bottleneck, and you'll need to re-diagnose this new problem.<br />
<br />
=== Close-to-open/flush-on-close ===<br />
<br />
'''Symptoms:''' Your clients are writing many small files. The server CPU is not maxed out, but there is very high wait-IO, and the server disk seems to be churning more than you might expect.<br />
<br />
In order to ensure data consistency across clients, the NFS protocol requires that the client's cache is flushed (all data is pushed to the server) whenever a file is closed after writing. Because the server is not allowed to buffer disk writes (if it crashes, the client won't realise the data wasn't written properly), the data is written to disk immediately before the client's request is completed. When you're writing lots of small files from the client, this means that the server spends most of its time waiting for small files to be written to its disk, which can cause a significant reduction in throughput.<br />
<br />
See [http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch07_04.htm this excellent article] or the '''nfs''' manpage for more details on the close-to-open policy. There are several approaches to solving this problem:<br />
<br />
==== The nocto mount option ====<br />
<br />
{{Note|The linux kernel does not seem to honour this option properly. Files are still flushed when they're closed.}}<br />
<br />
Does your situation match these conditions?<br />
<br />
* The export you have mounted on the client is only going to be used by the one client.<br />
* It doesn't matter too much if a file written on one client doesn't immediately appear on other clients.<br />
* It doesn't matter if after a client has written a file, and the client thinks the file has been saved, and then the client crashes, the file may be lost.<br />
<br />
If you're happy with the above conditions, you can use the '''nocto''' mount option, which will disable the close-to-open behaviour. See the '''nfs''' manpage for details.<br />
<br />
==== The async export option ====<br />
<br />
Does your situation match these conditions?<br />
<br />
* It's important that when a file is closed after writing on one client, it is:<br />
** Immediately visible on all the other clients.<br />
** Safely stored on the server, even if the client crashes immediately after closing the file.<br />
* It's not important to you that if the server crashes:<br />
** You may loose the files that were most recently written by clients.<br />
** When the server is restarted, the clients will believe their recent files exist, even though they were actually lost.<br />
<br />
In this situation, you can use {{ic|async}} instead of {{ic|sync}} in the server's {{ic|/etc/exports}} file for those specific exports. See the '''exports''' manual page for details. In this case, it does not make sense to use the {{ic|nocto}} mount option on the client.<br />
<br />
=== Buffer cache size and MTU ===<br />
<br />
'''Symptoms:''' High kernel or IRQ CPU usage, a very high packet count through the network card.<br />
<br />
This is a trickier optimisation. Make sure this is definitely the problem before spending too much time on this. The default values are usually fine for most situations.<br />
<br />
See [http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch07_03.htm this excellent article] for information about I/O buffering in NFS. Essentially, data is accumulated into buffers before being sent. The size of the buffer will affect the way data is transmitted over the network. The Maximum Transmission Unit (MTU) of the network equipment will also affect throughput, as the buffers need to be split into MTU-sized chunks before they're sent over the network. If your buffer size is too big, the kernel or hardware may spend too much time splitting it into MTU-sized chunks. If the buffer size is too small, there will be overhead involved in sending a very large number of small packets. You can use the '''rsize''' and '''wsize''' mount options on the client to alter the buffer cache size. To achieve the best throughput, you need to experiment and discover the best values for your setup.<br />
<br />
It is possible to change the MTU of many network cards. If your clients are on a separate subnet (e.g. for a Beowulf cluster), it may be safe to configure all of the network cards to use a high MTU. This should be done in very-high-bandwidth environments.<br />
<br />
See also the '''nfs''' manual page for more about '''rsize''' and '''wsize'''.<br />
<br />
<br />
== Debugging ==<br />
<br />
=== Using rpcdebug ===<br />
<br />
Using {{ic|rpcdebug}} is the easiest way to manipulate the kernel interfaces in place of echoing bitmasks to /proc.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Option !! Description<br />
|-<br />
| -c || Clear the given debug flags<br />
|-<br />
| -s || Set the given debug flags<br />
|-<br />
| -m ''module'' || Specify which module's flags to set or clear.<br />
|-<br />
| -v || Increase the verbosity of rpcdebug's output<br />
|-<br />
| -h || Print a help message and exit. When combined with the -v option, also prints the available debug flags.<br />
|}<br />
<br />
For the '''-m''' option, the available modules are:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Module !! Description<br />
|-<br />
| nfsd || The NFS server<br />
|-<br />
| nfs || The NFS client<br />
|-<br />
| nlm || The Network Lock Manager, in either an NFS client or server<br />
|-<br />
| rpc || The Remote Procedure Call module, in either an NFS client or server<br />
|}<br />
<br />
Examples:<br />
{{bc|<br />
rpcdebug -m rpc -s all # sets all debug flags for RPC<br />
rpcdebug -m rpc -c all # clears all debug flags for RPC<br />
<br />
rpcdebug -m nfsd -s all # sets all debug flags for NFS Server<br />
rpcdebug -m nfsd -c all # clears all debug flags for NFS Server<br />
}}<br />
<br />
Once the flags are set you can tail the journal for the debug output, usually {{ic|journalctl -fl}} or similar.<br />
<br />
=== Kernel Interfaces ===<br />
<br />
A bitmask of the debug flags can be echoed into the interface to enable output to syslog; 0 is the default:<br />
<br />
{{bc|<br />
/proc/sys/sunrpc/nfsd_debug<br />
/proc/sys/sunrpc/nfs_debug<br />
/proc/sys/sunrpc/nlm_debug<br />
/proc/sys/sunrpc/rpc_debug<br />
}}<br />
<br />
Sysctl controls are registered for these interfaces, so they can be used instead of echo:<br />
<br />
{{bc|1=<br />
sysctl -w sunrpc.rpc_debug=1023<br />
sysctl -w sunrpc.rpc_debug=0<br />
<br />
sysctl -w sunrpc.nfsd_debug=1023<br />
sysctl -w sunrpc.nfsd_debug=0<br />
}}<br />
<br />
At runtime the server holds information that can be examined:<br />
<br />
{{bc|<br />
grep . /proc/net/rpc/*/content<br />
cat /proc/fs/nfs/exports<br />
cat /proc/net/rpc/nfsd<br />
ls -l /proc/fs/nfsd<br />
}}<br />
<br />
A rundown of {{ic|/proc/net/rpc/nfsd}} (the userspace tool {{ic|nfsstat}} pretty-prints this info):<br />
<br />
{{bc|1=<br />
* rc (reply cache): <hits> <misses> <nocache><br />
- hits: client it's retransmitting<br />
- misses: a operation that requires caching<br />
- nocache: a operation that no requires caching<br />
<br />
* fh (filehandle): <stale> <total-lookups> <anonlookups> <dir-not-in-cache> <nodir-not-in-cache><br />
- stale: file handle errors<br />
- total-lookups, anonlookups, dir-not-in-cache, nodir-not-in-cache<br />
. always seem to be zeros<br />
<br />
* io (input/output): <bytes-read> <bytes-written><br />
- bytes-read: bytes read directly from disk<br />
- bytes-written: bytes written to disk<br />
<br />
* th (threads): <threads> <fullcnt> <10%-20%> <20%-30%> ... <90%-100%> <100%><br />
- threads: number of nfsd threads<br />
- fullcnt: number of times that the last 10% of threads are busy<br />
- 10%-20%, 20%-30% ... 90%-100%: 10 numbers representing 10-20%, 20-30% to 100%<br />
. Counts the number of times a given interval are busy<br />
<br />
* ra (read-ahead): <cache-size> <10%> <20%> ... <100%> <not-found><br />
- cache-size: always the double of number threads<br />
- 10%, 20% ... 100%: how deep it found what was looking for<br />
- not-found: not found in the read-ahead cache<br />
<br />
* net: <netcnt> <netudpcnt> <nettcpcnt> <nettcpconn><br />
- netcnt: counts every read<br />
- netudpcnt: counts every UDP packet it receives<br />
- nettcpcnt: counts every time it receives data from a TCP connection<br />
- nettcpconn: count every TCP connection it receives<br />
<br />
* rpc: <rpccnt> <rpcbadfmt+rpcbadauth+rpcbadclnt> <rpcbadfmt> <rpcbadauth> <rpcbadclnt><br />
- rpccnt: counts all rpc operations<br />
- rpcbadfmt: counts if while processing a RPC it encounters the following errors:<br />
. err_bad_dir, err_bad_rpc, err_bad_prog, err_bad_vers, err_bad_proc, err_bad<br />
- rpcbadauth: bad authentication<br />
. does not count if you try to mount from a machine that it's not in your exports file<br />
- rpcbadclnt: unused<br />
<br />
* procN (N = vers): <vs_nproc> <null> <getattr> <setattr> <lookup> <access> <readlink> <read> <write> <create> <mkdir> <symlink> <mknod> <remove> <rmdir> <rename> <link> <readdir> <readdirplus> <fsstat> <fsinfo> <pathconf> <commit><br />
- vs_nproc: number of procedures for NFS version<br />
. v2: nfsproc.c, 18<br />
. v3: nfs3proc.c, 22<br />
- v4, nfs4proc.c, 2<br />
- statistics: generated from NFS operations at runtime<br />
<br />
* proc4ops: <ops> <x..y><br />
- ops: the definition of LAST_NFS4_OP, OP_RELEASE_LOCKOWNER = 39, plus 1 (so 40); defined in nfs4.h<br />
- x..y: the array of nfs_opcount up to LAST_NFS4_OP (nfsdstats.nfs4_opcount[i])<br />
}}<br />
<br />
=== NFSD debug flags ===<br />
{{hc|/usr/include/linux/nfsd/debug.h|2=<br />
/*<br />
* knfsd debug flags<br />
*/<br />
#define NFSDDBG_SOCK 0x0001<br />
#define NFSDDBG_FH 0x0002<br />
#define NFSDDBG_EXPORT 0x0004<br />
#define NFSDDBG_SVC 0x0008<br />
#define NFSDDBG_PROC 0x0010<br />
#define NFSDDBG_FILEOP 0x0020<br />
#define NFSDDBG_AUTH 0x0040<br />
#define NFSDDBG_REPCACHE 0x0080<br />
#define NFSDDBG_XDR 0x0100<br />
#define NFSDDBG_LOCKD 0x0200<br />
#define NFSDDBG_ALL 0x7FFF<br />
#define NFSDDBG_NOCHANGE 0xFFFF<br />
}}<br />
<br />
=== NFS debug flags ===<br />
{{hc|/usr/include/linux/nfs_fs.h|2=<br />
/*<br />
* NFS debug flags<br />
*/<br />
#define NFSDBG_VFS 0x0001<br />
#define NFSDBG_DIRCACHE 0x0002<br />
#define NFSDBG_LOOKUPCACHE 0x0004<br />
#define NFSDBG_PAGECACHE 0x0008<br />
#define NFSDBG_PROC 0x0010<br />
#define NFSDBG_XDR 0x0020<br />
#define NFSDBG_FILE 0x0040<br />
#define NFSDBG_ROOT 0x0080<br />
#define NFSDBG_CALLBACK 0x0100<br />
#define NFSDBG_CLIENT 0x0200<br />
#define NFSDBG_MOUNT 0x0400<br />
#define NFSDBG_FSCACHE 0x0800<br />
#define NFSDBG_PNFS 0x1000<br />
#define NFSDBG_PNFS_LD 0x2000<br />
#define NFSDBG_STATE 0x4000<br />
#define NFSDBG_ALL 0xFFFF<br />
}}<br />
<br />
=== NLM debug flags ===<br />
{{hc|/usr/include/linux/lockd/debug.h|2=<br />
/*<br />
* Debug flags<br />
*/<br />
#define NLMDBG_SVC 0x0001<br />
#define NLMDBG_CLIENT 0x0002<br />
#define NLMDBG_CLNTLOCK 0x0004<br />
#define NLMDBG_SVCLOCK 0x0008<br />
#define NLMDBG_MONITOR 0x0010<br />
#define NLMDBG_CLNTSUBS 0x0020<br />
#define NLMDBG_SVCSUBS 0x0040<br />
#define NLMDBG_HOSTCACHE 0x0080<br />
#define NLMDBG_XDR 0x0100<br />
#define NLMDBG_ALL 0x7fff<br />
}}<br />
<br />
=== RPC debug flags ===<br />
{{hc|/usr/include/linux/sunrpc/debug.h|2=<br />
/*<br />
* RPC debug facilities<br />
*/<br />
#define RPCDBG_XPRT 0x0001<br />
#define RPCDBG_CALL 0x0002<br />
#define RPCDBG_DEBUG 0x0004<br />
#define RPCDBG_NFS 0x0008<br />
#define RPCDBG_AUTH 0x0010<br />
#define RPCDBG_BIND 0x0020<br />
#define RPCDBG_SCHED 0x0040<br />
#define RPCDBG_TRANS 0x0080<br />
#define RPCDBG_SVCXPRT 0x0100<br />
#define RPCDBG_SVCDSP 0x0200<br />
#define RPCDBG_MISC 0x0400<br />
#define RPCDBG_CACHE 0x0800<br />
#define RPCDBG_ALL 0x7fff<br />
}}<br />
<br />
=== General Notes ===<br />
* While the number of threads can be increased at runtime via an echo to {{ic|/proc/fs/nfsd/threads}}, the cache size (double the threads, see the '''ra''' line of /proc/net/rpc/nfsd) is not dynamic. The NFS daemon must be restarted with the new thread size during initialization in order for the thread cache to properly adjust.<br />
<br />
=== References ===<br />
* [https://github.com/torvalds/linux/tree/master/include/linux https://github.com/torvalds/linux/tree/master/include/linux]<br />
* [http://linux.die.net/man/8/rpcdebug http://linux.die.net/man/8/rpcdebug]<br />
* [http://utcc.utoronto.ca/~cks/space/blog/linux/NFSClientDebuggingBits http://utcc.utoronto.ca/~cks/space/blog/linux/NFSClientDebuggingBits]<br />
* [http://www.novell.com/support/kb/doc.php?id=7011571 http://www.novell.com/support/kb/doc.php?id=7011571]<br />
* [http://stromberg.dnsalias.org/~strombrg/NFS-troubleshooting-2.html http://stromberg.dnsalias.org/~strombrg/NFS-troubleshooting-2.html]<br />
* [http://www.opensubscriber.com/message/nfs@lists.sourceforge.net/7833588.html http://www.opensubscriber.com/message/nfs@lists.sourceforge.net/7833588.html]<br />
<br />
== Other issues ==<br />
<br />
=== Permissions issues ===<br />
<br />
If you find that you cannot set the permissions on files properly, make sure the user/group you are chowning are on both the client and server.<br />
<br />
If all your files are owned by {{ic|nobody}}, and you are using NFSv4, on both the client and server, you should:<br />
* For systemd, ensure that the {{ic|rpc-idmapd}} service has been started.<br />
* For initscripts, ensure that {{ic|NEED_IDMAPD}} is set to {{ic|YES}} in {{ic|/etc/conf.d/nfs-common.conf}}.<br />
<br />
On some systems detecting the domain from FQDN minus hostname does not seem to work reliably. If files are still showing as {{ic|nobody}} after the above changes, edit /etc/idmapd.conf, ensure that {{ic|Domain}} is set to {{ic|FQDN minus hostname}}. For example:<br />
<br />
{{hc|/etc/idmapd.conf|2=<br />
[General]<br />
<br />
Verbosity = 7<br />
Pipefs-Directory = /var/lib/nfs/rpc_pipefs<br />
Domain = yourdomain.local<br />
<br />
[Mapping]<br />
<br />
Nobody-User = nobody<br />
Nobody-Group = nobody<br />
<br />
[Translation]<br />
<br />
Method = nsswitch<br />
}}<br />
<br />
Please refer to [[Nfs#ID_mapping]] for more information.</div>Anthony25https://wiki.archlinux.org/index.php?title=Fail2ban&diff=294538Fail2ban2014-01-26T15:35:19Z<p>Anthony25: /* Installation */</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[ro:Fail2ban]]<br />
{{Warning|Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}<br />
<br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address. <br />
<br />
== Installation ==<br />
<br />
First, install python2-pyinotify so that Fail2ban can detect modification to the log files :<br />
# pacman -S python2-pyinotify<br />
<br />
Then, install {{Pkg|fail2ban}}:<br />
# pacman -S fail2ban<br />
<br />
If you want Fail2ban to send an email when someone has been banned, you have to configure [[SSMTP]] (for example). You will also have to install {{Pkg|whois}} to get some information about the ''attacker''.<br />
# pacman -S whois<br />
<br />
=== systemd ===<br />
<br />
Use the service unit fail2ban.service, refer to [[systemd]] for instructions.<br />
<br />
{{Note|Fail2ban currently does not support {{ic|journald}} logging. This is because it parses textual files like {{ic|/var/log/auth.log}} and {{ic|journald}} uses its own binary format. You must use {{ic|syslog-ng}} or similar to have textual logging.}}<br />
<br />
== Hardening ==<br />
<br />
Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]<br />
<br />
=== Capabilities ===<br />
<br />
For added security consider limiting fail2ban capabilities by specifying {{ic|CapabilityBoundingSet}} in the [[Systemd#Editing_provided_unit_files|drop-in configuration file]] for the provided {{ic|fail2ban.service}}:<br />
<br />
{{hc|/etc/systemd/system/fail2ban.service.d/capabilities.conf|2=<br />
[Service]<br />
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW<br />
}}<br />
<br />
In the example above, {{ic|CAP_DAC_READ_SEARCH}} will allow fail2ban full read access, and {{ic|CAP_NET_ADMIN}} and {{ic|CAP_NET_RAW}} allow setting of firewall rules with [[iptables]]. Additional capabilities may be required, depending on your fail2ban configuration. See {{ic|man capabilities}} for more info.<br />
<br />
=== Filesystem Access ===<br />
<br />
Also considering limiting file system read and write access, by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', again under the under {{ic|[Service]}} section. For example:<br />
ReadOnlyDirectories=/<br />
ReadWriteDirectories=/var/run/fail2ban /var/spool/postfix/maildrop<br />
In the example above, this limits the file system to read-only, except for {{ic|/var/run/fail2ban}} for pid and socket files, and {{ic|/var/spool/postfix/maildrop}} for [[postfix]] sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. Note that adding {{ic|/var/log}} is necessary if you want fail2ban to log its activity.<br />
<br />
== SSH jail ==<br />
<br />
Edit {{ic|/etc/fail2ban/jail.conf}} and modify the ssh-iptables section to enable it and configure the action.<br />
<br />
If your firewall is iptables:<br />
[ssh-iptables]<br />
enabled = true<br />
filter = sshd<br />
action = iptables[name=SSH, port=ssh, protocol=tcp] <br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log <br />
maxretry = 5<br />
<br />
If your firewall is shorewall:<br />
[ssh-shorewall]<br />
enabled = true<br />
filter = sshd<br />
action = shorewall<br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log <br />
maxretry = 5<br />
<br />
{{Note|You can set {{Ic|BLACKLISTNEWONLY}} to {{Ic|No}} in {{ic|/etc/shorewall/shorewall.conf}} otherwise the rule added to ban an IP address will affect only new connections.}}<br />
<br />
Also do not forget to add/change:<br />
LogLevel VERBOSE<br />
in your {{ic|/etc/ssh/sshd_config}}. Else, password failures are not logged correctly.<br />
<br />
== See also ==<br />
<br />
* [[sshguard]]</div>Anthony25https://wiki.archlinux.org/index.php?title=Fail2ban&diff=294536Fail2ban2014-01-26T14:21:04Z<p>Anthony25: /* Installation */</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[ro:Fail2ban]]<br />
{{Warning|Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}<br />
<br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address. <br />
<br />
== Installation ==<br />
<br />
First, install python-pyinotify so that Fail2ban can detect modification to the log files :<br />
# pacman -S python-pyinotify<br />
<br />
Then, install {{Pkg|fail2ban}}:<br />
# pacman -S fail2ban<br />
<br />
If you want Fail2ban to send an email when someone has been banned, you have to configure [[SSMTP]] (for example). You will also have to install {{Pkg|whois}} to get some information about the ''attacker''.<br />
# pacman -S whois<br />
<br />
=== systemd ===<br />
<br />
Use the service unit fail2ban.service, refer to [[systemd]] for instructions.<br />
<br />
{{Note|Fail2ban currently does not support {{ic|journald}} logging. This is because it parses textual files like {{ic|/var/log/auth.log}} and {{ic|journald}} uses its own binary format. You must use {{ic|syslog-ng}} or similar to have textual logging.}}<br />
<br />
== Hardening ==<br />
<br />
Currently, fail2ban requires to run as root, therefore you may wish to consider some additional hardening on the process with systemd. Ref:[http://0pointer.de/blog/projects/security.html systemd for Administrators, Part XII]<br />
<br />
=== Capabilities ===<br />
<br />
For added security consider limiting fail2ban capabilities by specifying {{ic|CapabilityBoundingSet}} in the [[Systemd#Editing_provided_unit_files|drop-in configuration file]] for the provided {{ic|fail2ban.service}}:<br />
<br />
{{hc|/etc/systemd/system/fail2ban.service.d/capabilities.conf|2=<br />
[Service]<br />
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW<br />
}}<br />
<br />
In the example above, {{ic|CAP_DAC_READ_SEARCH}} will allow fail2ban full read access, and {{ic|CAP_NET_ADMIN}} and {{ic|CAP_NET_RAW}} allow setting of firewall rules with [[iptables]]. Additional capabilities may be required, depending on your fail2ban configuration. See {{ic|man capabilities}} for more info.<br />
<br />
=== Filesystem Access ===<br />
<br />
Also considering limiting file system read and write access, by using ''ReadOnlyDirectories'' and ''ReadWriteDirectories'', again under the under {{ic|[Service]}} section. For example:<br />
ReadOnlyDirectories=/<br />
ReadWriteDirectories=/var/run/fail2ban /var/spool/postfix/maildrop<br />
In the example above, this limits the file system to read-only, except for {{ic|/var/run/fail2ban}} for pid and socket files, and {{ic|/var/spool/postfix/maildrop}} for [[postfix]] sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. Note that adding {{ic|/var/log}} is necessary if you want fail2ban to log its activity.<br />
<br />
== SSH jail ==<br />
<br />
Edit {{ic|/etc/fail2ban/jail.conf}} and modify the ssh-iptables section to enable it and configure the action.<br />
<br />
If your firewall is iptables:<br />
[ssh-iptables]<br />
enabled = true<br />
filter = sshd<br />
action = iptables[name=SSH, port=ssh, protocol=tcp] <br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log <br />
maxretry = 5<br />
<br />
If your firewall is shorewall:<br />
[ssh-shorewall]<br />
enabled = true<br />
filter = sshd<br />
action = shorewall<br />
sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com]<br />
logpath = /var/log/auth.log <br />
maxretry = 5<br />
<br />
{{Note|You can set {{Ic|BLACKLISTNEWONLY}} to {{Ic|No}} in {{ic|/etc/shorewall/shorewall.conf}} otherwise the rule added to ban an IP address will affect only new connections.}}<br />
<br />
Also do not forget to add/change:<br />
LogLevel VERBOSE<br />
in your {{ic|/etc/ssh/sshd_config}}. Else, password failures are not logged correctly.<br />
<br />
== See also ==<br />
<br />
* [[sshguard]]</div>Anthony25