One place for hosting & domains

      Cara Menggunakan Systemctl untuk Mengelola Layanan dan Unit Systemd


      Pengantar

      Systemd adalah sistem init dan pengelola sistem yang secara luas telah menjadi standar baru untuk berbagai distribusi Linux. Karena digunakan secara luas, memahami systemd akan mengatasi banyak masalah, karena ini akan membuat pengelolaan server menjadi jauh lebih mudah. Mempelajari dan memanfaatkan berbagai alat dan daemon yang meliputi systemd akan membantu Anda menghargai kehebatan, fleksibilitas, dan kemampuan yang diberikannya dengan lebih baik, atau setidaknya membantu Anda melakukan pekerjaan tanpa banyak kesulitan.

      Dalam panduan ini, kita akan membahas perintah systemctl, yang merupakan alat manajemen pusat untuk mengontrol sistem init. Kita akan membahas cara mengelola layanan, memeriksa status, mengubah keadaan sistem, dan menangani berkas konfigurasi.

      Harap diperhatikan bahwa meskipun systemd telah menjadi sistem init asali untuk banyak distribusi Linux, tetapi tidak diterapkan secara universal ke semua distribusi. Saat mengikuti tutorial ini, jika terminal Anda memberikan keluaran pesan kesalahan bash: systemctl is not installed, kemungkinan mesin Anda menginstal sistem init yang berbeda.

      Manajemen Layanan

      Kegunaan mendasar dari sistem init adalah menginisialisasi komponen yang harus dimulai setelah kernel Linux melakukan boot (biasanya dikenal dengan komponen “userland”). Sistem init juga digunakan untuk mengelola layanan dan daemon bagi server di titik apa pun selama sistem dijalankan. Dengan mengingat hal itu, kita akan mulai dengan beberapa operasi manajemen layanan dasar.

      Di systemd, target sebagian besar tindakan adalah “unit”, yakni sumber daya yang diketahui cara pengelolaannya oleh systemd. Unit dikelompokkan menurut tipe sumber daya yang diwakilinya dan didefinisikan bersama berkas yang dikenal dengan berkas unit. Tipe setiap unit dapat ditebak dari akhiran di belakang berkas.

      Untuk tugas manajemen layanan, unit target akan berupa unit layanan, yang memiliki berkas unit dengan akhiran .service. Namun, untuk kebanyakan perintah manajemen layanan, Anda sebenarnya dapat menanggalkan akhiran .service, karena systemd sudah cukup cerdas untuk mengetahui bahwa Anda mungkin ingin mengoperasikan suatu layanan saat menggunakan perintah manajemen layanan.

      Memulai dan Menghentikan Layanan

      Untuk memulai layanan systemd, yang mengeksekusi instruksi dalam berkas unit layanan, gunakan perintah start. Jika menjalankan sebagai pengguna non-root, Anda akan perlu menggunakan sudo karena ini akan memengaruhi keadaan sistem operasi:

      • sudo systemctl start application.service

      Seperti yang kami sebutkan di atas, systemd tahu untuk mencari berkas *.service untuk perintah manajemen layanan, sehingga perintah dapat diketikkan semudah ini:

      • sudo systemctl start application

      Meskipun Anda mungkin menggunakan format di atas untuk administrasi umum, demi kejelasan, kita akan menggunakan akhiran .service untuk perintah selebihnya, agar target operasi kita lebih jelas.

      Untuk menghentikan layanan yang sedang berjalan, Anda dapat menggunakan perintah stop sebagai gantinya:

      • sudo systemctl stop application.service

      Memulai Ulang dan Memuat Ulang

      Untuk memulai ulang layanan yang sedang berjalan, Anda dapat menggunakan perintah restart:

      • sudo systemctl restart application.service

      Jika aplikasi tersebut dapat memuat ulang berkas konfigurasinya (tanpa memulai ulang), Anda dapat memberikan perintah reload untuk memulai proses:

      • sudo systemctl reload application.service

      Jika tidak yakin apakah layanan memiliki fungsionalitas untuk memuat ulang konfigurasinya, Anda dapat memberikan perintah reload-or-restart. Perintah ini akan memuat ulang konfigurasi jika tersedia. Jika tidak, perintah ini akan memulai ulang layanan sehingga konfigurasi baru akan diambil:

      • sudo systemctl reload-or-restart application.service

      Mengaktifkan dan Menonaktifkan Layanan

      Perintah di atas berguna untuk memulai atau menghentikan layanan selama sesi yang berjalan saat ini. Untuk memberi tahu systemd agar memulai layanan secara otomatis saat boot, Anda harus mengaktifkannya.

      Untuk memulai layanan saat boot, gunakan perintah enable:

      • sudo systemctl enable application.service

      Ini akan membuat tautan simbolis dari salinan berkas layanan sistem (biasanya di /lib/systemd/system atau /etc/systemd/system) ke dalam lokasi di diska tempat systemd mencari berkas autostart (biasanya /etc/systemd/system/some_target.target.wants. Kita akan membahas targetnya nanti dalam panduan ini).

      Untuk menonaktifkan layanan agar tidak dimulai secara otomatis, Anda dapat mengetikkan:

      • sudo systemctl disable application.service

      Ini akan menghapus tautan simbolis yang menandakan bahwa layanan harus dimulai secara otomatis.

      Ingatlah bahwa mengaktifkan layanan tidak akan memulainya di sesi saat ini. Jika Anda ingin memulai layanan dan juga mengaktifkannya saat boot, Anda harus memberikan perintah start dan enable.

      Memeriksa Status Layanan

      Untuk memeriksa status layanan di sistem, Anda dapat menggunakan perintah status:

      • systemctl status application.service

      Perintah ini akan memberi tahu Anda keadaan layanan, hierarki cgroup, dan beberapa baris log pertama.

      Misalnya, saat memeriksa status server Nginx, Anda mungkin melihat keluaran seperti ini:

      Output

      ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

      Ini memberikan gambaran bagus tentang status aplikasi saat ini, yang memberi tahu Anda masalah dan tindakan yang mungkin diperlukan.

      Ada juga metode untuk memeriksa keadaan tertentu. Misalnya, untuk memeriksa agar tahu apakah suatu unit sedang aktif (berjalan), Anda dapat menggunakan perintah is-active:

      • systemctl is-active application.service

      Ini akan menunjukkan keadaan unit saat ini, yang biasanya berupa active atau inactive. Kode yang keluar akan “0” jika aktif, sehingga membuat hasilnya jadi lebih mudah diurai dalam skrip shell.

      Untuk melihat apakah unit diaktifkan, Anda dapat menggunakan perintah is-enabled:

      • systemctl is-enabled application.service

      Ini akan memberikan keluaran apakah layanan enabled atau disabled dan akan menetapkan lagi kode keluar ke “0” atau “1”, tergantung jawaban terhadap pertanyaan perintah.

      Pemeriksaan ketiga adalah apakah unit dalam keadaan gagal. Ini menandakan adanya masalah saat memulai unit tersebut:

      • systemctl is-failed application.service

      Hasilnya akan menjadi active jika berjalan dengan benar atau failed jika terjadi kesalahan. Jika unit sengaja dihentikan, hasilnya mungkin akan berupa unknown atau inactive. Status keluar “0” menandakan terjadi suatu kegagalan dan status keluar “1” menandakan status lainnya.

      Gambaran Umum Keadaan Sistem

      Sejauh ini, perintah berguna untuk mengelola layanan tunggal, tetapi tidak terlalu berguna untuk mempelajari keadaan sistem saat ini. Ada sejumlah sejumlah perintah systemctl yang memberikan informasi ini.

      Menampilkan Daftar Unit Saat Ini

      Untuk melihat daftar semua unit aktif yang diketahui systemd, kita dapat menggunakan perintah list-units:

      Perintah ini akan menampilkan semua unit systemd yang saat ini aktif di sistem. Keluarannya akan terlihat seperti ini:

      Output

      UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . .

      Keluarannya memiliki kolom berikut:

      • UNIT: Nama unit systemd
      • LOAD: Apakah konfigurasi unit telah diurai oleh systemd. Konfigurasi unit yang dimuat tersimpan dalam memori.
      • ACTIVE: Ringkasan keadaan apakah unit aktif. Ini biasanya cara yang cukup mendasar untuk mengetahui apakah unit berhasil dimulai atau tidak.
      • SUB: Ini tingkat keadaan lebih rendah yang menunjukkan informasi lebih detail tentang unit. Ini seringkali bervariasi menurut tipe unit, keadaan, dan metode aktual unit yang dijalankan.
      • DESCRIPTION: Deskripsi teks singkat tentang apa yang dilakukan unit.

      Karena perintah list-units hanya menampilkan unit aktif secara asali, semua entri di atas akan menampilkan loaded dalam kolom LOAD dan active dalam kolom ACTIVE. Tampilan ini sebenarnya adalah perilaku asali systemctl bila dipanggil tanpa perintah tambahan, sehingga Anda akan melihat hal yang sama jika memanggil systemctl tanpa argumen:

      Kita dapat menyuruh systemctl agar mengeluarkan informasi yang berbeda dengan memberikan bendera tambahan. Misalnya, untuk melihat semua unit yang telah dimuat (atau berupaya dimuat) oleh systemd , entah saat ini aktif atau tidak, Anda dapat menggunakan bendera --all, seperti ini:

      • systemctl list-units --all

      Ini akan menampilkan unit yang telah dimuat atau berupaya dimuat oleh systemd, terlepas dari keadaannya saat ini di sistem. Beberapa unit menjadi tidak aktif setelah berjalan, dan beberapa unit yang berupaya dimuat oleh systemd mungkin tidak ditemukan pada diska.

      Anda dapat menggunakan bendera lain untuk menyaring hasil ini. Misalnya, kita dapat menggunakan bendera --state= untuk menandai keadaan LOAD, ACTIVE, atau SUB yang ingin kita lihat. Anda harus mempertahankan bendera --all agar systemctl mengizinkan unit nonaktif untuk ditampilkan:

      • systemctl list-units --all --state=inactive

      Filter umum lainnya adalah filter --type=. Kita dapat menyuruh systemctl agar hanya menampilkan unit dengan tipe yang kita minati. Misalnya, untuk melihat unit layanan aktif saja, kita dapat menggunakan:

      • systemctl list-units --type=service

      Menampilkan Daftar Semua Berkas Unit

      Perintah list-units hanya menampilkan unit yang telah berupaya diurai dan dimuat systemd ke dalam memori. Karena systemd hanya akan membaca unit yang dianggapnya perlu, maka tidak perlu menyertakan semua unit yang tersedia di sistem. Untuk melihat setiap berkas unit yang tersedia dalam jalur systemd, termasuk berkas yang tidak berupaya dimuat oleh systemd, Anda dapat menggunakan perintah list-unit-files sebagai gantinya:

      • systemctl list-unit-files

      Unit adalah representasi dari sumber daya yang diketahui systemd. Karena systemd menganggap belum perlu membaca semua definisi unit di tampilan ini, systemd hanya menampilkan informasi tentang berkas itu saja. Keluarannya memiliki dua kolom: berkas unit dan keadaan.

      Output

      UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .

      Keadaan biasanya berupa enabled, disabled, static, atau masked. Dalam konteks ini, static berarti berkas unit tidak berisi bagian install, yang digunakan untuk mengaktifkan unit. Dengan demikian, unit-unit ini tidak dapat diaktifkan. Biasanya, ini berarti unit melakukan tindakan sekali-jalan atau hanya digunakan sebagai dependensi unit lain dan tidak boleh dijalankan dengan sendirinya.

      Kita akan membahas makna masked sebentar lagi.

      Manajemen Unit

      Sejauh ini, kita telah menggunakan beberapa layanan dan menampilkan informasi tentang unit dan berkas unit yang diketahui oleh systemd. Namun, kita dapat mengetahui informasi yang lebih spesifik tentang unit menggunakan beberapa perintah tambahan.

      Menampilkan Berkas Unit

      Untuk menampilkan berkas unit yang telah dimuat systemd ke dalam sistemnya, Anda dapat menggunakan perintah cat (ini telah ditambahkan dalam systemd versi 209). Misalnya, untuk melihat berkas unit daemon penjadwalan atd, kita dapat mengetikkan:

      • systemctl cat atd.service

      Output

      [Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target

      Keluaran adalah berkas unit yang diketahui systemd sebagai proses yang sedang berjalan. Ini dapat menjadi hal penting jika Anda baru-baru ini telah memodifikasi berkas unit atau jika Anda mengesampingkan beberapa opsi tertentu dalam fragmen berkas unit (kita akan membahasnya nanti).

      Menampilkan Dependensi

      Untuk melihat pohon dependensi unit, Anda dapat menggunakan perintah list-dependencies:

      • systemctl list-dependencies sshd.service

      Perintah ini akan menampilkan pemetaan hierarki yang harus ditangani agar dapat memulai unit tersebut. Dependensi dalam konteks ini meliputi unit-unit yang diperlukan oleh atau yang diinginkan oleh unit di atasnya.

      Output

      sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .

      Dependensi rekursif hanya ditampilkan untuk unit .target, yang menandakan keadaan sistem. Untuk menampilkan daftar semua dependensi secara rekursif, sertakan bendera --all.

      Untuk menampilkan dependensi terbalik (unit yang bergantung pada unit yang ditentukan), Anda dapat menambahkan bendera --reverse pada perintah. Bendera lain yang berguna adalah --before dan --after, yang dapat digunakan untuk menampilkan unit yang bergantung pada unit yang ditentukan yang masing-masing dimulai sebelum dan setelah unit itu sendiri.

      Memeriksa Properti Unit

      Untuk melihat properti tingkat rendah dari suatu unit, Anda dapat menggunakan perintah show. Perintah ini akan menampilkan daftar properti yang diatur untuk unit yang ditentukan menggunakan format key=value:

      • systemctl show sshd.service

      Output

      Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . . .

      Jika ingin menampilkan properti tunggal, Anda dapat memberikan bendera -p bersama nama properti. Misalnya, untuk melihat konflik yang dimiliki unit sshd.service, Anda dapat mengetikkan:

      • systemctl show sshd.service -p Conflicts

      Output

      Conflicts=shutdown.target

      Melakukan Masking dan Unmasking Unit

      Di bagian manajemen layanan, kita telah melihat cara menghentikan atau menonaktifkan layanan, tetapi systemd juga memiliki kemampuan untuk menandai suatu unit menjadi tidak dapat dimulai sama sekali, secara otomatis atau manual, dengan menautkannya ke /dev/null. Perintah ini disebut masking unit, dan dapat dilakukan dengan perintah mask:

      • sudo systemctl mask nginx.service

      Perintah ini akan mencegah layanan Nginx dimulai, secara otomatis atau manual, selama unit tersebut diberi mask.

      Jika Anda memeriksa list-unit-files, Anda akan melihat layanan kini tercantum sebagai diberi mask:

      • systemctl list-unit-files

      Output

      . . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .

      Jika Anda berupaya memulai layanan, Anda akan melihat pesan seperti ini:

      • sudo systemctl start nginx.service

      Output

      Failed to start nginx.service: Unit nginx.service is masked.

      Untuk melakukan unmask di suatu unit, agar unit dapat digunakan lagi, gunakan perintah unmask:

      • sudo systemctl unmask nginx.service

      Ini akan mengembalikan unit ke keadaan sebelumnya, yang memungkinkannya dimulai atau diaktifkan.

      Mengedit Berkas Unit

      Walaupun format spesifik untuk berkas unit berada di luar lingkup tutorial ini, systemctl memberikan mekanisme bawaan untuk mengedit dan memodifikasi berkas unit jika Anda perlu membuat penyesuaian. Fungsionalitas ini ditambahkan dalam systemd versi 218.

      Perintah edit secara asali akan membuka cuplikan berkas unit untuk unit tersebut:

      • sudo systemctl edit nginx.service

      Ini akan berupa berkas kosong yang dapat digunakan untuk mengesampingkan atau menambahkan arahan ke definisi unit. Direktori akan dibuat dalam direktori /etc/systemd/system yang berisi nama unit dengan tambahan .d. Misalnya, untuk nginx.service, suatu direktori bernama nginx.service.d akan dibuat.

      Di dalam direktori ini, cuplikan akan dibuat dengan nama override.conf. Bila unit dimuat, systemd dalam memori akan menggabungkan cuplikan yang dikesampingkan dengan berkas unit penuh. Arahan cuplikan akan menjadi prioritas daripada yang ada dalam berkas unit asli.

      Jika Anda ingin mengedit berkas unit penuh alih-alih membuat cuplikan, Anda dapat memberikan bendera --full:

      • sudo systemctl edit --full nginx.service

      Perintah ini akan memuat berkas unit saat ini ke dalam editor, yang dapat dimodifikasi. Ketika keluar dari editor, berkas yang diubah ditulis ke /etc/systemd/system, yang akan menjad prioritas dari definisi unit sistem (biasanya ditemukan di /lib/systemd/system).

      Untuk menghapus tambahan yang telah Anda buat, hapus direktori konfigurasi .d unit atau berkas layanan yang dimodifikasi dari /etc/systemd/system. Misalnya, untuk menghapus cuplikan, kita dapat mengetikkan:

      • sudo rm -r /etc/systemd/system/nginx.service.d

      Untuk menghapus berkas unit yang dimodifikasi sepenuhnya, kita ketikkan:

      • sudo rm /etc/systemd/system/nginx.service

      Setelah menghapus berkas atau direktori, Anda harus memuat ulang proses systemd agar tidak lagi berupaya merujuk berkas-berkas ini dan kembali menggunakan salinan sistem. Anda dapat melakukannya dengan mengetikkan:

      • sudo systemctl daemon-reload

      Menyesuaikan Keadaan Sistem (Runlevel) dengan Target

      Target adalah berkas unit khusus yang menggambarkan keadaan sistem atau titik sinkronisasi. Seperti unit lainnya, berkas yang mendefinisikan target dapat diidentifikasi melalui akhirannya, yang dalam hal ini adalah .target. Target tidak mencocokkan dirinya sendiri, melainkan digunakan untuk mengelompokkan unit lain menjadi satu.

      Perintah ini dapat digunakan untuk membawa sistem ke keadaan tertentu, seperti sistem init lainnya yang menggunakan runlevel. Semua itu digunakan sebagai referensi ketika fungsi tertentu tersedia, yang memungkinkan Anda menentukan keadaan yang diinginkan sebagai ganti unit individual yang diperlukan untuk menghasilkan keadaan itu.

      Misalnya, ada swap.target yang digunakan untuk menunjukkan bahwa swap siap digunakan. Unit yang menjadi bagian dari proses ini dapat menyinkronkan dengan target ini dengan menunjukkannya dalam konfigurasi bahwa unit tersebut WantedBy= atau RequiredBy= oleh swap.target. Unit yang mengharuskan swap tersedia dapat menentukan syarat ini menggunakan spesifikasi Wants=, Requires=, dan After= untuk menandakan sifat hubungannya.

      Mendapatkan dan Mengatur Target Asali

      Proses systemd memiliki target asali yang digunakannya saat melakukan boot sistem. Memenuhi kaskade dependensi dari target tunggal itu akan membawa sistem ke keadaan yang diinginkan. Untuk menemukan target asali bagi sistem Anda, ketikkan:

      Output

      multi-user.target

      Jika ingin menetapkan target asali yang berbeda, Anda dapat menggunakan set-default. Misalnya, jika Anda telah menginstal desktop grafis dan ingin agar sistem melakukan boot ke desktop grafis secara asali, Anda dapat mengubah target asalinya:

      • sudo systemctl set-default graphical.target

      Menampilkan Daftar Target yang Tersedia

      Anda bisa mendapatkan daftar target yang tersedia di sistem dengan mengetikkan:

      • systemctl list-unit-files --type=target

      Tidak seperti runlevel, beberapa target dapat aktif sekaligus. Target aktif menandakan bahwa systemd berupaya memulai semua unit yang terikat ke target dan tidak mencoba untuk memutusnya lagi. Untuk melihat semua target aktif, ketikkan:

      • systemctl list-units --type=target

      Mengisolasi Target

      Bisa saja memulai semua unit yang telah dikaitkan dengan target dan menghentikan semua unit yang bukan bagian dari pohon dependensi. Perintah yang kita perlukan untuk melakukannya disebut isolate. Ini mirip dengan mengubah runlevel di sistem init lainnya.

      Misalnya, jika Anda beroperasi di lingkungan grafis dengan graphical.target aktif, Anda dapat mematikan sistem grafis dan memasukkan sistem ke bentuk baris perintah multipengguna dengan mengisolasi multi-user.target. Karena graphical.target bergantung pada multi-user.target, tetapi tidak ada cara lainnya lagi, semua unit grafis akan dihentikan.

      Anda mungkin perlu melihat dependensi target yang diisolasi sebelum melakukan prosedur ini untuk memastikan bahwa Anda tidak menghentikan layanan penting:

      • systemctl list-dependencies multi-user.target

      Bila Anda puas dengan unit yang akan dibiarkan tetap aktif, Anda dapat mengisolasi target dengan mengetikkan:

      • sudo systemctl isolate multi-user.target

      Menggunakan Pintasan untuk Kejadian Penting

      Ada beberapa target yang didefinisikan untuk kejadian penting seperti mematikan daya atau melakukan boot ulang. Namun, systemctl juga memiliki beberapa pintasan yang memberikan beberapa fungsi tambahan.

      Misalnya, untuk menempatkan sistem ke dalam mode pertolongan (pengguna tunggal), Anda dapat menggunakan perintah rescue sebagai ganti isolate rescue.target:

      Perintah ini akan memberikan fungsi tambahan yang memperingatkan semua pengguna yang log masuk tentang kejadian tersebut.

      Untuk menghentikan sistem, Anda dapat menggunakan perintah halt:

      Untuk mulai mematikan daya sepenuhnya, Anda dapat menggunakan perintah poweroff:

      Menyalakan ulang dapat dimulai dengan perintah reboot:

      Ini semua akan memperingatkan para pengguna yang log masuk mengenai kejadian tersebut, satu-satunya hal yang tidak akan dilakukan oleh menjalankan atau mengisolasi target. Harap diperhatikan bahwa kebanyakan mesin akan menautkan perintah yang lebih pendek dan lebih konvensional untuk operasi ini agar berfungsi secara benar dengan systemd.

      Misalnya, untuk melakukan boot ulang sistem, Anda biasanya dapat mengetikkan:

      Kesimpulan

      Saat ini, Anda sudah memahami beberapa kemampuan dasar dari perintah systemctl yang memungkinkan Anda berinteraksi dengan dan mengendalikan instans systemd. Utilitas systemctl adalah titik utama interaksi Anda untuk manajemen layanan dan keadaan sistem.

      Walaupun systemctl terutama beroperasi dengan proses inti systemd, ada beberapa komponen lain di ekosistem systemd yang dikendalikan oleh utilitas lain. Kemampuan lainnya, seperti manajemen log dan sesi pengguna yang ditangani oleh daemon terpisah dan utilitas manajemen (masing-masing yaitu journald/journalctl dan logind/loginctl). Menyisihkan waktu untuk memahami berbagai alat dan daemon lain akan membuat manajemen menjadi tugas yang lebih mudah.



      Source link

      CSS Grid Layout: The Fr Unit


      While this tutorial has content that we believe is of great benefit to our community, we have not yet tested or
      edited it to ensure you have an error-free learning experience. It’s on our list, and we’re working on it!
      You can help us out by using the “report an issue” button at the bottom of the tutorial.

      Introduction

      With CSS Grid Layout, we get a new flexible unit: the Fr unit. Fr is a fractional unit and 1fr is for 1 part of the available space. The following are a few examples of the fr unit at work. The grid items in these examples are placed onto the grid with grid areas.

      .container {
        display: grid;
      
        grid-template-columns: 1fr 1fr 1fr 1fr;
        grid-template-rows: 100px 200px 100px;
      
        grid-template-areas:
              "head head2 . side"
              "main main2 . side"
              "footer footer footer footer";
      }
      

      The 4 columns each take up the same amount of space.

      Head

      Head 2

      Main

      Main 2

      Side

      Footer

      Examples using fr

      Here’s the same example from above with different fr values. Notice the change in the layout:

      .container {
        /* ... */
      
        grid-template-columns: 1fr 1fr 40px 20%;
        grid-template-rows: 100px 200px 100px;
      
        /* ... */
      }
      

      Head

      Head 2

      Main

      Main 2

      Side

      Footer


      In the following last example, the sidebar item covers 2fr, so it’ll be the same width as the items that span the 1st and 2nd columns:

      .container {
        /* ... */
      
        grid-template-columns: 1fr 1fr 40px 2fr;
        grid-template-rows: 100px 200px 100px;
      
        /* ... */
      }
      

      Head

      Head 2

      Main

      Main 2

      Side

      Footer

      Mixed Units

      As you saw in the previous examples, you can mix fr values with fixed and percentage values. The fr values will be divided between the space that’s left after what’s taken by the other values.

      For example, if you have a grid with 4 columns as in the following snippet, the 1st column will be 300px, the second 80px (10% of 800px), the 3rd and 4th columns will be 210px (each occupying half of the remaining space):

      main {
        width: 800px;
        display: grid;
        grid-template-columns: 300px 10% 1fr 1fr;
        /* 300px 80px 210px 210px */
      
        grid-template-rows: auto;
      }
      



      Source link

      How To Add Unit Testing to Your Django Project


      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      It is nearly impossible to build websites that work perfectly the first time without errors. For that reason, you need to test your web application to find these errors and work on them proactively. In order to improve the efficiency of tests, it is common to break down testing into units that test specific functionalities of the web application. This practice is called unit testing. It makes it easier to detect errors because the tests focus on small parts (units) of your project independently from other parts.

      Testing a website can be a complex task to undertake because it is made up of several layers of logic like handling HTTP requests, form validation, and rendering templates. However Django provides a set of tools that makes testing your web application seamless. In Django, the preferred way to write tests is to use the Python unittest module, although it is possible to use other testing frameworks.

      In this tutorial, you will set up a test suite in your Django project and write unit tests for the models and views in your application. You will run these tests, analyze their results, and learn how to find the causes of failing tests.

      Prerequisites

      Before beginning this tutorial, you’ll need the following:

      Step 1 — Adding a Test Suite to Your Django Application

      A test suite in Django is a collection of all the test cases in all the apps in your project. To make it possible for the Django testing utility to discover the test cases you have, you write the test cases in scripts whose names begin with test. In this step, you’ll create the directory structure and files for your test suite, and create an empty test case in it.

      If you followed the Django Development tutorial series, you’ll have a Django app called blogsite.

      Let’s create a folder to hold all our testing scripts. First, activate the virtual environment:

      • cd ~/my_blog_app
      • . env/bin/activate

      Then navigate to the blogsite app directory, the folder that contains the models.py and views.py files, and then create a new folder called tests:

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      Next, you’ll turn this folder into a Python package, so add an __init__.py file:

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      You’ll now add a file for testing your models and another for testing your views:

      • touch test_models.py
      • touch test_views.py

      Finally, you will create an empty test case in test_models.py. You will need to import the Django TestCase class and make it a super class of your own test case class. Later on, you will add methods to this test case to test the logic in your models. Open the file test_models.py:

      Now add the following code to the file:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      You’ve now successfully added a test suite to the blogsite app. Next, you will fill out the details of the empty model test case you created here.

      Step 2 — Testing Your Python Code

      In this step, you will test the logic of the code written in the models.py file. In particular, you will be testing the save method of the Post model to ensure it creates the correct slug of a post’s title when called.

      Let’s begin by looking at the code you already have in your models.py file for the save method of the Post model:

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      You’ll see the following:

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      We can see that it checks whether the post about to be saved has a slug value, and if not, calls slugify to create a slug value for it. This is the type of logic you might want to test to ensure that slugs are actually created when saving a post.

      Close the file.

      To test this, go back to test_models.py:

      Then update it to the following, adding in the highlighted portions:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      This new method test_post_has_slug creates a new post with the title "My first post" and then gives the post an author and saves the post. After this, using the assertEqual method from the Python unittest module, it checks whether the slug for the post is correct. The assertEqual method checks whether the two arguments passed to it are equal as determined by the "==" operator and raises an error if they are not.

      Save and exit test_models.py.

      This is an example of what can be tested. The more logic you add to your project, the more there is to test. If you add more logic to the save method or create new methods for the Post model, you would want to add more tests here. You can add them to the test_post_has_slug method or create new test methods, but their names must begin with test.

      You have successfully created a test case for the Post model where you asserted that slugs are correctly created after saving. In the next step, you will write a test case to test views.

      Step 3 — Using Django’s Test Client

      In this step, you will write a test case that tests a view using the Django test client. The test client is a Python class that acts as a dummy web browser, allowing you to test your views and interact with your Django application the same way a user would. You can access the test client by referring to self.client in your test methods. For example, let us create a test case in test_views.py. First, open the test_views.py file:

      Then add the following:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      The ViewsTestCase contains a test_index_loads_properly method that uses the Django test client to visit the index page of the website (http://your_server_ip:8000, where your_server_ip is the IP address of the server you are using). Then the test method checks whether the response has a status code of 200, which means the page responded without any errors. As a result you can be sure that when the user visits, it will respond without errors too.

      Apart from the status code, you can read about other properties of the test client response you can test in the Django Documentation Testing Responses page.

      In this step, you created a test case for testing that the view rendering the index page works without errors. There are now two test cases in your test suite. In the next step you will run them to see their results.

      Step 4 — Running Your Tests

      Now that you have finished building a suite of tests for the project, it is time to execute these tests and see their results. To run the tests, navigate to the blog folder (containing the application’s manage.py file):

      Then run them with:

      You’ll see output similar to the following in your terminal:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      In this output, there are two dots .., each of which represents a passed test case. Now you’ll modify test_views.py to trigger a failing test. First open the file with:

      Then change the highlighted code to:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Here you have changed the status code from 200 to 404. Now run the test again from your directory with manage.py:

      You’ll see the following output:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      You see that there is a descriptive failure message that tells you the script, test case, and method that failed. It also tells you the cause of the failure, the status code not being equal to 404 in this case, with the message AssertionError: 200 != 404. The AssertionError here is raised at the highlighted line of code in the test_views.py file:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      It tells you that the assertion is false, that is, the response status code (200) is not what was expected (404). Preceding the failure message, you can see that the two dots .. have now changed to .F, which tells you that the first test case passed while the second didn’t.

      Conclusion

      In this tutorial, you created a test suite in your Django project, added test cases to test model and view logic, learned how to run tests, and analyzed the test output. As a next step, you can create new test scripts for Python code not in models.py and views.py.

      Following are some articles that may prove helpful when building and testing websites with Django:

      You can also check out our Django topic page for further tutorials and projects.



      Source link