How To Configure a Linux Service to Start Automatically After a Crash or Reboot – Part 1: Practical Examples

Development

Đặng Tùng Lâm

3869

04-05-2023

Phần một bao gồm các khái niệm quản lý dịch vụ Linux chung như initdaemon and runlevels. Nó kết thúc với một bài thực hành về quản lý dịch vụ trong systemd. Ở đây, bạn sẽ xem xét targets , wants, requires, and unit files.

Phần hai cung cấp một hướng dẫn từng bước để hoàn thành một nhiệm vụ systemd thực tế và phổ biến. Cụ thể, bạn sẽ cấu hình một máy chủ cơ sở dữ liệu MySQL để tự động khởi động lại sau khi gặp sự cố hoặc khởi động lại.

Điều kiện cần

Để hoàn thành hướng dẫn này, bạn cần:

Một máy chủ chạy hệ điều hành CentOS 8, bao gồm một người dùng không phải root với đặc quyền sudo. Để thiết lập tất cả các thành phần này, bao gồm cả tường lửa, bạn có thể tạo một Bizfly Cloud Server chạy CentOS 8.

Giới thiệu về dịch vụ quản trị daemon

Các dịch vụ Linux có thể thực hiện tự động phát hiện và khắc phục lỗi phần lớn bằng cách thay đổi cách chúng được xử lý bởi daemon quản lý dịch vụ, còn được gọi là initdaemon

init là quá trình đầu tiên bắt đầu trong một hệ thống Linux sau khi máy khởi động và kernel được tải vào bộ nhớ. Ngoài ra, nó quyết định cách một quá trình người dùng hoặc dịch vụ được tải hệ thống, theo thứ tự nào và liệu nó có nên khởi động tự động.

Khi Linux phát triển, hành vi của initdaemon cũng thay đổi. Ban đầu, Linux bắt đầu với System V init, giống như được sử dụng trong Unix. Kể từ đó, Linux đã triển khai initdaemon Upstart (tạo bởi Ubuntu), và hiện tại là systemd initdaemon(được triển khai đầu tiên bởi Fedora).

Hầu hết các bản phân phối Linux hiện đại đã loại bỏ System V và hiện đang sử dụng systemd. init kiểu cũ (nếu được sử dụng) chỉ được giữ lại cho tính tương thích ngược. FreeBSD, một biến thể của UNIX, sử dụng một phiên bản khác của System V, được biết đến là BSD init.

Trong bài viết này, chúng ta sẽ bàn về systemd vì đây là trình quản lý dịch vụ mới nhất và phổ biến nhất được sử dụng trong các bản phân phối Linux hiện nay. Tuy nhiên, chúng ta cũng sẽ nói về System V và Upstart khi cần thiết và xem systemd đã phát triển từ đó. Để cho bạn một ví dụ:

System V là hệ thống init lâu đời nhất ,được sử dụng trong

Debian 6 và thấp hơn

Ubuntu 9.04 và thấp hơn

CentOS 5 và thấp hơn

Sau System V là Upstart được sử dụng trong:

Ubuntu từ phiên bản 9.10 đến 14.10, bao gồm Ubuntu 14.04

CentOS 6

systemd là trình quản lý dịch vụ Linux mới nhất, được sử dụng trong:

Debian 7 và cao hơn

Ubuntu 15.04 và cao hơn

CentOS 7 và cao hơn

Để hiểu về init daemon, hãy bắt đầu với một thứ được gọi là runlevel.

Runlevels

Một runlevel đại diện cho trạng thái hiện tại của một hệ thống Linux. Ví dụ, một runlevel có thể là trạng thái tắt máy của một máy chủ Linux, chế độ người dùng đơn, chế độ khởi động lại, vv. Mỗi chế độ sẽ quy định những dịch vụ nào có thể chạy trong trạng thái đó.

Một số dịch vụ có thể chạy ở một hoặc nhiều runlevel nhưng không phải ở các runlevel khác. Runlevel được đánh dấu bằng một giá trị từ 0 đến 6. Danh sách sau đây cho thấy ý nghĩa của mỗi cấp độ này:

Runlevel 0: Tắt hệ thống

Runlevel 1: Chế độ đơn người dùng, cứu hộ

Runlevels 2, 3, 4: Chế độ văn bản đa người dùng với mạng được kích hoạt

Runlevel 5: Chế độ đồ họa đa người dùng, được kích hoạt mạng

Runlevel 6: Khởi động lại hệ thống

Runlevels 2, 3, và 4 khác nhau trên các bản phân phối Linux. Ví dụ, một số bản phân phối Linux không thực hiện runlevel 4, trong khi những bản khác thì có. Một số bản phân phối có sự phân biệt rõ ràng giữa ba cấp độ này. Nói chung, runlevel 2, 3 hoặc 4 có nghĩa là trạng thái mà Linux đã khởi động ở chế độ đa người dùng, kết nối mạng và chế độ văn bản.

Khi bạn cho phép một dịch vụ tự động khởi động, Linux thực sự đang thêm mình vào một runlevel. Ví dụ, trong System V, hệ điều hành sẽ khởi động với một runlevel cụ thể; và, khi nó khởi động, nó sẽ cố gắng khởi động tất cả các dịch vụ liên quan đến runlevel đó. Trong systemd, runlevel đã trở thành mục tiêu, và khi một dịch vụ được đặt cho tự động khởi động, nó được thêm vào một mục tiêu. Chúng ta sẽ thảo luận về các mục tiêu sau trong bài viết này.

Giới thiệu về System V init Daemon

Trong hệ thống Linux sử dụng System V, tiến trình init được sử dụng để khởi động hệ thống. Để hoạt động, nó sử dụng một file cấu hình gọi là /etc/inittab, mà sau đó các phương pháp khác của init đã tiếp tục giữ lại để tương thích ngược. Chuỗi khởi động của System V có các bước sau:

1. Tiến trình init được tạo ra từ file nhị phân /sbin/init

2. Tiến trình init đọc tệp /etc/inittab để xác định runlevel hệ thống cần khởi động vào. Ví dụ, nếu giá trị runlevel được chỉ định là 3, Linux sẽ khởi động ở chế độ đa người dùng, chế độ văn bản với mạng được kích hoạt. (Runlevel này được biết đến là runlevel mặc định)

3. Tiến trình init đọc tệp /etc/inittab để xác định các tập lệnh init cần chạy để khởi động các dịch vụ.

4. Tiến trình init chạy các tập lệnh init được tìm thấy trong thư mục /etc/init.d để khởi động các dịch vụ cụ thể. Các tập lệnh init này được cung cấp bởi nhà cung cấp ứng dụng hoặc đi kèm với bản phân phối Linux.

Vì vậy, khi init daemon tìm thấy những tập lệnh init mà nó cần chạy cho runlevel được chỉ định, nó thực sự đang tìm hiểu những dịch vụ nào cần khởi động. Những tập lệnh init này là nơi bạn có thể cấu hình hành vi khởi động cho các dịch vụ riêng lẻ.

Một tệp lệnh init trong System V được sử dụng để điều khiển một dịch vụ cụ thể. Các tệp lệnh init cho các dịch vụ được cung cấp bởi nhà cung cấp ứng dụng hoặc đi kèm với bản phân phối Linux (cho các dịch vụ cơ bản). Bạn cũng có thể tạo tệp lệnh init riêng cho một dịch vụ được tạo ra theo các yêu cầu tùy chỉnh.

Khi một quy trình hoặc dịch vụ như MySQL Server bắt đầu trong System V, file chương trình nhị phân của nó phải được tải vào bộ nhớ. Tùy thuộc vào cách dịch vụ được cấu hình, chương trình này có thể tiếp tục thực thi ở nền (và chấp nhận kết nối khách hàng). Việc khởi động, dừng hoặc tải lại ứng dụng nhị phân này được xử lý bởi tập lệnh init của dịch vụ. Nó được gọi là tập lệnh init vì nó khởi tạo dịch vụ.

Trong System V, một tập lệnh init là một tập lệnh shell. Chúng cũng được gọi là tập lệnh rc (chạy lệnh). Các tập lệnh được đặt tại thư mục /etc/init.d. Những tập lệnh này được tạo liên kết tượng trưng đến các thư mục /etc/rc. Trong thư mục /etc, có một số thư mục rc khác nhau, mỗi thư mục có một số trong tên của nó. Các số đại diện cho các runlevel khác nhau. Vì vậy chúng ta có/etc/rc0.d, /etc/rc1.d , /etc/rc2.d và cứ tiếp tục như vậy.

Để một dịch vụ khởi động lại sau khi bị sự cố hoặc khởi động lại, bạn thường có thể thêm một dòng như sau vào tập lệnh init:

Để bật một dịch vụ System V khi khởi động hệ thống, chạy lệnh sau:

Để tắt nó, chạy lệnh sau:

Để kiểm tra trạng thái (đang chạy hay dừng), chạy lệnh sau:

Giới thiệu về Upstart Daemon

Với System V init, cách tải các công việc và dịch vụ theo cách chuỗi đã trở nên tốn thời gian hơn và phức tạp hơn, Upstart daemon đã được giới thiệu để tải hệ điều hành nhanh hơn, dọn dẹp dịch vụ bị sập một cách dễ dàng và đảm bảo sự phụ thuộc giữa các dịch vụ hệ thống.

Upstart init tốt hơn System V init ở một số điểm sau đây:

• Nó không giao tiếp với các tập lệnh shell khó hiểu để tải và quản lý dịch vụ. Thay vào đó, nó sử dụng các tệp cấu hình đơn giản dễ hiểu và dễ chỉnh sửa.
• Dịch vụ không được tải theo cách chuỗi như trong System V, giảm thời gian khởi động hệ thống.
• Nó sử dụng một hệ thống sự kiện linh hoạt để tùy chỉnh cách dịch vụ được xử lý trong các trạng thái khác nhau.
• Upstart có cách xử lý tốt hơn để dịch vụ bị sập phải khởi động lại.
• Không cần phải giữ một số liên kết tượng trưng dư thừa, tất cả đều trỏ vào cùng một tập lệnh.

Để giữ mọi thứ đơn giản, Upstart tương thích ngược với System V. Tập lệnh /etc/init.d/rc vẫn chạy để quản lý dịch vụ System V nguyên bản. Sự khác biệt chính của nó là cách cho phép kết nối nhiều sự kiện với một dịch vụ. Kiến trúc dựa trên sự kiện này cho phép Upstart trở thành một trình quản lý dịch vụ linh hoạt. Với Upstart, mỗi sự kiện có thể kích hoạt một tập lệnh shell để xử lý sự kiện đó. Những sự kiện này bao gồm:

• Starting(Bắt đầu)
• Started(Đã bắt đầu)
• Stopping(Dừng)
• Stopped(Đã dừng)

Giữa các sự kiện này, một dịch vụ có thể ở trong nhiều trạng thái khác nhau, như trạng thái chờ, trước khi bắt đầu, bắt đầu, đang chạy, trước khi dừng, đang dừng vv. Upstart có thể thực hiện các hành động cho mỗi trạng thái này, tạo ra một kiến trúc rất linh hoạt.

Trong quá trình khởi động, Upstart sẽ chạy tất cả các tệp lệnh System V init theo cách thông thường. Sau đó, nó sẽ tìm kiếm trong thư mục /etc/initvà thực thi các lệnh shell trong mỗi tệp cấu hình dịch vụ. Ngoài ra, những tệp này đã kiểm soát hành vi khởi động của dịch vụ.

Các tệp có một kiểu đặt tên là service_name.confvà chứa nội dung văn bản thuần túy với các phần khác nhau được gọi là stanza. Mỗi stanza mô tả một khía cạnh khác nhau của dịch vụ và cách nó nên hoạt động. Để đảm bảo rằng một dịch vụ sẽ tự động khởi động lại sau khi bị sập hoặc khởi động lại, bạn có thể thêm lệnh respawn trong các tệp cấu hình dịch vụ của nó, như được hiển thị dưới đây cho dịch vụ cron.

Giới thiệu về systemd Daemon

Các init daemon mới nhất của Linux là systemd. Thực tế, nó không chỉ là một init daemon: systemd là một khung xung quanh nhiều thành phần của một hệ thống Linux hiện đại.

Một trong các chức năng của nó là hoạt động như một trình quản lý hệ thống và dịch vụ cho Linux. Trong khả năng này, systemd điều khiển cách dịch vụ nên hoạt động nếu nó bị sập hoặc máy tính khởi động lại.

systemd tương thích ngược với các lệnh và tập lệnh System V. Điều đó có nghĩa là bất kỳ dịch vụ System V nào cũng sẽ chạy dưới systemd. Điều này là có thể vì hầu hết các lệnh quản trị Upstart và System V đã được sửa đổi để hoạt động dưới systemd.

Các tệp cấu hình systemd: Unit Files

Ở trung tâm của systemd là các unit file Mỗi unit file đại diện cho một tài nguyên hệ thống cụ thể. Thông tin về tài nguyên được theo dõi trong tệp đơn vị. Dịch vụ unit file là các tệp văn bản đơn giản (giống như các tệp .conf của Upstart) với cú pháp tường minh. Điều này làm cho các tệp dễ hiểu và chỉnh sửa.

Sự khác biệt chính giữa systemd và hai phương pháp init khác là systemd chịu trách nhiệm cho việc khởi động các daemon dịch vụ và các loại nguồn tài nguyên khác như đường dẫn hệ thống hoạt động của thiết bị, điểm gắn kết, socket, vv. Kiểu đặt tên cho một tệp đơn vị là service_name.unit_type.Vì vậy, bạn sẽ thấy các tệp như dbus.service, sshd.socket, hoặc home.mount.

Cấu trúc Thư mục

Trong các hệ thống dựa trên Red Hat như CentOS, các unit file được đặt tại hai nơi. Vị trí chính là /lib/systemd/system/. Các unit file được tạo ra tùy chỉnh hoặc các unit file hiện có được sửa đổi bởi các quản trị viên hệ thống sẽ sống dưới /etc/systemd/system.

Nếu có một tệp đơn vị cùng tên tồn tại ở cả hai vị trí, systemd sẽ sử dụng tệp đó trong /etc. Giả sử một dịch vụ được kích hoạt để bắt đầu khi khởi động hoặc bất kỳ mục tiêu / runlevel nào khác. Trong trường hợp đó, sẽ tạo ra một liên kết tượng trưng cho unit file dịch vụ đó trong các thư mục phù hợp trong/etc/systemd/system. Các unit file trong /etc/systemd/system thực chất là các liên kết tượng trưng cho các tệp cùng tên trong /lib/systemd/system.

Chuỗi systemd init: Target Units

Một loại unit file đặc biệt là target unit.

Một target unit được đặt tên theo hậu tố .target. Các target unit khác với các unit file khác vì chúng không đại diện cho một tài nguyên cụ thể nào. Thay vào đó, chúng đại diện cho trạng thái của hệ thống tại bất kỳ thời điểm nào. Target units làm điều này bằng cách nhóm và khởi chạy nhiều unit files mà nên là một phần của trạng thái đó. Các targets của systemd do đó có thể so sánh lỏng lẻo với các runlevel của System V, tuy nhiên chúng không giống nhau.

Mỗi target có một tên thay vì một số. Ví dụ, chúng ta có multi-user.target thay vì runlevel 3 hoặc reboot.target thay vì runlevel 6. Khi một máy chủ Linux khởi động với multi-user.target, nó về cơ bản đang đưa máy chủ đến runlevel 2, 3, hoặc 4, đó là chế độ văn bản nhiều người dùng với mạng được kích hoạt.

Cách mà nó đưa máy chủ lên tới giai đoạn đó chính là điểm khác biệt. Không giống như System V, systemd không khởi động các dịch vụ theo thứ tự. Trên đường đi, nó có thể kiểm tra sự tồn tại của các dịch vụ hoặc tài nguyên khác và quyết định thứ tự tải chúng. Điều này làm cho việc tải các dịch vụ cùng lúc trở nên có thể.

Một sự khác biệt khác giữa các target unit và các runlevel là trong System V, một hệ thống Linux có thể tồn tại trong chỉ một runlevel. Bạn có thể thay đổi runlevel, nhưng hệ thống sẽ tồn tại trong runlevel mới đó. Với systemd, các target unit có thể bao gồm, điều đó có nghĩa là khi một target unit được kích hoạt, nó có thể đảm bảo các target unit khác được tải là một phần của nó.

Ví dụ, một hệ thống Linux khởi động với giao diện người dùng đồ họa sẽ có graphical.target được kích hoạt, điều này lại đảm bảo rằng multi-user.target được tải và kích hoạt tự động. Theo thuật ngữ System V, đó sẽ giống như đang có runlevel 3 và 5 được kích hoạt đồng thời.

Bảng dưới đây so sánh các runlevel và mục tiêu:

systemd default.target

systemd default.target tương đương với System V default runlevel.

Ở System V, default runlevel được định nghĩa trong một tệp gọi là inittab. Ở systemd, tệp đó được thay thế bằng default.target. target unit file mặc định nằm trong thư mục /etc/systemd/system. Nó là một liên kết tượng trưng cho một trong các tệp đơn vị mục tiêu trong thư mục /lib/systemd/system.

Khi bạn thay đổi target mặc định, bạn đang tạo lại liên kết tượng trưng đó và thay đổi runlevel của hệ thống.

Tệp inittab trong System V cũng chỉ định thư mục mà Linux sẽ thực thi các tập lệnh khởi động của nó: nó có thể là bất kỳ các thư mục rcn.d nào. Trong systemd, target unit file mặc định xác định các đơn vị tài nguyên sẽ được tải lên vào thời điểm khởi động.

Khi các unit được kích hoạt, chúng được kích hoạt tất cả song song hoặc tất cả tuần tự. Cách một đơn vị tài nguyên tải lên có thể phụ thuộc vào các đơn vị tài nguyên khác nó muốn hoặc yêu cầu.

Phụ thuộc vào systemd: Wants và Requires

systemd wants và requires điều khiển cách systemd giải quyết sự phụ thuộc giữa các dịch vụ daemon.

Như đã đề cập trước đó, Upstart đảm bảo tải các dịch vụ song song bằng cách sử dụng các tệp cấu hình. Trong System V, một dịch vụ có thể bắt đầu ở một runlevel cụ thể, nhưng nó cũng có thể được thiết lập để đợi cho đến khi một dịch vụ hoặc tài nguyên khác có sẵn. Tương tự, các dịch vụ systemd có thể được thiết lập để tải lên trong một hoặc nhiều mục tiêu, hoặc đợi cho đến khi một dịch vụ hoặc tài nguyên khác được kích hoạt.

Trong systemd, một đơn vị yêu cầu một đơn vị khác sẽ không khởi động cho đến khi đơn vị được yêu cầu được tải lên và kích hoạt. Nếu đơn vị được yêu cầu thất bại vì một lý do gì đó trong khi đơn vị đầu tiên đang hoạt động, đơn vị đầu tiên cũng sẽ dừng lại.

Điều này đảm bảo tính ổn định của hệ thống. Một dịch vụ yêu cầu một thư mục cụ thể phải được hiện có có thể được thiết lập để đợi cho đến khi điểm gắn kết được kích hoạt cho thư mục đó. Trong khi đó, một đơn vị muốn một đơn vị khác sẽ không áp đặt các hạn chế đó. Nó sẽ không dừng lại nếu đơn vị mong muốn dừng lại khi người gọi đang hoạt động. Một ví dụ về điều này là các dịch vụ không thiết yếu xuất hiện trong chế độ đích đến đồ họa.

Ví dụ thực tế: Hiểu chuỗi khởi động systemd

Để hiểu cách khởi động dịch vụ trong systemd, chúng ta sử dụng một CentOS 8.3 Droplet. Chúng ta sẽ theo dõi chuỗi .target càng xa càng tốt. Chuỗi khởi động của systemd theo sau một chuỗi phụ thuộc dài.

Trước tiên, hãy chạy lệnh này để liệt kê target unit files mặc định:

Điều này sẽ hiển thị kết quả như sau:

Như bạn có thể thấy, target mặc định là một liên kết tượng trưng đến tệp mục tiêu đa người dùng trong /lib/systemd/system/. Vì vậy, hệ thống được giả định khởi động dưới multi-user.target, tương tự như runlevel 3 trong System V init.

multi-user.target.wants

Đầu tiên, chúng ta sẽ chạy lệnh sau để kiểm tra tất cả các dịch vụ tập tin multi-user.target muốn:

Điều này sẽ hiển thị một danh sách các tập tin liên kết tượng trưng, trỏ lại các tập tin đơn vị thực tế trong /usr/lib/systemd/system/:

Ngoài multi-user.target, còn có các loại mục tiêu khác như system-update.target hoặc basic.target. Để xem multi-user target phụ thuộc vào các mục tiêu nào, chạy lệnh sau:

Kết quả hiển thị:

Bạn có thể chạy lệnh sau để xem xem có bất kỳ đơn vị cần thiết cho basic.target không:

Như nó quay ra, basic.target yêu cầu sysinit.target:

Và wants một vài target:

Lệnh sẽ trả về như sau:

Đi sâu vào, bạn có thể xem xem sysinit.target có yêu cầu bất kỳ mục tiêu khác nào khác đang chạy không:

Sẽ không có. Tuy nhiên, sysinit.target sẽ muốn các mục tiêu khác:

Một đầu ra như thế này sẽ xuất hiện:

Kiểm tra một systemd Unit File

Đi một bước xa hơn, giờ hãy xem vào tệp đơn vị dịch vụ, tệp cho sshd:

Nó có dạng như sau:

Bạn có thể thấy tệp đơn vị dịch vụ là sạch và dễ hiểu.

Phần quan trọng đầu tiên là mệnh đề After trong phần [Unit]. Điều này cho biết dịch vụ sshd cần phải được tải sau khi các mục tiêu network.target và sshd-keygen.target đã được tải.

Phần [Install] cho thấy dịch vụ được yêu cầu bởi multi-user.target. Điều này có nghĩa là multi-user.target sẽ tải demon sshd, nhưng nó sẽ không tắt hoặc bị sập nếu sshd gặp sự cố trong quá trình tải.

Vì multi-user.target là target mặc định, demon sshd được cho là sẽ khởi động khi khởi động hệ thống. Trong phần [Service], tham số Restart có giá trị on-failure. Cài đặt này cho phép demon sshd khởi động lại nếu gặp sự cố hoặc thoát không đúng cách.

Kết luận

Trong bài viết này, bạn đã tìm hiểu về các daemon quản lý dịch vụ System V, Upstart và systemd. Bạn đã khám phá các tập lệnh khởi động và các tệp cấu hình, các tham số quan trọng, thứ tự khởi động và các lệnh điều khiển hành vi khởi động dịch vụ.

Trong phần hai của bài viết này, chúng ta sẽ áp dụng những kỹ năng này vào một ví dụ thực tế và sử dụng systemd để cấu hình MySQL. Sau khi hoàn thành, phiên bản MySQL của bạn sẽ tự động khởi động lại sau khi khởi động lại hoặc sự cố. Và mặc dù bạn sẽ sử dụng MySQL làm ứng dụng ví dụ của mình, bạn có thể thay thế bằng bất kỳ số dịch vụ nào, chẳng hạn như các máy chủ web Nginx hoặc Apache.

>> Phần 2: How To Configure a Linux Service to Start Automatically After a Crash or Reboot – Part 2: Reference