# How to run yc-360 Script as a Linux System Service (systemctl)

This guide explains how to configure the yc-360 script to run as a system service on your Linux machine using systemctl. It covers both Debian-based distributions (Debian, Ubuntu, Linux Mint, AWS Amazon Linux where applicable) and RHEL-based distributions (RHEL, CentOS Stream, Rocky Linux, AlmaLinux, Fedora), including the extra SELinux steps required on RHEL-based systems.

# Placeholders Used in This Guide

Every path or name that is specific to your machine is written as a placeholder inside angle brackets, e.g. <YC_INSTALL_DIR>. Replace the placeholder and the angle brackets themselves with your real value. Do not leave < and > in any command or file you type.

Placeholder	What it means	Example value
`<YC_INSTALL_DIR>`	The folder where you extracted/unzipped the yc-360 distribution	`/opt/yc-360/linux`
`<YC_EXECUTABLE>`	Full path to the yc-360 launcher executable (usually `<YC_INSTALL_DIR>/yc`)	`/opt/yc-360/linux/yc`
`<YC_CONFIG>`	Full path to the yc-360 YAML configuration file (usually `<YC_INSTALL_DIR>/yc-config.yaml`)	`/opt/yc-360/linux/yc-config.yaml`
`<SERVICE_NAME>`	The systemd unit name. The file you create must be named `<SERVICE_NAME>.service`	`yc-360-script`
`<SERVICE_USER>` / `<SERVICE_GROUP>`	The Linux user/group the service runs as (not root, unless you really need root)	`yc360` / `yc360`
`<LOG_DIR>`	Directory where the service's stdout/stderr log files are written	`/var/log/yc-360`
`<DATA_DIR>`	Directory where yc-360 writes its reports, captures, heap dumps, etc.	`/var/lib/yc-360`
`<APP_USER>`	The user that runs your monitored application (only needed when troubleshooting SELinux/permissions)	`tomcat`

Tip:

Decide your real paths and service name first, write them down, and then substitute them everywhere consistently (service file, SELinux rules, directory creation commands).

# Prerequisites

yc-360 script installed on your system (see Downloads).
Basic understanding of systemd / systemctl commands.
A user with sudo (or root) privileges.
On RHEL-based systems: SELinux tooling installed (see Step 0).

# Step 0: Identify Your Distribution and Prepare

Check which family your OS belongs to:

cat /etc/os-release

Debian-based (Debian, Ubuntu, …) — systemd is preinstalled. Optionally make sure everything is current:

sudo apt-get update
sudo apt-get install -y systemd

1
2

RHEL-based (RHEL, CentOS Stream, Rocky, AlmaLinux, Fedora) — install systemd plus the SELinux management tools (the semanage command comes from policycoreutils-python-utils):

sudo dnf install -y systemd policycoreutils-python-utils policycoreutils audit

Confirm SELinux status (you will need this later):

getenforce

Possible outputs: Disabled, Permissive, Enforcing. Only Enforcing requires the SELinux steps in Step 4; on Disabled/Permissive you can skip them, but it is still recommended to set the contexts so the service keeps working if SELinux is later switched to Enforcing.

Also note your systemd version — it decides which logging lines you can use in the service file (Step 2c):

systemctl --version | head -1
# e.g. "systemd 252 (252.el9)"  or  "systemd 239 (239-58.el8)"

1
2

systemd ≥ 240 (RHEL/CentOS/Rocky/AlmaLinux 9+, Fedora, Debian 11+, Ubuntu 20.04+): StandardOutput=append: works.
systemd < 240 (RHEL/CentOS/Rocky/AlmaLinux 8.x ship systemd 239): append: is not supported — the unit is rejected with Invalid StandardOutput setting: append:... or the service fails with status=209/STDOUT. Use the alternatives in Step 2c.

# Step 1: Create the Systemd Service File

Open a terminal window with root privileges (using sudo) and create a new unit file under /etc/systemd/system:

sudo vi /etc/systemd/system/<SERVICE_NAME>.service

Example with the placeholder replaced:

sudo vi /etc/systemd/system/yc-360-script.service

# Step 2: Copy and Edit the Service Configuration

Paste the following content into the file and replace every placeholder with your real value:

[Unit]
Description=yc-360 Script Service
After=network.target
Wants=network-online.target
StartLimitIntervalSec=500
StartLimitBurst=5

[Service]
Type=simple

# User/Group the service runs as — must be able to read <YC_INSTALL_DIR>
# and write to <LOG_DIR> and <DATA_DIR>
User=<SERVICE_USER>
Group=<SERVICE_GROUP>

# Folder that contains the yc-360 script files
WorkingDirectory=<YC_INSTALL_DIR>

# The actual command that starts yc-360
ExecStart=<YC_EXECUTABLE> -m3 -c <YC_CONFIG>

Restart=on-failure
RestartSec=5

# Log files — two hard requirements, otherwise you get status=209/STDOUT:
#  1) systemd >= 240 (on RHEL/CentOS/Rocky/Alma 8 use the alternatives in Step 2c)
#  2) <LOG_DIR> must already exist (create it below) — systemd does NOT create it
StandardOutput=append:<LOG_DIR>/<SERVICE_NAME>.log
StandardError=append:<LOG_DIR>/<SERVICE_NAME>-error.log

## Optional hardening/resource directives — uncomment and adjust if necessary
# LimitNOFILE=65536
# LimitNPROC=1024
# TimeoutStopSec=60
# ProtectSystem=full
# ProtectHome=true
# PrivateTmp=true
# NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

Refer to the systemd documentation (opens new window) for details of each directive.

# Create the required directories

sudo mkdir -p <LOG_DIR> <DATA_DIR>
sudo chown <SERVICE_USER>:<SERVICE_GROUP> <LOG_DIR> <DATA_DIR>
sudo chmod 755 <LOG_DIR> <DATA_DIR>

1
2
3

Example:

sudo mkdir -p /var/log/yc-360 /var/lib/yc-360
sudo chown yc360:yc360 /var/log/yc-360 /var/lib/yc-360

1
2

Save and close the file.

# 2a. Debian/Ubuntu variation

Any non-root user works; common choices are your application user, www-data (for web apps), or a dedicated user:
```
User=www-data
Group=www-data
```
1
2

Typical Debian-style paths if you prefer FHS locations:

WorkingDirectory=/opt/yc-360/linux
ExecStart=/opt/yc-360/linux/yc -m3 -c /opt/yc-360/linux/yc-config.yaml
StandardOutput=append:/var/log/yc-360/yc-360-script.log
StandardError=append:/var/log/yc-360/yc-360-script-error.log

1
2
3
4

Ubuntu/Debian use AppArmor instead of SELinux (usually in enforcing mode on Ubuntu). Custom scripts normally have no profile and therefore run unconfined — no action is usually needed. If you do have a profile for the script and see AppArmor denials in /var/log/syslog or journalctl, temporarily allow it with:
```
sudo aa-complain /etc/apparmor.d/<profile-name>
```
1
and later replace aa-complain with aa-enforce after adding the required rules to the profile.

# 2b. RHEL/CentOS/Rocky/Alma/Fedora variation

Create a dedicated non-root user (recommended) or use the application user:

sudo useradd -r -s /sbin/nologin <SERVICE_USER>
sudo groupadd <SERVICE_GROUP> 2>/dev/null || true

1
2

Example:

sudo useradd -r -s /sbin/nologin yc360

Typical RHEL-style paths:

WorkingDirectory=/opt/yc-360/linux
ExecStart=/opt/yc-360/linux/yc -m3 -c /opt/yc-360/linux/yc-config.yaml
StandardOutput=append:/var/log/yc-360/yc-360-script.log
StandardError=append:/var/log/yc-360/yc-360-script-error.log

1
2
3
4

On RHEL/CentOS/Rocky/AlmaLinux 8 these two append: lines fail with status=209/STDOUT (systemd 239 does not support append:). Check systemctl --version and apply Step 2c before starting the service.

Make sure the service user can execute the binaries and read the config:

sudo chmod -R a+rX <YC_INSTALL_DIR>
sudo chmod +x <YC_EXECUTABLE>

1
2

RHEL-based systems enforce SELinux by default — continue with Step 4 before starting the service.

# 2c. Fixing `status=209/STDOUT` for the `StandardOutput=`/`StandardError=` lines (common on RHEL)

If the service fails like this:

Process: 1234 ExecStart=/opt/yc-360/linux/yc ... (code=exited, status=209/STDOUT)
Main PID: 1234 (code=exited, status=209/STDOUT)

1
2

or systemd refuses to load the unit with:

Invalid StandardOutput setting: append:/path/to/folder/linux/yc-360-script.log

…then the problem is not yc-360 — it is these two lines:

StandardOutput=append:/path/to/folder/linux/yc-360-script.log
StandardError=append:/path/to/folder/linux/yc-360-script-error.log

1
2

209 is systemd's internal EXIT_STDOUT: systemd could not set up the service's standard output. There are exactly three causes:

#	Cause	How to confirm
1	systemd too old. `append:` was added in systemd v240. RHEL/CentOS/Rocky/AlmaLinux 8.x ship systemd 239, which rejects it (Red Hat bug 2076714)	`systemctl --version \\| head -1` → prints `239` (or anything `< 240`)
2	Log directory does not exist. systemd does not create the parent directory of the file target	`ls -ld /path/to/folder/linux/` → `No such file or directory`
3	SELinux denial (RHEL, `Enforcing`) blocking PID 1 from creating/opening the log file at that path	`sudo ausearch -m avc,deny -ts recent` mentions the log path

# Fix for cause 1 — systemd < 240 (RHEL/CentOS/Rocky/Alma 8): pick one option

Option A (recommended): log to the systemd journal. Delete both append: lines and use:

StandardOutput=journal
StandardError=journal

1
2

View the logs with:

sudo journalctl -u <SERVICE_NAME> -f

Option B: keep plain log files on any systemd version by doing the redirection yourself in ExecStart=. Delete both StandardOutput=/StandardError= lines and use:

ExecStart=/bin/sh -c 'exec <YC_EXECUTABLE> -m3 -c <YC_CONFIG> >> <LOG_DIR>/<SERVICE_NAME>.log 2>> <LOG_DIR>/<SERVICE_NAME>-error.log'

exec makes the shell replace itself with the yc-360 process, so systemctl stop still signals yc-360 directly (without exec, stop would kill only the shell and orphan yc-360).
Keep the whole command in single quotes exactly as shown; still replace every <...> placeholder first.
<LOG_DIR> must exist and be writable by <SERVICE_USER> (see "Create the required directories" above).
With this option systemctl status shows /bin/sh as the main process — that is expected.

Option C: systemd ≥ 240 but you still get status=209/STDOUT — the version is fine, so it is cause 2 or 3 below.

# Fix for cause 2 — create the directory before the first start

sudo mkdir -p <LOG_DIR>
sudo chown <SERVICE_USER>:<SERVICE_GROUP> <LOG_DIR>
sudo touch <LOG_DIR>/<SERVICE_NAME>.log <LOG_DIR>/<SERVICE_NAME>-error.log
sudo chown <SERVICE_USER>:<SERVICE_GROUP> <LOG_DIR>/<SERVICE_NAME>.log <LOG_DIR>/<SERVICE_NAME>-error.log

1
2
3
4

Example (matches the paths used in this guide):

sudo mkdir -p /var/log/yc-360
sudo chown yc360:yc360 /var/log/yc-360

1
2

# Fix for cause 3 — SELinux (RHEL only)

Label the log directory var_log_t so PID 1 (systemd) and the service may create/append files there (details in Step 4.5):

sudo semanage fcontext -a -t var_log_t "<LOG_DIR>(/.*)?"
sudo restorecon -R -v <LOG_DIR>
ls -Z <LOG_DIR>

1
2
3

If semanage says the rule exists, use -m instead of -a.

# Verify the fix

sudo systemctl daemon-reload
sudo systemctl restart <SERVICE_NAME>.service
systemctl show <SERVICE_NAME> -p StandardOutput -p StandardError
sudo journalctl -u <SERVICE_NAME> -n 50 --no-pager
sudo systemctl status <SERVICE_NAME>.service   # expect: Active: active (running)

1
2
3
4
5

Never leave the append: lines in place on a systemd < 240 host: even when the unit loads, the redirection silently falls back or fails, and tail -f <LOG_DIR>/... will show nothing.

# 2d. Fixing `status=203/EXEC` — systemd cannot execute the `yc` binary

If the service fails like this:

Process: 1234 ExecStart=/opt/yc-360/linux/yc -m3 -c ... (code=exited, status=203/EXEC)
Main PID: 1234 (code=exited, status=203/EXEC)

1
2

203 is systemd's EXIT_EXEC: the execve(2) call for ExecStart= failed, i.e. systemd could not start the yc binary at all (the service never runs, so <SERVICE_NAME>-error.log stays empty).

Diagnose it in this order:

# 1. What command did systemd actually receive? (placeholders must be gone)
systemctl show <SERVICE_NAME> -p ExecStart

# 2. Does the file exist at that exact path, and is it executable?
ls -l <YC_EXECUTABLE>
sudo chmod +x <YC_EXECUTABLE>

# 3. Does it work when run manually as the service user?
sudo -u <SERVICE_USER> <YC_EXECUTABLE> -m3 -c <YC_CONFIG>

# 4. What kind of file is it, and does it match this machine's architecture?
file <YC_EXECUTABLE>
uname -m

# 5. RHEL only: did SELinux deny the execute?
sudo ausearch -m avc,deny -ts recent | grep -i execute

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Causes and fixes:

Cause	How to confirm	Fix
Placeholder never replaced (e.g. `ExecStart=<YC_EXECUTABLE> ...` or a leftover `/path/to/folder/...`)	`systemctl show -p ExecStart` shows the literal placeholder	Edit the unit file with the real path, then `sudo systemctl daemon-reload`
Path typo / wrong case (Linux paths are case-sensitive: `yc` ≠ `YC`) or file not extracted there	`ls -l` → `No such file or directory`	Correct `<YC_EXECUTABLE>`; verify with `ls -l <YC_INSTALL_DIR>`
Missing execute bit	`ls -l` shows `-rw-r--r--` instead of `-rwxr-xr-x`	`sudo chmod +x <YC_EXECUTABLE>`
SELinux denial `avc: denied { execute }` / `execute_no_trans` on the `yc` file (RHEL, `Enforcing`)	`ausearch -m avc,deny -ts recent` names the file	Label it `bin_t` → Step 4.3
Binary built for a different CPU architecture (e.g. `aarch64` binary on an `x86_64` host)	`file` prints `ELF 64-bit ARM aarch64`, `uname -m` prints `x86_64`	Download the yc-360 build matching `uname -m`
It is a shell script with Windows (CRLF) line endings or a broken `#!/bin/sh` shebang	`head -1 <YC_EXECUTABLE> \\| cat -A` shows `^M$` at line end	`sudo dos2unix <YC_EXECUTABLE>` and ensure the first line is `#!/bin/sh` (or the correct interpreter), then `chmod +x`
Filesystem mounted `noexec` (common for custom mounts under `/opt` or `/usr/local`)	`findmnt -no OPTIONS --target <YC_INSTALL_DIR>` contains `noexec`	Remount with `sudo mount -o remount,exec <mount-point>` (or move the installation), then restart the service

Also related: status=204/CHDIR means systemd could not chdir() into WorkingDirectory= — fix the <YC_INSTALL_DIR> value in that directive the same way.

Apply and re-test:

sudo systemctl daemon-reload
sudo systemctl start <SERVICE_NAME>.service
sudo systemctl status <SERVICE_NAME>.service   # expect: Active: active (running)

1
2
3

# Step 3: Reload Systemd

Inform systemd about the newly created service file:

sudo systemctl daemon-reload

# Step 4: SELinux Configuration (RHEL-based only)

Skip this entire step on Debian/Ubuntu systems that do not run SELinux (getenforce → Disabled or command not found).

# 4.1 Verify SELinux is enabled

getenforce

If it prints Enforcing, follow the steps below.

# 4.2 Give the unit file the correct context

The unit file must be labeled systemd_unit_file_t. Files created under /etc/systemd/system normally get this label automatically; verify and fix with:

ls -Z /etc/systemd/system/<SERVICE_NAME>.service
sudo restorecon -v /etc/systemd/system/<SERVICE_NAME>.service

1
2

If the label is wrong (e.g. admin_home_t or user_home_t because you created the file from a home directory and copied it), set it explicitly:

sudo semanage fcontext -a -t systemd_unit_file_t "/etc/systemd/system/<SERVICE_NAME>\.service"
sudo restorecon -v /etc/systemd/system/<SERVICE_NAME>.service

1
2

If semanage reports that the rule already exists, replace -a (add) with -m (modify).

# 4.3 Label the executables with `bin_t`

Executables placed under /opt, /usr/local or a custom directory may be labeled usr_t/lib_t, which a confined domain is not allowed to execute. Label every executable that the service launches (the yc binary and any *.sh helper scripts) as bin_t, which is the generic "executable content" type:

sudo semanage fcontext -a -t bin_t "<YC_EXECUTABLE>"
sudo restorecon -v <YC_EXECUTABLE>

1
2

If the installation directory contains additional executables/scripts that are invoked (for example helper shell scripts), label them too:

sudo semanage fcontext -a -t bin_t "<YC_INSTALL_DIR>/[^/]+\.sh"
sudo restorecon -R -v <YC_INSTALL_DIR>

1
2

Quick (temporary, lost on reboot) alternative for testing:

sudo chcon -t bin_t <YC_EXECUTABLE>

Verify:

ls -Z <YC_EXECUTABLE>
# expected: ... system_u:object_r:bin_t:s0 /opt/yc-360/linux/yc

1
2

Why bin_t? SELinux decides what a process may execute based on the type of the target file. bin_t (and etc_t, lib_t in some policy versions) is executable by service domains; usr_t (the default label for files under /opt) is not always allowed. Using semanage fcontext makes the label persistent across relabels — chcon alone does not.

# 4.4 Make the configuration and data files readable/writable

The YAML config only needs to be readable; the default label for /opt (usr_t) is normally readable by an unconfined service domain. If AVC denials mention <YC_CONFIG>, label it bin_t as well:
```
sudo semanage fcontext -a -t bin_t "<YC_CONFIG>"
sudo restorecon -v <YC_CONFIG>
```
1
2
If yc-360 writes reports into <DATA_DIR>, make sure the directory exists and is owned by the service user (Step 2). If denials show up for the data directory, label it var_log_t (a writable/log-style type) or create a dedicated type:
```
sudo semanage fcontext -a -t var_log_t "<DATA_DIR>(/.*)?"
sudo restorecon -R -v <DATA_DIR>
```
1
2

# 4.5 Make sure log file paths are writable

With StandardOutput=append:<LOG_DIR>/..., systemd (running in its own domain) creates and appends to the log files. Ensure <LOG_DIR> exists and is labeled consistently (a wrong/missing label or directory here is also a common cause of status=209/STDOUT — see Step 2c):

sudo semanage fcontext -a -t var_log_t "<LOG_DIR>(/.*)?"
sudo restorecon -R -v <LOG_DIR>
ls -Z <LOG_DIR>

1
2
3

Alternative that avoids log-file labeling entirely: use the systemd journal instead of files:
StandardOutput=journal
StandardError=journal
1
2
then view logs with sudo journalctl -u <SERVICE_NAME>.

# 4.6 Apply everything and start

sudo systemctl daemon-reload
sudo systemctl enable <SERVICE_NAME>.service
sudo systemctl start <SERVICE_NAME>.service

1
2
3

# 4.7 Check for AVC denials

After starting the service and letting it run for a minute, check whether SELinux blocked anything:

sudo ausearch -m avc,deny -ts recent

or, for a human-readable summary of the last boot:

sudo ausearch -m avc,deny -ts boot | sudo audit2why

Common fixes:

Symptom in `audit2why`	Fix
`path ... dev="..." ino=... scontext=..._service_t tcontext=...usr_t tclass=file execute_no_trans`	Executable not labeled `bin_t` → repeat Step 4.3
`... tclass=file { read open }` denied on `<YC_CONFIG>`	Label the config `bin_t` → Step 4.4
`... tclass=dir { write add_name }` denied on `<LOG_DIR>` / `<DATA_DIR>`	Fix ownership + label as `var_log_t` → Steps 4.4/4.5
`... tclass=dir { search }` denied on a parent path (e.g. `/home/<APP_USER>`)	The service needs `execmod`/`ptrace` access to the app — see 4.8

Only after confirming the denial with audit2why should you consider a custom policy module (as a last resort):

sudo ausearch -m avc,deny -ts recent | sudo audit2allow -M yc360-custom
sudo semanage permissive -a <service-domain>   # temporary, while validating
sudo semodule -i yc360-custom.pp

1
2
3

Keep audit2allow modules minimal and reviewed — each one weakens the policy.

# 4.8 If thread dumps / process capture of the target JVM fail (`jcmd`, `jstack`, `jmap`)

yc-360 attaches to your application process. SELinux can block that cross-process attach via the deny_ptrace boolean:

getsebool deny_ptrace
sudo setsebool -P deny_ptrace off

1
2

-P makes the change persistent across reboots.
If your security policy requires deny_ptrace=on, instead label the service domain permissive while testing:
```
sudo semanage permissive -a unconfined_service_t
```
1
and check sudo ausearch -m avc -ts recent to see exactly what is blocked.

# Step 5: Enable the Service

To start yc-360 automatically at boot:

sudo systemctl enable <SERVICE_NAME>.service

Example:

sudo systemctl enable yc-360-script.service

# Step 6: Verify Service Status

sudo systemctl status <SERVICE_NAME>.service

Expected: Active: active (running).

# Step 7: Manage the Service

Start manually:

sudo systemctl start <SERVICE_NAME>.service

Stop:

sudo systemctl stop <SERVICE_NAME>.service

Restart (e.g. after editing <YC_CONFIG>):

sudo systemctl restart <SERVICE_NAME>.service

View logs:

sudo journalctl -u <SERVICE_NAME>.service
# or, if you configured append: log files
sudo tail -f <LOG_DIR>/<SERVICE_NAME>.log
sudo tail -f <LOG_DIR>/<SERVICE_NAME>-error.log

1
2
3
4

# Quick Reference: Debian vs RHEL Differences

Topic	Debian / Ubuntu	RHEL / CentOS Stream / Rocky / AlmaLinux / Fedora
Package manager	`apt-get`	`dnf`
Install SELinux tools	not applicable (or `apt-get install policycoreutils`)	`dnf install policycoreutils-python-utils audit`
MAC framework	AppArmor (usually no profile → no action)	SELinux (usually `Enforcing` → follow Step 4)
Label executables	n/a	`semanage fcontext -a -t bin_t <executable>` + `restorecon`
Unit file context	n/a	must be `systemd_unit_file_t`
Check denials	`journalctl -k`, `/var/log/syslog`	`ausearch -m avc,deny -ts recent` / `audit2why`
Example service user	`www-data` or app user	dedicated `useradd -r` system user
systemd version	≥ 240 → `StandardOutput=append:` works	8.x = systemd 239 → `append:` fails (`status=209/STDOUT`); use journal or `sh -c 'exec … >> … 2>> …'` (Step 2c)

# Troubleshooting

Problem	Likely cause	Solution
`Failed to execute command ... Permission denied`	Executable bit missing or wrong SELinux label	`chmod +x <YC_EXECUTABLE>`; on RHEL repeat Step 4.3 (`bin_t`)
`Unit <SERVICE_NAME>.service not found`	Wrong unit name or `daemon-reload` not run	File must be exactly `<SERVICE_NAME>.service`; run `sudo systemctl daemon-reload`
`status=203/EXEC` in `journalctl`	systemd's `execve()` failed: `yc` missing, not executable, wrong path/placeholder, wrong architecture, `noexec` mount, or SELinux `{ execute }` denial	Step 2d (full diagnosis for the `yc` binary)
`status=204/CHDIR` in `journalctl`	`WorkingDirectory=` points to a non-existent `<YC_INSTALL_DIR>`	Step 2d (last row of the causes table)
`status=209/STDOUT` (`code=exited, status=209/STDOUT`)	systemd could not set up stdout: log dir missing, systemd < 240 rejects `append:`, or SELinux denies the log path	Step 2c (causes 1–3)
`Invalid StandardOutput setting: append:...` at load time	systemd < 240 (RHEL/CentOS/Rocky/Alma 8) does not support `append:`	Step 2c, Option A or B
Service starts, exits immediately	Wrong `<YC_CONFIG>` path or unreadable config	Check `<SERVICE_NAME>-error.log`, fix path/ownership
`avc: denied { execute_no_trans }`	Executable not labeled `bin_t`	Step 4.3
No thread/process report for the app	`deny_ptrace` or cross-domain attach blocked	Step 4.8
Logs empty	`<LOG_DIR>` missing or not writable	Create it and `chown <SERVICE_USER>` (Step 2), label `var_log_t` (Step 4.5)
Service works until reboot, then SELinux denials return	Used `chcon` instead of `semanage fcontext`	Re-apply with `semanage fcontext -a` + `restorecon`

# Additional Notes

The service configuration defines restart behavior, logging, and resource limits; customize these for your environment. Refer to the systemd documentation (opens new window) for all available directives.
Ensure <SERVICE_USER> can read <YC_EXECUTABLE> and <YC_CONFIG>, and can write to <LOG_DIR> and <DATA_DIR>.
Prefer semanage fcontext + restorecon over chcon for all SELinux labels so they survive fixfiles relabel and OS upgrades.
After any change to the unit file: sudo systemctl daemon-reload and sudo systemctl restart <SERVICE_NAME>.service.
After any change to SELinux labels: re-check with sudo ausearch -m avc,deny -ts recent.

Following these steps configures the yc-360 script to run as a system service — starting automatically at boot and restarting on failures — on both Debian-based and RHEL-based (SELinux-enforcing) Linux distributions.

← yc-360 Script Action API How to Launch yc-360 Script in the background? →

# How to run yc-360 Script as a Linux System Service (systemctl)

# Placeholders Used in This Guide

# Prerequisites

# Step 0: Identify Your Distribution and Prepare

# Step 1: Create the Systemd Service File

# Step 2: Copy and Edit the Service Configuration

# Create the required directories

# 2a. Debian/Ubuntu variation

# 2b. RHEL/CentOS/Rocky/Alma/Fedora variation

# 2c. Fixing status=209/STDOUT for the StandardOutput=/StandardError= lines (common on RHEL)

# Fix for cause 1 — systemd < 240 (RHEL/CentOS/Rocky/Alma 8): pick one option

# Fix for cause 2 — create the directory before the first start

# Fix for cause 3 — SELinux (RHEL only)

# Verify the fix

# 2d. Fixing status=203/EXEC — systemd cannot execute the yc binary

# Step 3: Reload Systemd

# Step 4: SELinux Configuration (RHEL-based only)

# 4.1 Verify SELinux is enabled

# 4.2 Give the unit file the correct context

# 4.3 Label the executables with bin_t

# 4.4 Make the configuration and data files readable/writable

# 4.5 Make sure log file paths are writable

# 4.6 Apply everything and start

# 4.7 Check for AVC denials

# 4.8 If thread dumps / process capture of the target JVM fail (jcmd, jstack, jmap)

# Step 5: Enable the Service

# Step 6: Verify Service Status

# Step 7: Manage the Service

# Quick Reference: Debian vs RHEL Differences

# Troubleshooting

# Additional Notes

# 2c. Fixing `status=209/STDOUT` for the `StandardOutput=`/`StandardError=` lines (common on RHEL)

# 2d. Fixing `status=203/EXEC` — systemd cannot execute the `yc` binary

# 4.3 Label the executables with `bin_t`

# 4.8 If thread dumps / process capture of the target JVM fail (`jcmd`, `jstack`, `jmap`)