oracular (5) core.5.gz

Provided by: manpages-pl_4.23.1-1_all bug

NAZWA

       core - plik zrzutu pamięci

OPIS

       Dla  pewnych sygnałów domyślną akcją procesu jest zakończenie działania i utworzenie pliku zrzutu pamięci
       (core), czyli pliku zawierającego obraz pamięci procesu w  czasie,  gdy  został  on  zakończony.  Dowolny
       debugger  (np.  gdb(1)) może użyć tego obrazu do zbadania stanu programu w czasie jego zakończenia. Listę
       sygnałów powodujących utworzenie pliku core przez proces można znaleźć w signal(7).

       Proces może ustawić miękki limit zasobów RLIMIT_CORE, aby  ograniczyć  maksymalny  rozmiar  pliku,  który
       zostanie utworzony po otrzymaniu sygnału powodującego zrzut pamięci; szczegółowe informacje można znaleźć
       w getrlimit(2).

       W następujących wypadkach plik zrzutu pamięci nie będzie utworzony:

       •  Proces nie ma uprawnień, aby zapisać plik zrzutu pamięci (Domyślnie  plik  ten  nazywa  się  core  lub
          core.pid,  gdzie  pid  jest  identyfikatorem  procesu  który  zrzuca pamięć i jest tworzony w bieżącym
          katalogu roboczym procesu. Nazwę tę można  zmienić  -  patrz  niżej).  Zapisywanie  pliku  zrzutu  nie
          powiedzie się również wtedy, gdy prawa katalogu, w którym ten plik miałby być utworzony, nie pozwalają
          na zapis do niego lub gdy plik o tej samej nazwie istnieje i nie jest zapisywalny lub nie jest zwykłym
          plikiem (ale np. katalogiem lub dowiązaniem symbolicznym).

       •  Już  istnieje  (zapisywalny,  zwykły)  plik  o tej samej nazwie, jaka zostałaby użyta dla pliku zrzutu
          pamięci, jednakże plik ten ma więcej niż jedno dowiązanie twarde.

       •  System plików, w którym zostałby utworzony plik zrzutu pamięci, jest pełny,  wyczerpał  mu  się  limit
          i-węzłów,  jest  zamontowany  w  trybie  tylko  do  odczytu albo użytkownik osiągnął przydział systemu
          plików.

       •  Nie istnieje katalog, w którym miałby być utworzony plik zrzutu pamięci.

       •  Limity zasobów RLIMIT_CORE (rozmiar pliku zrzutu pamięci) lub RLIMIT_FSIZE (rozmiar pliku) dla procesu
          są  ustawione  na  zero; patrz getrlimit(2) i dokumentacja wbudowanego w powłokę polecenia ulimit (lub
          limit w powłoce csh(1)). RLIMIT_CORE będzie ignorowane, gdy  system  skonfigurowano  do  przekazywania
          zrzutów pamięci za pomocą potoku do programu.

       •  Wykonywany przez proces plik binarny nie ma włączonych uprawnień do odczytu (jest to zabezpieczenie, w
          celu wykluczenia  sytuacji,  gdy  plik  wykonywany,  którego  odczyt  jest  niemożliwy,  tworzyłby   —
          potencjalnie odczytywalny — zrzut pamięci zawierający obraz pliku wykonywalnego).

       •  Proces  uruchomił  program  z  flagą  set-user-ID (set-group-ID), którego właścicielem jest użytkownik
          (grupa) inny niż rzeczywisty użytkownik (grupa) procesu lub proces wykonujący  program  ma  przywileje
          plikowe  (zob.  capabilities(7)).  (Jednakże  patrz  w  prctl(2)  opis operacji PR_SET_DUMPABLE oraz w
          proc(5) opis pliku /proc/sys/fs/suid_dumpable).

       •  /proc/sys/kernel/core_pattern jest pusty i /proc/sys/kernel/core_uses_pid zawiera wartość 0 (pliki  te
          opisano   poniżej).   Proszę   zauważyć,   że   gdy   /proc/sys/kernel/core_pattern   jest   pusty   i
          /proc/sys/kernel/core_uses_pid zawiera wartość 1, to pliki zrzutu pamięci będą miały nazwy  w  postaci
          .pid, a pliki takie są ukryte, chyba że poda się opcję ls(1) -a.

       •  (od Linuksa 3.7) Jądro zostało zbudowane bez opcji CONFIG_COREDUMP.

       Dodatkowo  zrzut  pamięci  może  nie  zawierać  części  przestrzeni  adresowej  procesu jeśli użyto flagi
       MADV_DONTDUMP madvise(2).

       W systemach korzystającym z systemd(1) jako init, pliki zrzutu pamięci mogą być w  zamian  umieszczane  w
       położeniu wskazanym przez systemd(1). Więcej szczegółów poniżej.

   Nazwy plików zrzutu pamięci
       Domyślnie  plik zrzutu pamięci nazywa się core, jednakże w pliku /proc/sys/kernel/core_pattern (od wersji
       2.6 i 2.4.21 Linuksa) można zdefiniować szablon, który będzie użyty do nazywania plików  zrzutu  pamięci.
       Szablon  ten  może  zawierać  specjalne  znaczniki  zaczynające się od „%”, które podczas tworzenia pliku
       zrzutu będą zastąpione następującymi wartościami:

           %%  Pojedynczy znak %.
           %c  Miękki limit zasobu rozmiaru  pliku  zrzutu  pamięci  procesu  zrzucającego  pamięć  (od  Linuksa
               2.6.24).
           %d  Tryb zrzutu — taki sam jak wartość zwracana przez prctl(2) PR_GET_DUMPABLE (od Linuksa 3.7).
           %e  Wartość  comm procesu lub wątku, zwykle równa nazwie pliku wykonywalnego (bez przedrostka ścieżki
               i obcięta do maksymalnie 15 znaków), lecz mogąca być również zmodyfikowana na inną wartość,  zob.
               opis /proc/pid/comm i /proc/pid/task/tid/comm w proc(5).
           %E  Nazwa  ścieżki  pliku  wykonywalnego, z ukośnikami („/”) zastąpionymi przez wykrzykniki („!”) (od
               Linuksa 3.0).
           %g  Numeryczny identyfikator grupy (GID) procesu, który zrzucił pamięć.
           %h  Nazwa komputera (taka sama jak nodename zwracane przez uname(2)).
           %i  identyfikator wątku (TID) który zainicjował zrzut pamięci, taki jak w przestrzeni nazw  PID-ów  w
               której wątek działa (od Linuksa 3.18).
           %I  identyfikator  wątku  (TID)  który  zainicjował zrzut pamięci, taki jak w początkowej przestrzeni
               nazw PID-ów (od Linuksa 3.18).
           %p  identyfikator zrzucanego procesu, taki jak w przestrzeni nazw PID-ów w której proces działa.
           %P  identyfikator zrzucanego procesu, taki jak w początkowej  przestrzeni  nazw  PID-ów  (od  Linuksa
               3.12).
           %s  Numer sygnału powodującego zrzut pamięci.
           %t  Czas zrzutu wyrażony w sekundach od początku epoki, czyli od 1970-01-01 00:00:00 +0000 (UTC).
           %u  Numeryczny identyfikator użytkownika (UID) procesu, który zrzucił pamięć.

       Jeśli  szablon  kończy  się  pojedynczym  znakiem  %, to znak ten zostanie usunięty z nazwy pliku zrzutu.
       Podobnie zostaną usunięte wszelkie kombinacje % ze znakami innymi niż te, wymienione  powyżej.  Wszystkie
       inne  znaki  szablonu  staną  się  częścią  nazwy pliku zrzutu. Szablon może zawierać znaki „/”, które są
       interpretowane jako separatory nazw katalogów. Maksymalna długość wygenerowanej nazwy  pliku  wynosi  128
       bajtów  (64  bajty  w  wersjach  wcześniejszych niż Linux 2.6.19). Domyślną wartością jest „core”. W celu
       zachowania   wstecznej   zgodności,   jeśli   /proc/sys/kernel/core_pattern    nie    zawiera    %p,    a
       /proc/sys/kernel/core_uses_pid  (patrz  niżej)  ma  niezerową  wartość, to .PID będzie dołączony do nazwy
       pliku zrzutu.

       Ścieżki są interpretowane zgodnie z ustawieniami aktywnymi dla  załamującego  się  procesu.  Oznacza  to:
       przestrzeń  nazw  montowania  (zob.  mount_namespaces(7)),  jego  bieżący katalog roboczy (odnaleziony za
       pomocą getcwd(2)) oraz jego katalog główny (zob. chroot(2)).

       Od Linuksa 2.4, Linux dostarcza również bardziej  prymitywną  metodę  kontrolowania  nazwy  pliku  zrzutu
       pamięci.  Gdy  plik  /proc/sys/kernel/core_uses_pid  zawiera  wartość 0, plik zrzutu pamięci ma po prostu
       nazwę core. Gdy plik ten zawiera wartość niezerową, plik zrzutu pamięci będzie zawierał w  swojej  nazwie
       ID procesu, w postaci core.PID.

       Od  Linuksa  3.6  jeśli  /proc/sys/fs/suid_dumpable  ustawiono na 2 („suidsafe”) to wzorzec musi być albo
       ścieżką absolutną (zaczynającą się znakiem „/”) lub potokiem, zgodnie z poniższą definicją.

   Przekazywanie zrzutów pamięci potokiem do programu
       Od wersji Linuksa 2.6.19, Linux  obsługuje  alternatywną  składnię  pliku  /proc/sys/kernel/core_pattern.
       Jeśli  pierwszym  znakiem  pliki  jest  symbol  potoku  (|),  to  wszystko,  co  po  nim  występuje, jest
       interpretowane jako wiersz polecenia dla programu w przestrzeni użytkownika (lub skryptu), który  ma  być
       wykonany.

       Od  Linuksa  5.3.0,  szablon  potoku  jest  dzielony  na  spacjach na listę argumentów przed rozwinięciem
       parametrów szablonu. We wcześniejszych jądrach parametry szablonu były  najpierw  rozwijane,  a  wynikowy
       łańcuch  był  dzielony  na  spacjach na listę argumentów. Oznacza to, że we wcześniejszych jądrach, nazwy
       plików wykonywalnych dodawane za pomocą parametrów szablonu %e i  %E  mogły  ulec  podzieleniu  na  wiele
       argumentów.  Procedura  obsługi  zrzutu  pamięci  musi  zatem  umieszczać nazwy plików wykonywalnych jako
       ostatni argument i upewnić się, że połączy  wszystkie  składowe  nazwy  pliku  wykonywalnego  używającego
       spacji.  Nazwy  plików  wykonywalnych  zawierające  wiele  spacji  nie  były prawidłowo reprezentowane we
       wcześniejszych jądrach, co oznacza, że procedura  obsługi  zrzutu  pamięci  musi  używać  mechanizmów  do
       odnalezienia nazwy pliku wykonywalnego.

       Zamiast  zostać  zapisanym  na  dysku,  zrzut  pamięci jest przekazywany na standardowe wejście programu.
       Proszę zauważyć, że:

       •  Program musi być podany używając ścieżki bezwzględnej (lub ścieżki względnej w  stosunku  do  korzenia
          systemu plików, czyli katalogu /) i musi występować bezpośrednio po znaku „|”.

       •  Argumenty  linii  poleceń  mogą zawierać dowolne z wymienionych powyżej specyfikatorów %. Na przykład,
          aby przekazać identyfikator procesu zrzucającego pamięć, należy podać %p jako argument.

       •  Proces tworzony do wykonania programu jest wykonywany jako użytkownik i grupa root.

       •  Uruchomienie jako root nie pomija w żaden sposób procedur bezpieczeństwa. Przede wszystkim, LSM-y (np.
          SELinux)  są  wciąż  aktywne  i  mogą zapobiec uzyskaniu szczegółów poprzez /proc/pid, przez procedurę
          obsługi, na temat załamanego procesu.

       •  Ścieżka programu jest interpretowana zgodnie z początkową przestrzenią nazw montowań, jako  że  zawsze
          jest  on  tu  wykonywany.  Nie  mają  na  nią  wpływu  ustawienia (np. katalog główny, przestrzeń nazw
          montowań, bieżący katalog roboczy) załamującego się procesu.

       •  Proces działa w swoich pierwotnych przestrzeniach nazw (PID, montowania, użytkownika itd.),  a  nie  w
          przestrzeniach  nazw  załamującego  się  procesu.  Można  użyć znaczników, takich jak %P, aby odnaleźć
          właściwy katalog /proc/pid i sprawdzić/wejść w przestrzenie nazw załamującego się procesu, jeśli  jest
          taka potrzeba.

       •  Proces uruchamia się ze swoim bieżącym katalogiem roboczym jako katalogiem głównym. Jeśli to wskazane,
          można zmienić katalog roboczy zrzucanego procesu za pomocą wartości podanej  przez  znacznik  %P,  aby
          zmienić położenie zrzucanego procesu za pomocą /proc/pid/cwd.

       •  Można  przekazać do programu argumenty linii poleceń (od Linuksa 2.6.24), rozdzielając je spacjami (aż
          do wyczerpania limitu całkowitej długości linii wynoszącego 128 bajtów).

       •  Limit RLIMIT_CORE nie jest pilnowany w przypadku zrzutów pamięci, które są  przekazywane  potokiem  za
          pomocą tego mechanizmu.

   /proc/sys/kernel/core_pipe_limit
       Przy  zbieraniu  zrzutów  pamięci  za pomocą potoku do program w przestrzeni użytkownika, może okazać się
       przydatne zbieranie danych o załamującym się procesie  z  katalogu  /proc/pid  procesu.  Aby  uczynić  to
       bezpiecznie,  jądro  musi  zaczekać  na  wyjście  przez  program zbierający zrzut pamięci, aby nie usuwać
       przedwcześnie plików /proc/pid załamującego się procesu. Z  drugiej  jednak  strony,  daje  to  możliwość
       blokowania   dorzynania   (ang.  reaping)  załamanego  procesu,  przez  niepoprawnie  działający  program
       zbierający, który może nigdy nie wyjść.

       Od Linuksa 2.6.32, można użyć  /proc/sys/kernel/core_pipe_limit  do  obrony  przed  taką  ewentualnością.
       Wartość  pliku  definiuje,  jak wiele współbieżnych załamujących się procesów można przekazać równolegle,
       potokiem, do programów w przestrzeni użytkownika. Po przekroczeniu tej wartości, załamujące się  programy
       niemieszczące się w tej wartości są odnotowywane w dzienniku jądra, a ich zrzuty pamięci są pomijane.

       Wartość  0  w  tym  pliku  ma  specjalne  znaczenie.  Oznacza,  że  równolegle  może  być  przechwytywana
       nieograniczona liczba procesów, ale  nie  zajdzie  żadne  oczekiwanie  (tj.  program  zbierający  nie  ma
       gwarancji dostępu do /proc/<załamujący-się-PID>). Domyślną wartością pliku jest 0.

   Kontrolowanie mapowań zapisywanych do pliku zrzutu pamięci
       Od Linuksa 2.6.23, można użyć specyficznego dla Linuksa pliku /proc/PID/coredump_filter do kontrolowania,
       które segmenty pamięci zostaną zapisane do pliku zrzutu pamięci, w przypadku  gdy  pamięć  jest  zrzucana
       przez proces o podanym identyfikatorze.

       Wartość  w  tym pliku jest maską bitową typów mapowań pamięci (patrz mmap(2)). Jeśli bit jest ustawiony w
       masce, to odpowiadające mu mapowanie jest zapisywane w pliku, w przeciwnym wypadku -  nie  jest.  Bity  w
       masce mają następujące znaczenia:

           bit 0  Zrzucanie anonimowych mapowań prywatnych.
           bit 1  Zrzucanie anonimowych mapowań współdzielonych.
           bit 2  Zrzucanie prywatnych mapowań plików.
           bit 3  Zrzucanie współdzielonych mapowań plików.
           bit 4 (od Linuksa 2.6.24)
                  Zrzucanie nagłówków ELF.
           bit 5 (od Linuksa 2.6.28)
                  Zrzucanie prywatnych dużych stron.
           bit 6 (od Linuksa 2.6.28)
                  Zrzucanie współdzielonych dużych stron.
           bit 7 (od Linuksa 4.4)
                  Zrzucanie prywatnych stron DAX.
           bit 8 (od Linuksa 4.4)
                  Zrzucanie współdzielonych stron DAX.

       Domyślnie    ustawione    są    następujące    bity:    0,    1,    4    (jeśli   jest   włączona   opcja
       CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS konfiguracji jądra) oraz 5. Tę wartość domyślną  można  zmodyfikować
       przy rozruchu za pomocą opcji coredump_filter.

       Wartość  tego  pliku  jest wyświetlana szesnastkowo (z tego powodu domyślna wartość jest wyświetlana jako
       33).

       Strony wejścia/wyjścia mapowane w pamięci, takie jak bufor ramki, nigdy  nie  są  zrzucane,  a  wirtualne
       strony DSO (vdso(7)) są zawsze zrzucane, niezależnie od wartości coredump_filter.

       Proces-dziecko  utworzony przez fork(2) dziedziczy wartość coredump_filter od swojego rodzica; wartość ta
       jest także zachowywana podczas execve(2).

       Może być użyteczne ustawienie coredump_filter w powłoce przed uruchomieniem programu, na przykład:

           $ echo 0x7 > /proc/self/coredump_filter
           $ ./some_program

       Plik istnieje, jeśli jądro zostało zbudowane z włączoną opcją konfiguracji CONFIG_ELF_CORE.

   Zrzuty pamięci i systemd
       W systemach korzystających z init w postaci systemd(1), zrzuty pamięci mogą być umieszczane  w  położeniu
       określanym   przez   systemd(1).  systemd(1)  używa  do  tego  funkcji  core_pattern,  która  pozwala  na
       przekazywanie potokiem zrzutów pamięci do programu. Można to zweryfikować, sprawdzając czy zrzuty pamięci
       są przekazywane potokiem do programu systemd-coredump(8):

           $ cat /proc/sys/kernel/core_pattern
           |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e

       W  tym  przypadku,  zrzuty  pamięci będą umieszczane w położeniu skonfigurowanym dla systemd-coredump(8),
       zwykle jako pliki skompresowane  lz4(1),  w  katalogu  /var/lib/systemd/coredump/.  Można  wypisać  listę
       zarejestrowanych przez systemd-coredump(8) zrzutów pamięci za pomocą coredumpctl(1):

       $ coredumpctl list | tail -5
       Wed 2017-10-11 22:25:30 CEST  2748 1000 1000 3 present  /usr/bin/sleep
       Thu 2017-10-12 06:29:10 CEST  2716 1000 1000 3 present  /usr/bin/sleep
       Thu 2017-10-12 06:30:50 CEST  2767 1000 1000 3 present  /usr/bin/sleep
       Thu 2017-10-12 06:37:40 CEST  2918 1000 1000 3 present  /usr/bin/cat
       Thu 2017-10-12 08:13:07 CEST  2955 1000 1000 3 present  /usr/bin/cat

       Informacje  pokazywane  dla  każdego zrzutu pamięci obejmują datę i czas zrzutu, identyfikatory: procesu,
       użytkownika  i  grupy  zrzucającego  procesu,  numer  sygnału  powodującego  zrzut  i  ścieżka  do  pliku
       wykonywalnego,  który  był  uruchomiony przez zrzucany proces. Można podać do coredumpctl(1) wiele opcji,
       które pozwalają wskazać plik zrzutu pamięci,  który  ma  być  wyciągnięty  z  lokalizacji  systemd(1)  do
       określonego  pliku.  Na przykład, aby wydobyć zrzut pamięci dla procesu o PID 2955 pokazanego powyżej, do
       pliku nazwanego core w bieżącym katalogu można użyć polecenia:

           $ coredumpctl dump 2955 -o core

       Więcej szczegółów znajduje się w podręczniku systemowym coredumpctl(1).

       Aby (na  stałe)  wyłączyć  mechanizm  systemd(1)  archiwizujący  zrzuty  pamięci,  przywracając  bardziej
       tradycyjne zachowanie linuksowe, można przesłonić mechanizm systemd(1), za pomocą konstrukcji podobnej do
       poniżej:

           # echo "kernel.core_pattern=core.%p" > \
                          /etc/sysctl.d/50-coredump.conf
           # /lib/systemd/systemd-sysctl

       Można również tymczasowo (do następnego przeładowania systemu) zmienić ustawienie core_pattern poleceniem
       podobnym do poniższego (które powoduje włączenie do nazw zrzutu pamięci również nazwy pliku wykonywalnego
       i numer sygnału wyzwalające zrzut pamięci):

           # sysctl -w kernel.core_pattern="%e-%s.core"

UWAGI

       Aby uzyskać zrzut pamięci działającego procesu, można użyć polecenia gcore programu gdb(1).

       W wersjach jądra Linux do 2.6.27 włącznie, jeżeli pamięć zrzuca  proces  wielowątkowy  (albo  -  bardziej
       precyzyjnie  -  proces,  który  dzieli  swą  pamięć  z innym procesem utworzonym z flagą CLONE_VM funkcji
       clone(2)), to identyfikator  procesu  zawsze  będzie  dołączony  do  nazwy  pliku  zrzutu,  chyba  że  ów
       identyfikator  procesu już występuje w nazwie pliku, ponieważ w pliku /proc/sys/kernel/core_pattern użyto
       specyfikatora  p  (Jest  to  szczególnie  użyteczne  podczas   stosowania   przestarzałej   implementacji
       LinuxThreads, w której każdy wątek procesu ma inny PID).

PRZYKŁADY

       Poniższy  program  pokazuje  użycie  składni potoku w pliku /proc/sys/kernel/core_pattern. Poniższa sesja
       powłoki demonstruje użycie tego programu (skompilowanego do pliku o nazwie  core_pattern_pipe_test):

           $ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
           $ su
           Hasło:
           # echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \
           /proc/sys/kernel/core_pattern
           # exit
           $ sleep 100
           ^\                     # wpisz control+odwrotny ukośnik
           Quit (core dumped)
           $ cat core.info
           argc=5
           argc[0]=</home/mtk/core_pattern_pipe_test>
           argc[1]=<20575>
           argc[2]=<UID=1000>
           argc[3]=<GID=100>
           argc[4]=<sig=3>
           Całkowita liczba bajtów pliku core: 282624

   Kod źródłowy programu

       /* core_pattern_pipe_test.c */

       #define _GNU_SOURCE
       #include <sys/stat.h>
       #include <fcntl.h>
       #include <limits.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <unistd.h>

       #define BUF_SIZE 1024

       int
       main(int argc, char *argv[])
       {
           ssize_t nread, tot;
           char buf[BUF_SIZE];
           FILE *fp;
           char cwd[PATH_MAX];

           /* Zmienia bieżący katalog roboczy na katalog procesu
              który generuje zrzut pamięci. */

           snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);
           chdir(cwd);

           /* Zapisuje wyjście do pliku "core.info" w tym katalogu. */

           fp = fopen("core.info", "w+");
           if (fp == NULL)
               exit(EXIT_FAILURE);

           /* Wyświetla argumenty wiersza poleceń przekazane do programu
              filtrującego "core_pattern". */

           fprintf(fp, "argc=%d\n", argc);
           for (size_t j = 0; j < argc; j++)
               fprintf(fp, "argc[%zu]=<%s>\n", j, argv[j]);

           /* Zlicza bajty na standardowym wejściu (daje rozmiar
              zrzutu pamięci). */

           tot = 0;
           while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)
               tot += nread;
           fprintf(fp, "Całkowita liczba bajtów pliku core: %zd\n", tot);

           fclose(fp);
           exit(EXIT_SUCCESS);
       }

ZOBACZ TAKŻE

       bash(1),  coredumpctl(1),  gdb(1),  getrlimit(2),  mmap(2),  prctl(2),  sigaction(2),  elf(5),   proc(5),
       pthreads(7), signal(7), systemd-coredump(8)

TŁUMACZENIE

       Autorami  polskiego  tłumaczenia  niniejszej  strony podręcznika są: Robert Luberda <robert@debian.org> i
       Michał Kułach <michal.kulach@gmail.com>

       Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje  o  warunkach  licencji  można  uzyskać
       zapoznając  się  z  GNU General Public License w wersji 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ lub
       nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

       Błędy w tłumaczeniu  strony  podręcznika  prosimy  zgłaszać  na  adres  listy  dyskusyjnej  ⟨manpages-pl-
       list@lists.sourceforge.net⟩.