HƯỚNG DẪN Understanding Systemd Units and Unit Files

Thảo luận trong 'KIẾN THỨC SERVER' bắt đầu bởi quyet1990, 16/2/17.

  1. quyet1990

    quyet1990 New Member

    220
    16
    0
    Giới thiệu
    Càng ngày, các bản phân phối Linux đang áp dụng hoặc có kế hoạch áp dụng hệ thống systemd init. Đây là bộ phần mềm mạnh mẽ có thể quản lý nhiều khía cạnh của máy chủ của bạn, từ các dịch vụ cho các thiết bị gắn kết và cả các dịch vụ hệ thống.
    Trong systemd, một unit dùng để chỉ bất kỳ tài nguyên giúp hệ thống biết cách làm thế nào để hoạt động và quản lý. Đây là đối tượng chính mà các công cụ systemd biết làm thế nào để xử lý. Các nguồn tài nguyên được xác định qua các tập tin cấu hình gọi là unit files.
    Trong hướng dẫn này, chúng tôi sẽ giới thiệu bạn với các đơn vị khác nhau mà systemd có thể xử lý. Chúng tôi cũng sẽ bao gồm một số rất nhiều chỉ thị có thể được sử dụng trong các tập tin unit để định hình cách thức các nguồn lực được xử lý trên hệ thống của bạn.

    Systemd unit mang lại cho bạn những gì?
    Units là các đối tượng mà systemd biết làm thế nào để quản lý. Đây là những điều cơ bản và đại diện tiêu chuẩn hóa cho các tài nguyên hệ thống có thể được quản lý bởi daemon và thao túng bởi các tiện ích được cung cấp.

    Các đơn vị trong một số cách có thể nói là tương tự như dịch vụ hoặc công việc trong hệ thống init khác. Tuy nhiên, một đơn vị có thể định nghĩa rộng hơn nhiều, vì chúng có thể được sử dụng cho các abstract services, tài nguyên mạng, các thiết bị, gắn kết hệ thống tập tin, và tài nguyên pool bị cô lập.

    Một số tính năng mà các đơn vị có thể thực hiện một cách dễ dàng là:
    • socket-based activation: Socket gắn liền với một dịch vụ được chia ra tốt nhất của bản thân các daemon để có thể được xử lý riêng biệt. Điều này cung cấp một số lợi thế, chẳng hạn như trì hoãn sự khởi đầu của một dịch vụ cho đến khi socket liên kết là lần đầu tiên truy cập. Điều này cũng cho phép hệ thống để tạo ra tất cả các socket đầu tiên trong quá trình khởi động, làm cho nó có thể khởi động các dịch vụ liên quan đến song song.
    • bus-based activation: Các đơn vị cũng có thể được kích hoạt trên giao diện bus được cung cấp bởi D-Bus. Một đơn vị có thể được bắt đầu khi một bus liên quan được công bố
    • path-based activation: Một đơn vị có thể được bắt đầu dựa trên hoạt động hoặc sự sẵn có của đường dẫn hệ thống tập tin nhất định.
    • device-based activation: Các đơn vị cũng có thể được bắt đầu vào sự sẵn có đầu tiên của phần cứng liên quan bằng cách tận dụng sự kiện udev.
    • implicit dependency mapping : Hầu hết các cây phụ thuộc cho các đơn vị có thể được xây dựng bởi bản thân systemd. Bạn vẫn có thể thêm phụ thuộc và thông tin yêu cầu, nhưng hầu hết các vấn đề nâng cao systemd sẽ xử lý cho bạn.
    • instances and templates: các tập tin đơn vị mẫu có thể được sử dụng để tạo ra nhiều trường hợp của các đơn vị nói chung. Điều này cho phép cho các biến thể nhẹ hoặc đơn vị, tất cả chúng đều được cung cấp các chức năng chung.
    • easy security hardening: đơn vị có thể thực hiện một số tính năng bảo mật khá tốt bằng cách thêm các chỉ thị đơn giản Ví dụ, bạn có thể chỉ định không có hoặc chỉ đọc truy cập vào một phần của hệ thống tập tin, khả năng giới hạn hạt nhân, và chỉ định thư mục riêng /tmp và truy cập mạng.
    • drop-ins and snippets: Các đơn vị có thể dễ dàng được mở rộng bằng cách cung cấp các đoạn mà sẽ ghi đè lên các bộ phận của tập tin đơn vị của hệ thống. Điều này làm cho nó dễ dàng để chuyển đổi giữa nguyên gốc và đơn vị triển khai tùy chỉnh.
    Systemd Unit Files được tìn thấy ở đâu?
    Các tập tin xác định cách mà systemd sẽ xử lý một đơn vị có thể được tìm thấy ở nhiều địa điểm khác nhau, mỗi trong số đó có những ưu tiên và những tác động khác nhau.
    Bản sao của hệ thống các tập tin đơn vị thường được lưu giữ trong thư mục /lib/systemd/system. Khi phần mềm cài đặt tập tin đơn vị trên hệ thống, đây là vị trí nơi họ được đặt theo mặc định.

    Các tập tin đơn vị lưu trữ ở đây có thể được bắt đầu và dừng lại theo yêu cầu trong một phiên. Tập tin nguyên gốc thường được viết bởi upstream project's maintainers mà nên làm việc trên bất kỳ hệ thống triển khai systemd trong tiêu chuẩn của nó. Bạn không nên chỉnh sửa các tập tin trong thư mục này. Thay vào đó bạn nên ghi đè lên các tập tin, nếu cần thiết, sử dụng một vị trí tập tin đơn vị này sẽ thay thế các tập tin ở vị trí này.

    Nếu bạn muốn thay đổi cách mà một đơn vị chức năng, vị trí tốt nhất để làm điều đó là trong thư mục /etc/systemd/system/. Đơn vị file được tìm thấy ở vị trí thư mục này được ưu tiên hơn bất kỳ địa điểm khác trên hệ thống tập tin. Nếu bạn cần phải sửa đổi bản sao của hệ thống về một tập tin đơn vị, đặt một thay thế trong thư mục này là cách an toàn nhất và linh hoạt nhất để làm điều này.
    Nếu bạn muốn ghi đè lên các chỉ thị cụ thể từ các tập tin đơn vị của hệ thống, bạn thực sự có thể cung cấp các đoạn tập tin đơn vị trong một thư mục con. Điều này sẽ nối thêm hoặc sửa đổi các chỉ thị của bản sao của hệ thống, cho phép bạn xác định các tùy chọn bạn muốn thay đổi.

    Cách chính xác để làm điều này là tạo ra một thư mục có tên sau tập tin đơn vị với .d nối vào cuối. Vì vậy, đối với một đơn vị gọi là example.service, một thư mục con gọi là example.service.d có thể được tạo ra. Trong thư mục này một tập tin kết thúc với .conf có thể được sử dụng để ghi đè hoặc mở rộng các thuộc tính của tập tin đơn vị của hệ thống.

    Ngoài ra còn có một vị trí cho định nghĩa đơn vị run-time ở /run/systemd/system. Đơn vị các file tìm thấy trong thư mục này có một đích ưu tiên giữa những người trong /etc/systemd/system and /lib/systemd/system. Tập tin ở vị trí này được cho trọng số ít hơn so với vị trí cũ, nhưng trọng lượng hơn sau này.
    Quá trình systemd sử dụng địa điểm này cho các tập tin đơn vị tự động tạo ra khi chạy. Thư mục này có thể được sử dụng để thay đổi hành vi đơn vị của hệ thống trong suốt thời gian của phiên giao dịch. Tất cả những thay đổi trong thư mục này sẽ bị mất khi máy chủ được khởi động lại.
    Các loại đơn vị (unit)
    Các đơn vị của Systemd dựa trên loại tài nguyên mà chúng mô tả. Cách dễ nhất để xác định loại của một đơn vị là với loại hậu tố của nó, được nối vào cuối của tên tài nguyên. Danh sách sau đây mô tả các loại của các đơn vị có sẵn của systemd:
    • .service: Một đơn vị dịch vụ mô tả làm thế nào để quản lý các dịch vụ hoặc ứng dụng trên máy chủ. Điều này sẽ bao gồm làm thế nào để bắt đầu hoặc dừng dịch vụ, theo đó trường hợp nó sẽ tự động bắt đầu, và sự phụ thuộc và thông tin yêu cầu cho các phần mềm liên quan.
    • .socket: Một tập tin đơn vị socket mô tả một mạng hoặc socket IPC, hoặc một bộ đệm FIFO rằng systemd sử dụng để kích hoạt socket. Lúc nào cũng có một file .service liên quan sẽ được bắt đầu khi hoạt động được nhìn thấy trên các socket mà đơn vị này xác định.
    • .device: Một đơn vị mô tả một thiết bị đã được chỉ định là cần quản lý systemd bởi udev hoặc hệ thống tập tin sysfs. Không phải tất cả các thiết bị sẽ có tập tin .device. Một số kịch bản mà .device có thể cần thiết được cho yêu cầu, gắn kết, và truy cập vào thiết bị.
    • .mount: Đơn vị này xác định điểm gắn kết trên hệ thống được quản lý bởi systemd. Chúng được đặt tên theo con đường gắn kết, với dấu gạch chéo thay đổi đến dấu gạch ngang. Mục trong /etc/fstab có thể có những đơn vị tạo ra tự động.
    • .automount: Một đơn vị .automount cấu hình điểm gắn kết sẽ được tự động gắn kết. Đây phải được đặt tên sau khi các điểm gắn kết mà họ hướng tới và phải có một đơn vị trùng .mount để xác định các chi tiết cụ thể của sự gắn kết.
    • .swap: đơn vị này mô tả không gian swap trên hệ thống. Tên của đơn vị này phải phản ánh các thiết bị hoặc đường dẫn tập tin của không gian.
    • .target: Một đơn vị target được sử dụng để cung cấp các điểm đồng bộ cho các đơn vị khác khi khởi động hoặc thay đổi trạng thái. Chúng cũng có thể được sử dụng để mang lại hệ thống về trạng thái mới.
    • .path: Đơn vị này xác định một đường dẫn mà có thể được sử dụng cho path-based activation. Theo mặc định, một đơn vị .service của tên cơ sở tương tự sẽ được bắt đầu khi con đường đạt đến trạng thái nhất định. Điều này sẽ sử dụng inotify giám sát các đường dẫn cho sự thay đổi.
    • .timer: Một đơn vị .timer định nghĩa một bộ đếm thời gian sẽ được quản lý bởi systemd, tương tự như một công việc định kỳ để kích hoạt chậm hoặc theo lịch trình. Một đơn vị trùng khớp sẽ được bắt đầu khi bộ đếm thời gian đạt đủ điều kiện.
    • .snapshot: Một đơn vị .snapshot được tạo ra tự động bởi lệnh systemctl snapshot . Nó cho phép bạn tái tạo lại trạng thái hiện tại của hệ thống sau khi thực hiện thay đổi. Snapshots không tồn tại trên phiên và được sử dụng để quay trở lại trạng thái tạm thời.
    • .slice: Một đơn vị .slice được liên kết với Linux Control Group nodes, cho phép nguồn tài nguyên có thể bị hạn chế hoặc chỉ định cho bất kỳ quá trình liên kết với các slice. Tên đơn vị này phản ánh vị trí thứ bậc của nó trong cây cgroup. Các đơn vị được đặt trong slice nhất định theo mặc định tùy thuộc vào kiểu của chúng.
    • .scope: đơn vị .scope được tạo ra tự động bởi systemd từ các thông tin nhận được từ giao diện bus của nó. Chúng được sử dụng để quản lý các tập quy trình hệ thống được tạo ra bên ngoài.
    Như bạn có thể thấy, có rất nhiều đơn vị khác nhau mà systemd biết làm thế nào để quản lý. Nhiều trong số các loại đơn vị làm việc với nhau để thêm chức năng. Ví dụ, một số đơn vị được sử dụng để kích hoạt các đơn vị khác và cung cấp chức năng kích hoạt.
    Chúng tôi chủ yếu sẽ tập trung vào các đơn vị .service do công năng sử dụng và tính nhất quán mà các nhà quản trị cần phải hiểu biết khi quản lý các đơn vị này.
    Cấu trúc của một tập tin đơn vị
    Cơ cấu nội bộ các tập tin đơn vị được tổ chức với các section. section được biểu thị bằng một cặp dấu ngoặc vuông "[" và "]" với section name ở bên trong. Mỗi section mở rộng cho đến khi bắt đầu của section tiếp theo hoặc cho đến khi kết thúc của tập tin.

    Đặc điểm chung của các đơn vị tập tin
    Section name được xác định rõ trong trường hợp phân biệt hoa thường. Vì vậy, phần [Unit] sẽ không được giải thích một cách chính xác nếu nó được viết như [UNIT]. Nếu bạn cần thêm các phần phi tiêu chuẩn để được phân tích bởi các ứng dụng khác hơn systemd, bạn có thể thêm một tiền tố X tới section name.
    Trong các bộ phận, đơn vị hành vi và siêu dữ liệu được xác định thông qua việc sử dụng các chỉ thị đơn giản sử dụng một định dạng key-value chỉ bằng một dấu bằng, như thế này:
    Mã:
    [Section]
    Directive1=value
    Directive2=value
    . . .
    
    Trong trường hợp của một tập tin ghi đè (chẳng hạn như trong một thư mục unit.type.d), chỉ có thể được thiết lập lại bằng cách gán cho họ một chuỗi rỗng. Ví dụ, hệ thống bản sao của một tập tin đơn vị có thể chứa một chỉ thiết lập một giá trị như thế này:
    Mã:
    Directive1=default_value
    
    Các DEFAULT_VALUE có thể được loại bỏ trong một tập tin ghi đè bằng cách tham chiếu Directive1 mà không có một giá trị, như thế này:
    Mã:
    Directive1=
    
    Nói chung, systemd cho phép cấu hình dễ dàng và linh hoạt. Ví dụ, nhiều biểu thức boolean được chấp nhận (1, yes, on, and true for affirmative and 0, no off, and false for the opposite answer). Thời gian có thể được phân tích một cách thông minh, với giây giả định cho giá trị đơn vị ít hơn và kết hợp nhiều định dạng hoàn thành trong nội bộ.

    [Unit] Section Directives
    Phần đầu tiên được tìm thấy trong hầu hết các tập tin đơn vị là phần [Unit]. Điều này thường được sử dụng để xác định siêu dữ liệu cho các đơn vị và cấu hình các mối quan hệ của các đơn vị đến các đơn vị khác.
    Mặc dù phần yêu cầu không quan trọng đối với systemd khi phân tích các tập tin, phần này thường được đặt ở đầu vì nó cung cấp một cái nhìn tổng quan của đơn vị. Một số chỉ thị phổ biến mà bạn sẽ tìm thấy trong phần [Unit] là:
    • Description=: Chỉ thị này có thể được sử dụng để mô tả tên và chức năng cơ bản của các đơn vị. Nó được trả về bởi các công cụ systemd khác nhau.
    • Documentation=: Chỉ thị này cung cấp một vị trí cho một danh sách các URI cho tài liệu. Đây có thể là một trong trang nội bộ có sẵn hoặc URL truy cập web. Lệnh systemctl status sẽ phơi bày thông tin này, cho phép dễ dàng khám phá hơn.
    • Requires=: Chỉ thị này liệt kê bất kỳ đơn vị mà đơn vị này chủ yếu phụ thuộc. Nếu đơn vị hiện tại được kích hoạt, các đơn vị được liệt kê ở đây phải kích hoạt thành công, nếu không đơn vị này sẽ thất bại. Các đơn vị này bắt đầu song song với các đơn vị hiện tại theo mặc định.
    • Wants=: Chỉ thị này cũng tương tự như Requires=, nhưng ít nghiêm ngặt hơn. Systemd sẽ cố gắng để bất kỳ đơn vị được liệt kê ở đây đều kích hoạt thành công khi đơn vị này được kích hoạt. Nếu các đơn vị này không tìm thấy hoặc không khởi động được, đơn vị hiện tại sẽ tiếp tục hoạt động.
    • BindsTo=: Chỉ thị này cũng tương tự như Requires=, các đơn vị hiện tại dừng lại khi các đơn vị liên quan chấm dứt.
    • Before=: Các đơn vị được liệt kê trong chỉ thị này sẽ không được bắt đầu cho đến khi đơn vị hiện tại được đánh dấu là bắt đầu nếu chúng được kích hoạt cùng một lúc.
    • After=: Các đơn vị được liệt kê trong chỉ thị này sẽ được bắt đầu trước khi bắt đầu các đơn vị hiện tại.
    • Conflicts=: Điều này có thể được sử dụng để liệt kê các đơn vị mà không thể chạy đồng thời là đơn vị hiện tại. Bắt đầu từ một đơn vị có mối quan hệ này sẽ gây ra các đơn vị khác để được dừng lại.
    • Condition...=: Có một số chỉ thị bắt đầu với Condition cho phép các quản trị viên để kiểm tra các điều kiện nhất định trước khi bắt đầu các đơn vị. Điều này có thể được sử dụng để cung cấp một tập tin đơn vị chung chung mà sẽ chỉ được chạy khi trên các hệ thống thích hợp. Nếu tình trạng này không được đáp ứng, các đơn vị được bỏ qua.
    • Assert...=: Tương tự như các chỉ thị bắt đầu bằng Condition, các chỉ thị kiểm tra các khía cạnh khác nhau của môi trường đang chạy để quyết định xem các đơn vị có nên kích hoạt.
    [Install] Section Directives
    Ở phía ngược lại của tập tin đơn vị, phần cuối cùng thường là phần [Install]. Phần này là tùy chọn và được sử dụng để xác định hành vi hoặc một đơn vị nếu nó được kích hoạt hoặc vô hiệu hóa. Cho phép một đơn vị đánh dấu nó sẽ được tự động bắt đầu lúc khởi động.
    Bởi vì điều này, chỉ có một số ít các đơn vị có thể được kích hoạt sẽ có phần này. Các chỉ thị mô tả những gì sẽ xảy ra khi các đơn vị được kích hoạt:
    • WantedBy=: Chỉ thị WantedBy= là cách phổ biến nhất để xác định làm thế nào một đơn vị cần được kích hoạt. Chỉ thị này cho phép bạn chỉ định một mối quan hệ phụ thuộc trong một cách tương tự tới chỉ thị WantedBy= làm gì trong phần [Unit]. Sự khác biệt là chỉ thị này được bao gồm trong các đơn vị phụ trợ cho phép các đơn vị chính được liệt kê vẫn tương đối rõ ràng. Khi một đơn vị có chỉ thị này được kích hoạt, một thư mục sẽ được tạo ra trong /etc/systemd/system đặt tên theo sự chỉ định với .wants gắn kết vào phía sau. Trong vòng này, một liên kết symbolic cho đơn vị hiện tại sẽ được tạo ra và tạo ra sự phụ thuộc.
    • RequiredBy=: Chỉ thị này là rất tương tự như chỉ thị WantedBy=, nhưng thay thế quy định cụ thể một phụ thuộc yêu cầu mà sẽ gây ra sự kích hoạt thất bại nếu không được đáp ứng. Khi được kích hoạt, một đơn vị có chỉ thị này sẽ tạo ra một thư mục kết thúc với .requires.
    • Alias=: Chỉ thị này cho phép các đơn vị được kích hoạt dưới một tên khác. Trong số các ứng dụng khác, điều này cho phép cung cấp các chức năng có sẵn, để các đơn vị có liên quan có thể tìm bất kỳ nhà cung cấp của tên aliased chung.
    • Also=: Chỉ thị này cho phép các đơn vị để được kích hoạt hay vô hiệu hóa như là một tập. Đơn vị đó phải luôn luôn có sẵn khi đơn vị này đang hoạt động có thể được liệt kê ở đây hỗ trợ. Họ sẽ được quản lý như một nhóm cho các nhiệm vụ lắp đặt.
    • DefaultInstance=: Đối với đơn vị mẫu (bảo hiểm sau này) mà có thể sản xuất các trường hợp đơn vị có tên không thể đoán trước, điều này có thể được sử dụng như một giá trị dự phòng cho tên nếu một tên thích hợp không được cung cấp.
    Unit-Specific Section Directives
    Ởgiữa hai phần trước, bạn có thể sẽ tìm đơn vị phần loại cụ thể (unit type-specific). Hầu hết các loại đơn vị cung cấp các chỉ thị mà chỉ áp dụng cho các loại hình cụ thể của họ.
    Các loại đơn vị thiết bị, mục tiêu, ảnh chụp, và phạm vi không có chỉ thị đơn vị cụ thể, và do đó không có phần liên quan cho loại hình của họ.

    Phần [Service]
    Phần [Service]
    được sử dụng để cung cấp cấu hình mà chỉ áp dụng cho các dịch vụ.
    Một trong những điều cơ bản đó phải được quy định trong phần [Service]Type= của dịch vụ. Điều này phân loại dịch vụ theo quy trình của họ và hành vi daemonizing. Điều này rất quan trọng vì nó cho systemd biết làm thế nào để quản lý một cách chính xác các servie và tìm hiểu trạng thái của nó.
    Chỉ thị Type= chỉ có thể là một trong những cách sau:
    • simple: Các quá trình chính của dịch vụ được quy định trong các dòng bắt đầu. Đây là mặc định nếu chỉ thị Type=Busname= không được thiết lập, nhưng ExecStart= được thiết lập. Bất kỳ thông tin liên lạc cần được xử lý bên ngoài của đơn vị thông qua một đơn vị thứ hai của loại thích hợp (giống như thông qua một đơn vị .socket nếu đơn vị này phải giao tiếp sử dụng socket).
    • forking: loại hình dịch vụ này được sử dụng khi các nhánh dịch vụ là một quá trình con, thoát ra quá trình cha mẹ gần như ngay lập tức. Điều này cho systemd biết rằng quá trình này vẫn chạy mặc dù cha mẹ đã thoát.
    • oneshot: loại này chỉ ra rằng quá trình này sẽ là ngắn ngủi và systemd biết rằng nên chờ cho quá trình này thoát ra trước khi tiếp tục với các đơn vị khác. Đây là Type=ExecStart= không được thiết lập. Nó được sử dụng cho các nhiệm vụ một lần.
    • dbus: Điều này chỉ ra rằng đơn vị sẽ có một tên trên bus D-Bus. Khi điều này xảy ra, systemd sẽ tiếp tục xử lý các đơn vị tiếp theo.
    • notify: Điều này chỉ ra rằng dịch vụ sẽ đưa ra thông báo khi nó đã hoàn tất khởi động. Quá trình systemd sẽ chờ đợi cho điều này xảy ra trước khi tiến hành cho các đơn vị khác.
    • idle: Điều này chỉ ra rằng dịch vụ sẽ không được chạy cho đến khi tất cả các công việc được gửi đi.
    Một số chỉ thị bổ sung có thể cần thiết khi sử dụng các loại dịch vụ nhất định. Ví dụ:
    • RemainAfterExit=: Chỉ thị này thường được sử dụng với các loại oneshot. Nó chỉ ra rằng các dịch vụ cần được xem xét hoạt động ngay sau khi thoát khỏi quá trình.
    • PIDFile=: Nếu các loại hình dịch vụ được đánh dấu là "forking", chỉ thị này được sử dụng để thiết lập đường dẫn của tập tin đó nên chứa số lượng quá trình ID của dịch vụ chính mà nên được theo dõi.
    • BusName=: Chỉ thị này nên được thiết lập tới D-Bus bus name, dịch vụ sẽ cố gắng để có được khi sử dụng kiểu dịch vụ "dbus".
    • NotifyAccess=: Điều này chỉ truy cập vào các socket được sử dụng để lắng nghe thông báo khi các "thông báo" loại hình dịch vụ được lựa chọn này có thể là "none", "main", hoặc "all". Theo mặc định,." none ", bỏ qua tất cả thông báo trạng thái. Tùy chọn "main" sẽ lắng nghe thông điệp từ quá trình chính và "all" sẽ tác động tất cả các thành viên của nhóm kiểm soát của dịch vụ để được xử lý.
    Cho đến nay, chúng tôi đã thảo luận về một số thông tin điều kiện tiên quyết, nhưng chúng tôi đã không thực sự được định nghĩa như thế nào để quản lý các dịch vụ của chúng tôi. Các chỉ thị để làm điều này là:
    • ExecStart=: Chỉ định đường dẫn đầy đủ và các đối số của lệnh được thực thi để bắt đầu quá trình. Điều này chỉ có thể được chỉ định một lần (trừ các dịch vụ "oneshot"). Nếu các đường dẫn đến các lệnh đi trước bởi một dấu gạch ngang "-", trạng thái thoát khác sẽ được chấp nhận mà không đánh dấu kích hoạt đơn vị bị thất bại.
    • ExecStartPre=: Điều này có thể được sử dụng để cung cấp các lệnh bổ sung cần được thực hiện trước khi quá trình chính được bắt đầu. Điều này có thể được sử dụng nhiều lần. Một lần nữa, lệnh phải chỉ định một đường dẫn đầy đủ và họ có thể được đi trước bởi "-" để chỉ ra rằng sự thất bại của lệnh sẽ được bỏ qua.
    • ExecStartPost=: Đây có chức năng chính xác giống như ExecStartPre= ngoại trừ nó chỉ định lệnh sẽ được chạy sau khi quá trình chính được bắt đầu.
    • ExecReload=: Chỉ thị tùy chọn này chỉ ra các lệnh cần thiết để tải lại cấu hình của dịch vụ nếu có.
    • ExecStop=: Điều này cho thấy các lệnh cần thiết để dừng dịch vụ. Nếu điều này không được đưa ra, quá trình này sẽ bị kết thúc ngay lập tức khi dịch vụ được dừng lại.
    • ExecStopPost=: Điều này có thể được sử dụng để xác định các lệnh thực hiện sau lệnh dừng.
    • RestartSec=: Nếu việc tự động khởi động lại các dịch vụ được kích hoạt, điều này quy định cụ thể số lượng thời gian chờ đợi trước khi cố gắng khởi động lại dịch vụ.
    • Restart=: Điều này cho thấy những trường hợp mà systemd sẽ cố gắng để tự động khởi động lại dịch vụ. Điều này có thể được thiết lập đến các giá trị như "always","on-success", "on-failure", "on-abnormal", "on-abort", hoặc "on-watchdog". Những điều này sẽ kích hoạt khi khởi động lại theo cách mà các dịch vụ đã được ngừng lại.
    • TimeoutSec=: Cấu hình số lượng thời gian mà systemd sẽ đợi khi dừng hoặc ngừng dịch vụ trước khi đánh dấu nó như là thất bại hoặc mạnh mẽ kết thúc chết nó. Bạn có thể thiết lập timeout riêng biệt với TimeoutStartSec=TimeoutStopSec=.
    Phần [Socket]
    Phần [Socket] là rất phổ biến trong các cấu hình systemd vì nhiều dịch vụ thực hiện kích hoạt trên socket để cung cấp song song tốt hơn và linh hoạt. Mỗi đơn vị socket phải có một đơn vị dịch vụ phù hợp sẽ được kích hoạt khi socket nhận hoạt động.
    Bằng cách phá vỡ sự kiểm soát socket ngoài của bản thân dịch vụ, socket có thể được khởi đầu và các dịch vụ liên quan thường có thể được bắt đầu song song. Theo mặc định, tên socket sẽ cố gắng để bắt đầu dịch vụ cùng tên khi nhận được một kết nối. Khi dịch vụ được khởi tạo, socket sẽ được truyền cho nó, cho phép nó bắt đầu xử lý các yêu cầu đệm.
    Để xác định các socket thực tế, các chỉ thị là phổ biến:
    • ListenStream=: Điều này xác định một địa chỉ cho một stream socket mà hỗ trợ liên tục, thông tin liên lạc đáng tin cậy. Dịch vụ sử dụng TCP nên sử dụng loại socket này.
    • ListenDatagram=: Điều này xác định một địa chỉ cho một datagram socket mà hỗ trợ nhanh, các gói tin truyền thông không đáng tin cậy. Dịch vụ sử dụng UDP nên đặt socket này.
    • ListenSequentialPacket=: Điều này xác định một địa chỉ liên tiếp, truyền thông đáng tin cậy với datagrams chiều dài tối đa ranh giới thông điệp. Điều này được tìm thấy thường xuyên nhất cho socket Unix.
    • ListenFIFO: Cùng với các loại khác, bạn cũng có thể chỉ định một bộ đệm FIFO thay vì một socket.
    Có nhiều loại chỉ thị lắng nghe, nhưng những cái trên là phổ biến nhất.
    Các đặc điểm khác của các socket có thể được kiểm soát thông qua các chỉ thị bổ sung:
    • Accept=: Điều này xác định liệu một ví dụ khác của các dịch vụ này sẽ được bắt đầu cho mỗi kết nối. Nếu thiết lập là false (mặc định), một instance sẽ xử lý tất cả các kết nối.
    • SocketUser=: Với một socket Unix, xác định chủ sở hữu của các socket. Đây sẽ là người sử dụng gốc nếu không thiết lập.
    • SocketGroup=: Với một socket Unix, xác định chủ sở hữu nhóm của socket. Đây sẽ là nhóm gốc nếu không là cái này hoặc các bên trên được thiết lập. Nếu chỉ SocketUser= được thiết lập, systemd sẽ cố gắng tìm một nhóm phù hợp.
    • SocketMode=: Đối với socket Unix hoặc bộ đệm FIFO, điều này đặt ra các điều khoản trên các thực thể được tạo ra.
    • Service=: Nếu tên dịch vụ không phù hợp với tên .socket, các dịch vụ có thể được chỉ định với các chỉ thị này.
    Phần [Mount]
    Đơn vị gắn kết cho phép quản lý điểm gắn kết từ bên trong systemd. Núi gắn kết được đặt theo tên của thư mục mà họ kiểm soát, với một thuật toán dịch được áp dụng.
    Ví dụ, các dấu gạch chéo hàng đầu được lấy ra, tất cả các dấu gạch chéo khác được dịch thành dấu gạch ngang "-", và tất cả các dấu gạch ngang và các kí tự chưa in được thay thế bằng C-style escape codes. Kết quả của bản dịch này được sử dụng như tên đơn vị gắn kết.

    Đơn vị gắn kết thường được dịch trực tiếp từ /etc/fstab trong quá trình khởi động. Đối với các định nghĩa đơn vị tự động tạo ra và những thứ mà bạn muốn xác định trong một tập tin đơn vị, các chỉ thị sau rất hữu ích:
    • What=: Đường dẫn tuyệt đối đến tài nguyên cần được gắn kết.
    • Where=: Đường dẫn tuyệt đối của các điểm gắn kết nơi có tài nguyên cần được gắn kết. Điều này nên được giống như tên tập tin đơn vị, ngoại trừ sử dụng ký hiệu hệ thống tập tin thông thường.
    • Type=: Các loại hệ thống tập tin của gắn kết..
    • Option=: Bất kỳ tùy chọn mà cần phải được áp dụng gắn kết. Đây là một danh sách bằng dấu phẩy.
    • SloppyOptions=: Một boolean xác định liệu các gắn kết sẽ thất bại nếu có một tùy chọn gắn kết không được công nhận.
    • DirectoryMode=: Nếu thư mục mẹ cần phải được tạo ra cho các điểm gắn kết, điều này xác định các chế độ cho phép của các thư mục này.
    • TimeoutSec=: Cấu hình số lượng thời gian hệ thống sẽ chờ đợi cho đến khi các hoạt động gắn kết được đánh dấu là đã thất bại.
    Phần [Automount]
    Đơn vị này cho phép một đơn vị .mount liên quan để được tự động gắn kết lúc khởi động. Như với các đơn vị .mount, các đơn vị này phải được đặt tên theo đường dẫn điểm gắn kết.
    Phần [automount] là khá đơn giản, chỉ với hai tùy chọn sau đây cho phép:
    • Where=: Đường dẫn tuyệt đối của điểm automount trên hệ thống tập tin. Điều này sẽ phù hợp với tên tập tin ngoại trừ việc nó sử dụng ký hiệu con đường thông thường thay vì của bản dịch.
    • DirectoryMode=: Nếu điểm automount hoặc bất cứ thư mục cần được tạo ra, điều này sẽ xác định các thiết lập quyền truy cập của những thành phần đường dẫn.
    Phần [Swap]
    Phần [Swap] được sử dụng để cấu hình không gian trao đổi trên hệ thống. Các đơn vị phải được đặt theo tên của tập tin trao đổi hoặc các thiết bị trao đổi, sử dụng các hệ thống dịch tập tin tương tự mà đã được thảo luận ở trên.
    Giống như các tùy chọn gắn kết, các đơn vị trao đổi có thể được tạo ra tự động từ /etc/fstab, hoặc có thể được cấu hình thông qua một tập tin đơn vị chuyên dụng.

    Phần [Swap] của một tập tin đơn vị có thể chứa các chỉ dẫn sau để cấu hình:
    • What=: Đường dẫn tuyệt đối đến vị trí của không gian trao đổi, cho dù đây là một tập tin hoặc một thiết bị.
    • Priority=: Điều này cho biết ưu tiên của các trao đổi được cấu hình.
    • Options=: Bất kỳ lựa chọn thường được thiết lập trong file /etc/fstab có thể được thiết lập với chỉ thị này thay thế. Một danh sách bằng dấu phẩy được sử dụng.
    • TimeoutSec=: Lượng thời gian mà systemd chờ cho đến khi trao đổi phải được kích hoạt trước khi đánh dấu sự hoạt động như là một thất bại.
    Phần [Path]
    Phần [Path] xác định một đường dẫn hệ thống tập tin mà systemd có thể theo dõi các thay đổi. Một đơn vị khác phải tồn tại sẽ được kích hoạt khi hoạt động nào đó được phát hiện ở các vị trí đường dẫn. Hoạt động đường dẫn được xác định thông qua sự kiện inotify.
    Phần [Path] của một tập tin đơn vị có thể chứa các chỉ thị sau:
    • PathExists=: Chỉ thị này được sử dụng để kiểm tra xem các đường dẫn trong câu hỏi tồn tại. Nếu có, các đơn vị liên quan được kích hoạt.
    • PathExistsGlob=: Giống như ở trên, nhưng hỗ trợ tập tin biểu thức glob để xác định con đường tồn tại.
    • PathChanged=: Chỉ thị này sẽ giám sát vị trí con đường cho sự thay đổi. Các đơn vị liên quan được kích hoạt nếu có thay đổi được phát hiện khi các tập tin theo dõi được đóng lại.
    • PathModified=: Chỉ thị này sẽ giám sát các thay đổi như các chỉ thị trên, nhưng nó kích hoạt trên tập ghi cũng như khi tập tin được đóng lại.
    • DirectoryNotEmpty=: Chỉ thị này cho phép systemd kích hoạt các đơn vị liên quan khi các thư mục không còn trống.
    • Unit=: Chỉ thị này quy định các đơn vị để kích hoạt khi các điều kiện đường dẫn quy định trên được đáp ứng. Nếu điều này được bỏ qua, systemd sẽ tìm một file .service có chung tên đơn vị cơ sở tương tự như đơn vị này.
    • MakeDirectory=: Chỉ thị này xác định nếu systemd sẽ tạo cấu trúc thư mục của các con đường trong câu hỏi trước khi xem xét.
    • DirectoryMode=: Nếu chỉ thị trên được bật, đây sẽ thiết lập các chế độ cho phép của bất kỳ thành phần con đường phải được tạo ra.
    Phần [Timer]
    Phần này được sử dụng để sắp xếp thao tác tới các hoạt động tại một thời điểm cụ thể hoặc sau một sự chậm trễ nhất định. loại đơn vị này thay thế hoặc bổ sung một số chức năng của cron và daemon. Một đơn vị liên quan phải được cung cấp sẽ được kích hoạt khi bộ đếm thời gian là đạt.
    Phần [Timer] của một tập tin đơn vị có thể chứa một số các chỉ thị sau:
    • OnActiveSec=: Chỉ thị này cho phép các đơn vị có liên quan phải được kích hoạt tương đối đến các đơn vị kích hoạt .timer.
    • OnBootSec=: Chỉ thị này được sử dụng để xác định số lượng thời gian sau khi hệ thống được khởi động khi các đơn vị liên quan phải được kích hoạt.
    • OnStartupSec=: Chỉ thị này cũng tương tự như các bộ đếm thời gian trên, nhưng liên quan đến khi quá trình systemd bắt đầu.
    • OnUnitActiveSec=: Điều này đặt ra một bộ đếm thời gian theo khi các đơn vị liên quan đã được kích hoạt trước.
    • OnUnitInactiveSec=: Điều này đặt bộ đếm thời gian liên quan đến khi các đơn vị liên quan đã được đánh dấu là không hoạt động cuối cùng.
    • OnCalendar=: Điều này cho phép bạn kích hoạt các đơn vị liên quan bằng cách xác định một cách tuyệt đối thay vì liên quan đến một sự kiện.
    • AccuracySec=: Đơn vị này được sử dụng để thiết lập mức độ chính xác mà bộ đếm thời gian nên được tôn trọng. Theo mặc định, các đơn vị liên quan sẽ được kích hoạt trong vòng một phút của bộ đếm thời gian khi đạt tới. Giá trị của chỉ thị này sẽ xác định các giới hạn trên của cửa sổ trong đó quá trịnh systemd kích hoạt.
    • Unit=: Chỉ thị này được sử dụng để chỉ định các đơn vị đó phải được kích hoạt khi bộ đếm thời gian trôi qua. Nếu không được thiết lập, systemd sẽ tìm một đơn vị .service với một cái tên phù hợp với đơn vị này.
    • Persistent=: Nếu điều này được thiết lập, systemd sẽ kích hoạt các đơn vị liên quan khi bộ đếm thời gian được kích hoạt, nó sẽ được kích hoạt trong khoảng thời gian mà bộ đếm thời gian không hoạt động.
    • WakeSystem=: Thiết lập chỉ thị này cho phép bạn đánh thức một hệ thống đang bị đình chỉ nếu thảo mãn điều kiện.
    Phần [Slice]
    Phần này của một tập tin đơn vị thực sự không có bất kỳ cấu hình cụ thể đơn vị .slice. Thay vào đó, nó có thể chứa một số chỉ thị quản lý tài nguyên thực sự sẵn sàng cho một số các đơn vị được liệt kê ở trên.
    Một số chỉ thị phổ biến trong phần [Slice], mà cũng có thể được sử dụng trong các đơn vị khác có thể được tìm thấy trong systemd.resource-control man page. Đây là những giá trị trong các phần đơn vị cụ thể sau đây:
    • [Slice]
    • [Scope]
    • [Service]
    • [Socket]
    • [Mount]
    • [Swap]
    Tạo các đơn vị Instance từ mẫu đơn vị tập tin
    Chúng tôi đã đề cập trước đó trong hướng dẫn này, các ý tưởng của các tập tin template đơn vị được sử dụng để tạo ra nhiều trường hợp của các đơn vị. Trong phần này, chúng ta có thể đi qua khái niệm này chi tiết hơn.

    Template unit files, trong hầu hết không có gì khác hơn các tập tin đơn vị thường xuyên. Tuy nhiên, chúng cung cấp sự linh hoạt trong việc cấu hình đơn vị bằng cách cho phép một số phần của tập tin sử dụng thông tin năng động sẽ có sẵn tại thời gian chạy.

    Template and Instance Unit Names
    Template unit files có thể được xác định bởi vì chúng chứa một biểu tượng @ sau tên đơn vị cơ sở và trước khi các loại đơn vị hậu tố. Một tên tập tin mẫu đơn có thể trông như thế này:
    Mã:
    example@.service
    Khi một instance được tạo ra từ một khuôn mẫu, một instance identifier được đặt giữa các ký hiệu @ và thời gian đánh dấu sự khởi đầu của các loại hình đơn vị. Ví dụ, các đơn vị tập tin mẫu trên có thể được sử dụng để tạo ra một đơn vị dụ đó trông như thế này:
    Mã:
    example@instance1.service
    Một tập tin ví dụ thường được tạo ra như là một liên kết symbolic đến tập tin mẫu, với tên liên kết bao gồm các instance identifier. Bằng cách này, nhiều liên kết với các định danh duy nhất có thể chỉ trở lại một tập tin mẫu đơn. Khi quản lý một đơn vị instance, systemd sẽ tìm kiếm một tập tin với tên ví dụ chính xác mà bạn chỉ định trên dòng lệnh để sử dụng. Nếu nó không thể tìm thấy một, nó sẽ tìm kiếm một tập tin mẫu liên quan.

    Template Specifiers
    Sức mạnh của các tập tin đơn vị mẫu được chủ yếu là nhìn thấy thông qua khả năng của nó để tự động thay thế thông tin thích hợp trong định nghĩa đơn vị theo môi trường hoạt động. Điều này được thực hiện bằng cách thiết lập các chỉ thị trong tập tin mẫu như bình thường, nhưng thay thế các giá trị hoặc các bộ phận nhất định của giá trị với biến specifiers.

    Sau đây là một số các specifiers phổ biến hơn sẽ được thay thế khi một đơn vị instance được giải thích với các thông tin có liên quan:
    • %n: Nơii xuất hiện trong một tập tin mẫu, kết quả tên đơn vị đầy đủ sẽ được chèn vào.
    • %N: Giống như ở trên, nhưng sẽ thoát ra, chẳng hạn như những thứ có mặt trong mô hình đường dẫn tập tin, sẽ bị đảo ngược.
    • %p: Tham chiếu các tiền tố tên đơn vị. Đây là phần trong tên của đơn vị mà đến trước ký hiệu @.
    • %P: Tương tự như trên, nhưng với bất kỳ escaping reversed.
    • %i: Tham chiếu instance name, đó là định danh sau @ trong đơn vị instance. Đây là một trong những specifiers thường được sử dụng nhất vì nó đảm bảo được năng động. Việc sử dụng định danh này khuyến khích việc sử dụng các cấu hình định đáng kể.
    • %I: Tương tự như trên, nhưng với bất kỳ escaping reversed.
    • %f: Điều này sẽ được thay thế bằng tên instance giữ lại hoặc tên tiền tố, thêm vào phía trước với một /.
    • %c: Điều này sẽ chỉ ra các nhóm kiểm soát của các đơn vị, với hệ thống cấp bậc /sys/fs/cgroup/ssytemd/ bị gỡ bỏ.
    • %u: Tên của người sử dụng cấu hình để chạy các đơn vị.
    • %U: Giống như trên, nhưng là một số UID thay vì tên.
    • %H: Tên máy chủ của hệ thống đang chạy các đơn vị.
    • %%: Điều này được sử dụng để chèn thêm một dấu phần trăm.
    Bằng cách sử dụng các định danh trên trong một tập tin mẫu, systemd sẽ điền vào các giá trị đúng khi giải thích các mẫu để tạo ra một đơn vị instance.

    Phần kết luận
    Khi làm việc với systemd, sự hiểu biết đơn vị và các tập tin đơn vị có thể làm cho quản trị đơn giản. Không giống như nhiều hệ thống init khác, bạn không cần phải biết một ngôn ngữ script để giải thích các tập tin init dùng để khởi động dịch vụ hoặc hệ thống. Các tập tin đơn vị sử dụng một cú pháp khai báo khá đơn giản cho phép bạn xem qua để biết mục đích và tác động của một đơn vị khi kích hoạt.

    Phá vỡ các chức năng như kích hoạt logic thành các đơn vị riêng biệt, không chỉ cho phép các quá trình systemd nội bộ để tối ưu hóa song song, nó cũng giữ cấu hình khá đơn giản và cho phép bạn sửa đổi, khởi động lại một số đơn vị mà không phá hỏng các kết nối liên quan của họ. Tận dụng những khả năng có thể cung cấp cho bạn sự linh hoạt và sức mạnh trong hệ thống.
     
    16/2/17 Sửa lần cuối: 17/2/17 #1

Chia sẻ trang này

Đang tải...