Zombie Process

Giriş
Eğer sistemde bir kaç tane zombie process varsa genelde çok bir sorun teşkil etmez. Eğer zombie process sayısı sürekli artıyorsa PID numaraları biteceği için sorun olabilir.

Zombie Process'ten Kurtulmak
Açıklaması şöyle

One way to kill zombie is by sending the SIGCHLD signal to the parent process. This signal tells the parent process to execute the wait() system call and clean up its zombie children.

Parent process's şu komutu göndeririz.

kill -s SIGCHLD pid

Zombie Process Nasıl Bulunur?

top komutu kullanılabilir. S sütununda - Status sütunu anlamına gelir - bazı harfler görünür. Bir harf Z ise Zombie anlamına gelir. Harfle şöyle

Process status is reported with a single character:

R — RUNNING/RUNNABLE

S — INTERRUPTABLE_SLEEP

D — UNINTERRUPTABLE_SLEEP

T — STOPPED

Z — ZOMBIE

systemd-resolve komutu

Giriş
Açıklaması şöyle. Bu komut yerine sanırım kullandığımız desktop tarafından sağlanan NetworkManager'ı kullanmak daha kolay.

systemd-resolved is a service that provides DNS name resolution to local services and applications and it can be configured with Netplan, the default network management tool on Ubuntu 18.04.

Netplan configuration files are stored in the /etc/netplan directory. You’ll probably find one or two YAML files in this directory. The file name may differ from setup to setup. Usually, the file is named either 01-netcfg.yaml or 50-cloud-init.yaml but in your system, it may be different.

These files allow you to configure the network interface, including the IP address, gateway, DNS nameservers, and so on.

--status seçeneği
Bu komutun çıktısı çok uzun. İstenilen kısımı görmek için grep'lemek gerekiyor.
Örnek
Şöyle yaparız. Bu komut sadece tek DNS sunucusu gösterir.

sudo systemd-resolve --status | grep "DNS Server"

Tüm DNS sunucularını görmek için şöyle yaparız

systemd-resolve --status | grep 'DNS Servers' -A2

Pipe Verisi Nerede Saklanır

Giriş
Eski Unix'lerde pipe'a giren veri diskte saklanırdı. Günümüzde disk yerine RAM kullanılıyor. Açıklaması şöyle

Early versions of Unix didn't hold pipe data in RAM. They stored them on disc. Pipes had i-nodes; on a disc device that was denoted the pipe device. The system administrator ran a program named /etc/config to specify (amongst other things) which volume on which disc was the pipe device, which volume was the root device, and which the dump device.

The amount of pending data was constrained by the fact that only the direct blocks of the i-node on disc were used for storage. This mechanism made the code simpler, because much the same algorithm was employed for reading from a pipe as was employed for reading for a regular file, with some tweaks caused by the fact that pipes are non-seekable and the buffer is circular.

This mechanism was replaced by others in the middle to late 1980s. SCO XENIX gained the "High Performance Pipe System", which replaced i-nodes with in-core buffers. 4BSD made unnamed pipes into socketpairs. AT&T reimplemented pipes using the STREAMS mechanism.

And of course the sort program performed a limited internal sort of 32KiB chunks of input (or whatever smaller amount of memory it could allocate if 32KiB was not available), writing the sorted results to intermediate stmX?? files in /usr/tmp/ which it then externally merge sorted to provide the final output.

Named Pipe (FIFO) oluşturmak için mkfifo komutu kullanılabilir.

Windows tasklist komutu

/fi seçeneği
Süzerek listeler. Şöyle yaparız

tasklist /svc /fi "PID eq 5516"

/svc seçeneği

Uygulama ve çalıştırdığı servisleri listeler. Şöyle yaparız

tasklist /svc

/v seçeneği

Verbose - daha fazla - bilgi verir. Şöyle yaparız

tasklist /v

LD_DEBUG komutu

Giriş
Hangi kütüphanalerin yüklendiğini gösterir.

libs seçeneği
Şöyle yaparız.

LD_DEBUG=libs your-application

LC_ALL Ortam Değişkeni - Tüm Localization Değişkenlerini Ezer

Giriş
- locale komutu yazısına bakabilirsiniz.
- LANG Ortam Değişkeni yazısına bakabilirsiniz.

Açıklaması şöyle. Genellikle bir script içinde kullanıcının diğer ayaları ile teker teker uğraşmadan her yerelleştirme ayarını hep birlikte bir değere geçirmek için kullanılır

LC_ALL is the environment variable that overrides all the other localisation settings

Örnek
Şöyle yaparız.

export LC_ALL=en_US.UTF-8

Locale İsimleri Nasıldır

Açıklaması şöyle

Locale names are typically of the form language[_territory][.codeset][@modifier]

Burada modifier kısmı biraz belirsiz. Açıklaması şöyle. Yani locale'i aynı tutup önemli bir değişikliği de dahil edebilmek için kullanılıyor

The @modifier setting specifies a variant. A minor addition in the encoding set. As an example :

European countries have long time relied on ISO definitions. Some French, for example (language fr, country FR) would have most probably set their codeset to ISO-8859-1 in the following way :fr_FR.ISO-8859-1


Then comes a new currency, the Euro and the the associated currency symbol could be made available via Alt Gr E while keeping the ISO-8859-15 encoding.fr_FR.ISO-8859-1@euro

Benzer bir açıklama şöyle

For example, in Germany, if you had your locale set to de_DE.UTF-8 in the early 2000s, a banking program that uses the locale information to determine the default currency would probably have chosen DM as the default, but if you change the locale to de_DE.UTF-8@euro, the default might have been €.

Localization Değişkenlerinin Öncelik Sırası

Localization değerlerini değiştirmek için bir sürü değişken var. Bunların önem sırası şöyle

1. LANG_ALL - Her şeyi ezer
2. LC_XYZ değişkenleri - Eğer varsa bu değişkenler kullanılır
3. LANG - En düşük sıradaki değişken budur.

Örnek

Elimizde şöyle bir kod olsun. Burada LC_NUMERIC değişkeni LANG'dan önce gelir. Bu yüzden printf Almanca'da ayraç olarak virgül kullanıldığı için 3.14 değerini algılayamaz ve hata verir.

$ export LC_NUMERIC="de_DE.UTF-8"
$ export LANG=C
$ printf "%.2f\n" 3.14
-bash: printf: 3.14: invalid number
3,00

Ancak kodu şöyle değiştirelim. Bu durumda LC_ALL her şey ezecek ve yerelleştirmeyi C yapacaktır. Böylece printf çalışır.

$ export LC_NUMERIC="de_DE.UTF-8"
$ export LC_ALL=C
$ printf "%.2f\n" 3.14
3.14

LC_ALL Ne Zaman Kullanılır
Normalde LC_ALL değişkenine değer atanmaz, sadece LANG ve LC_X değişkenlerine değer atanır. Bence sadece script içinde kullanılmalıdır.

Sıralama - Sorting
Sıralama (sorting) en etkilinden başlayarak şu 3 değişkene göre yapılır.

LC_ALL, LC_COLLATE ve LANG

LC_ALL normalde boş olduğu için LC_COLLATE değişkeni devreye girer.

Örnek - C Kullanımı
Açıklaması şöyle. Yani bu komut aslında string karşılaştırması yapar.

Note that some uniq implementations like GNU uniq will give you the first of a sequence of lines that sort the same (where strcoll() returns 0) as opposed to are byte-to-byte identical (where memcmp() or strcmp() returns 0). To force a byte to byte comparison regardless of the uniq implementation, you can force the locale to C with:

Byte karşılaştırması için şöyle yaparız.

LC_ALL=C uniq your-file




LD_LIBRARY_PATH

Giriş
- Bu ortam değişkeninin OS X'teki karşılığı DYLD_LIBRARY_PATH ortam değişkeni. 

- Bu ortam değişkeninin Windows'taki karşılığı PATH ortam değişkeni. 

Bu değişken Java uygulamalarındaki java.library.path  değişkeninin iliklendirilmesini sağlar.

/lib ve /lib64 farkı
Bazı sistemlerde /lib dizininde 32 bit kütüphaneler /lib64 dizininde ise 64 bit kütüphaneler bulunur.

System Wide Settings
Açıklaması şöyle. Eğer sistem bazında değişiklik yapmak istersek ldconfig kullanılır.

If you need a LD_LIBRARY_PATH (but you probably should not), set it yourself (e.g. in  ~/.bashrc).

If you need system wide settings, you could e.g. consider adding  /usr/local/lib/ in /etc/ld.so.conf and run ldconfig after installation of every library there.

AFAIK $LD_LIBRARY_PATH is used only by the dynamic linker ld-linux.so (and by dlopen(3) which uses it) after execve(2). See also ldd(1).

Örnek
Şöyle yaparız

LD_LIBRARY_PATH=/home/my_lib/boost_1_64_0/stage/lib:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH