{"id":5805,"date":"2026-10-04T12:38:44","date_gmt":"2026-10-04T09:38:44","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5805"},"modified":"2026-10-04T06:26:15","modified_gmt":"2026-10-04T03:26:15","slug":"systemd-service-keeps-restarting-debugging-guide","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/systemd-service-keeps-restarting-debugging-guide\/","title":{"rendered":"Why Does a systemd Service Keep Restarting? A Debugging Guide"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div class=\"aiw-summary\">\n<p class=\"aiw-box-title\">Quick summary<\/p>\n<p>If a systemd service keeps restarting, inspect its status and journal first; adding a longer <code>RestartSec<\/code> value immediately can hide the actual failure.<\/p>\n<ul>\n<li>Use <code>systemctl status<\/code> to see the latest exit code, signal and systemd warning.<\/li>\n<li>Search <code>journalctl -u<\/code> for the application error, missing environment variable or port conflict.<\/li>\n<li>After fixing the application problem, reload the unit only if its definition changed, then start the service in a controlled way.<\/li>\n<li>Use <code>reset-failed<\/code> when systemd has rate-limited attempts; this does not repair the application.<\/li>\n<\/ul>\n<\/div>\n<p>When an application closes and reopens every few seconds, the problem may not be limited to systemd. systemd may be starting the process again because <code>Restart=<\/code> is enabled in the service definition. The underlying cause could be an incorrect command, missing file, wrong permission, unavailable port, missing environment variable or an application startup failure.<\/p>\n<p>This guide narrows the diagnosis from the systemd layer toward the application layer. First confirm the service name and its actual runtime settings, then interpret the exit code and journal entries. Before changing anything, back up the current unit file and application configuration. After each fix, verify that the service remains healthy instead of only checking whether it starts once.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Confirm_the_restart_loop\"><span class=\"toc_number toc_depth_1\">1.<\/span> Confirm the restart loop<\/a><ul><li><a href=\"#Identify_the_source_of_the_unit_file\"><span class=\"toc_number toc_depth_2\">1.1.<\/span> Identify the source of the unit file<\/a><\/li><\/ul><\/li><li><a href=\"#Find_the_actual_error_in_the_journal\"><span class=\"toc_number toc_depth_1\">2.<\/span> Find the actual error in the journal<\/a><ul><li><a href=\"#Interpret_the_exit_code_and_signal\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Interpret the exit code and signal<\/a><\/li><\/ul><\/li><li><a href=\"#Test_the_start_command_outside_systemd\"><span class=\"toc_number toc_depth_1\">3.<\/span> Test the start command outside systemd<\/a><\/li><li><a href=\"#Narrow_down_common_root_causes\"><span class=\"toc_number toc_depth_1\">4.<\/span> Narrow down common root causes<\/a><ul><li><a href=\"#Incorrect_ExecStart_or_a_missing_file\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> Incorrect ExecStart or a missing file<\/a><\/li><li><a href=\"#Port_conflicts_and_dependency_order\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Port conflicts and dependency order<\/a><\/li><li><a href=\"#Permissions_and_the_working_directory\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> Permissions and the working directory<\/a><\/li><li><a href=\"#Do_not_confuse_FPM_CLI_and_queue_workers\"><span class=\"toc_number toc_depth_2\">4.4.<\/span> Do not confuse FPM, CLI and queue workers<\/a><\/li><\/ul><\/li><li><a href=\"#When_should_you_change_Restart_settings\"><span class=\"toc_number toc_depth_1\">5.<\/span> When should you change Restart settings?<\/a><\/li><li><a href=\"#Apply_the_fix_and_verify_it\"><span class=\"toc_number toc_depth_1\">6.<\/span> Apply the fix and verify it<\/a><\/li><li><a href=\"#Frequently_Asked_Questions\"><span class=\"toc_number toc_depth_1\">7.<\/span> Frequently Asked Questions<\/a><ul><li><a href=\"#Why_does_a_service_restart_while_status_still_says_active\"><span class=\"toc_number toc_depth_2\">7.1.<\/span> Why does a service restart while status still says active?<\/a><\/li><li><a href=\"#Can_a_service_restart_without_systemd_being_the_cause\"><span class=\"toc_number toc_depth_2\">7.2.<\/span> Can a service restart without systemd being the cause?<\/a><\/li><li><a href=\"#Should_I_disable_Restart_while_troubleshooting\"><span class=\"toc_number toc_depth_2\">7.3.<\/span> Should I disable Restart= while troubleshooting?<\/a><\/li><li><a href=\"#What_should_I_check_if_the_service_works_after_a_manual_start\"><span class=\"toc_number toc_depth_2\">7.4.<\/span> What should I check if the service works after a manual start?<\/a><\/li><\/ul><\/li><li><a href=\"#Final_checklist\"><span class=\"toc_number toc_depth_1\">8.<\/span> Final checklist<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Confirm_the_restart_loop\">Confirm the restart loop<\/span><\/h2>\n<p>The first sign usually appears in <code>systemctl status<\/code>. The service may briefly show <code>active (running)<\/code>, then become <code>failed<\/code> or start again. Run the command with your service name:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl status example-service.service --no-pager -l<\/code><\/pre>\n<p>Replace <code>example-service.service<\/code> with the real unit name. You need sudo access and a systemd-based operating system where the service is defined. In the output, focus on these lines:<\/p>\n<ul>\n<li><strong>Active:<\/strong> Shows the current state and the time of the latest state change.<\/li>\n<li><strong>Main PID:<\/strong> Identifies the main process. If it changes on every attempt, systemd may be creating a new process each time.<\/li>\n<li><strong>code=exited<\/strong> and <strong>status=<\/strong>: Show whether the application ended normally or returned an error code.<\/li>\n<li><strong>code=killed<\/strong> and the signal information: Suggest that the process was terminated by a signal.<\/li>\n<li><strong>Start request repeated too quickly<\/strong>: Means systemd has seen many failed starts in a short period and is temporarily limiting new attempts.<\/li>\n<\/ul>\n<p>The last warning is not the root cause. It describes the result of repeated failures and systemd&#8217;s protective behavior. The real error is usually in earlier application log lines.<\/p>\n<h3><span id=\"Identify_the_source_of_the_unit_file\">Identify the source of the unit file<\/span><\/h3>\n<p>A service file may have been supplied by the distribution, installed by a package manager or extended with an override you created. Inspect the effective configuration and drop-ins together:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl cat example-service.service<\/code><\/pre>\n<p>To list the working directory, user, start command, environment files and restart settings separately, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl show example-service.service -p FragmentPath -p DropInPaths -p ExecStart -p User -p Group -p WorkingDirectory -p EnvironmentFiles -p Restart -p RestartSec<\/code><\/pre>\n<p>The <code>systemctl cat<\/code> output shows the main unit and additional settings under <code>\/etc\/systemd\/system\/example-service.service.d\/<\/code>. If the same setting is defined in several places, diagnosis becomes harder, so assess the main file and every override together. The available properties can vary with the systemd version; the unit text and drop-in files remain the primary reference.<\/p>\n<div class=\"aiw-note aiw-note-warning\">\n<p class=\"aiw-box-title\">Caution<\/p>\n<p>Direct changes to a package-provided unit can disappear during an update. If a persistent change is needed, back up the existing definition and use <code>systemctl edit<\/code> to create a narrowly scoped override where possible. Record how to undo any change that affects the way the application starts.<\/p>\n<\/div>\n<h2><span id=\"Find_the_actual_error_in_the_journal\">Find the actual error in the journal<\/span><\/h2>\n<p>The last few lines shown by the status command are often not enough. Review all recent start attempts with timestamps:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo journalctl -u example-service.service -b --no-pager -n 200<\/code><\/pre>\n<p><code>-b<\/code> limits the output to the current boot, while <code>-n 200<\/code> returns the last 200 lines. If the problem began during an earlier boot, use <code>-b -1<\/code> to inspect the previous one. To filter a specific period:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo journalctl -u example-service.service --since &quot;30 minutes ago&quot; --no-pager<\/code><\/pre>\n<p>Look at application lines immediately before or after systemd&#8217;s service-start messages. For example, <code>address already in use<\/code> indicates that another process has the port, <code>permission denied<\/code> indicates rejected access to a file or directory, and <code>no such file or directory<\/code> may refer to the command, working directory or an expected file.<\/p>\n<h3><span id=\"Interpret_the_exit_code_and_signal\">Interpret the exit code and signal<\/span><\/h3>\n<p>A value such as <code>status=1\/FAILURE<\/code> means the application exited with an error, but it does not identify the cause by itself. Match the code with the application&#8217;s documentation and the surrounding journal lines. If you see <code>status=0\/SUCCESS<\/code> but the service still restarts, the application may be exiting normally while the unit contains <code>Restart=always<\/code>.<\/p>\n<p><code>SIGTERM<\/code> or <code>SIGINT<\/code> can be consistent with a controlled stop request. <code>SIGKILL<\/code> may be related to a timeout, an external termination or memory pressure. Check kernel messages as well:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo journalctl -k --since &quot;30 minutes ago&quot; --no-pager | grep -Ei &quot;oom|out of memory|killed process&quot;<\/code><\/pre>\n<p>An empty result does not definitively rule out a memory problem. It only means those expressions were not found in the kernel journal. If the service writes its application logs to a separate file, check that file&#8217;s permissions and the same time range.<\/p>\n<h2><span id=\"Test_the_start_command_outside_systemd\">Test the start command outside systemd<\/span><\/h2>\n<p>If the journal shows an application error, the narrowest next test is to run the command used by systemd with the same user and working directory. Take the command from <code>systemctl cat<\/code>. Testing as root can be misleading; use the same account as the service.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo -u application-user sh -c &#039;cd \/srv\/example-app &amp;&amp; exec \/usr\/bin\/example-app --config \/etc\/example-app\/config.yml&#039;<\/code><\/pre>\n<p>Replace <code>application-user<\/code>, the directory and the command according to your unit file. Do not use a diagnostic command that writes live data or runs a migration. Test the normal start command only within an appropriate maintenance plan. If the command needs interactive environment variables, check separately whether those variables are defined for the systemd service.<\/p>\n<p>A command that fails in the terminal points to an application problem. A command that works in the terminal does not prove that it will work under systemd, because the two environments can differ:<\/p>\n<ul>\n<li>The service uses another user and cannot access a file or socket.<\/li>\n<li><code>WorkingDirectory<\/code> is different, so relative paths resolve elsewhere.<\/li>\n<li><code>PATH<\/code>, <code>HOME<\/code> or application variables from a shell profile are not passed to the service.<\/li>\n<li>Secrets or configuration files are not readable by the service account.<\/li>\n<li>A terminal-launched process already uses the port, so the new systemd attempt cannot bind to it.<\/li>\n<\/ul>\n<p>For diagnosis, do not copy an entire interactive environment into the unit. Add only the variables the application needs, either in the unit or an <code>EnvironmentFile<\/code>. Do not make secret files broadly readable; verify that the service account can read the required file instead.<\/p>\n<h2><span id=\"Narrow_down_common_root_causes\">Narrow down common root causes<\/span><\/h2>\n<h3><span id=\"Incorrect_ExecStart_or_a_missing_file\">Incorrect ExecStart or a missing file<\/span><\/h3>\n<p>Check the binary path, working directory and arguments in <code>ExecStart<\/code> exactly. Python applications installed in a virtual environment may use a different interpreter from the system one. Node.js applications may use a different Node path. Check the absolute path and file access:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">test -x \/usr\/bin\/example-app\nsudo -u application-user test -x \/usr\/bin\/example-app\nsudo -u application-user test -r \/etc\/example-app\/config.yml<\/code><\/pre>\n<p>The first command confirms that the path exists and is executable; the second checks the same condition as the service account. Before correcting a path, determine where the unit file comes from. Change only the missing or incorrect argument; do not alter unrelated resource or restart settings at the same time.<\/p>\n<h3><span id=\"Port_conflicts_and_dependency_order\">Port conflicts and dependency order<\/span><\/h3>\n<p>If the application reports <code>address already in use<\/code> while binding to a TCP port, find the process using that port:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo ss -ltnp | grep &#039;:8080&#039;<\/code><\/pre>\n<p>Replace <code>8080<\/code> with the application&#8217;s real port. If the process is an older copy of the same application, do not terminate it at random. First determine how it was started and which unit manages it. If another service owns the port, assess the conflicting configuration before changing the application port.<\/p>\n<p>An application can fail several times if a database, socket or network service is not ready at startup. <code>After=<\/code> controls start order; it does not guarantee that a service is ready. If the application supports readiness checks, use an appropriate health check or the application&#8217;s own retry behavior. Adding a long delay only to hide the loop does not solve a dependency problem.<\/p>\n<h3><span id=\"Permissions_and_the_working_directory\">Permissions and the working directory<\/span><\/h3>\n<p>When <code>User=<\/code> is defined, the application accesses the filesystem as that user. Directories need not only file permissions but also the <code>x<\/code> permission that allows traversal through parent directories. Inspect the path during diagnosis:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">namei -l \/srv\/example-app\/config.yml<\/code><\/pre>\n<p>Apply the narrowest permission correction to the specific file or directory you found. Making configuration world-readable is not a safe fix, especially when it contains credentials. Repeat the read test as the service account after the change.<\/p>\n<h3><span id=\"Do_not_confuse_FPM_CLI_and_queue_workers\">Do not confuse FPM, CLI and queue workers<\/span><\/h3>\n<p>In a web application, PHP-FPM workers and CLI cron or queue workers are separate processes. Restarting PHP-FPM web workers does not mean that a CLI queue worker stopped for the same reason. CLI work does not consume an FPM worker unless it makes an HTTP request.<\/p>\n<p>This distinction prevents you from diagnosing the wrong unit. For web request failures, inspect the FPM unit logs. For queues or scheduled work, inspect the relevant CLI process, cron entry or worker unit. If you are choosing a scheduler, the existing guide on <strong><a href=\"https:\/\/www.dchost.com\/blog\/en\/cron-vs-systemd-timers-the-friendly-way-to-ship-reliable-schedules-and-real-healthchecks\/\">Cron vs systemd Timers<\/a><\/strong> can help; a Timer job&#8217;s failure should still be investigated separately from a web service restart loop.<\/p>\n<div class=\"aiw-note aiw-note-example\">\n<p class=\"aiw-box-title\">Example scenario<\/p>\n<p>Assume that <code>app-worker.service<\/code> restarts every five seconds and the journal says that its configuration file cannot be found. The unit defines <code>WorkingDirectory=\/srv\/app\/current<\/code>, but a symbolic link was removed after a new release was deployed. The narrow fix is to restore the valid release path and the link target; adding only <code>RestartSec=60<\/code> would not repair the failure. This is a constructed example scenario used to explain the diagnosis.<\/p>\n<\/div>\n<h2><span id=\"When_should_you_change_Restart_settings\">When should you change Restart settings?<\/span><\/h2>\n<p><code>Restart=on-failure<\/code> restarts a service that exits with an error code or unexpected signal. <code>Restart=always<\/code> can restart it even after a normal exit. <code>RestartSec<\/code> sets the delay between attempts. These settings can be useful for long-running services, but if the application fails in the same way at every start, repeated attempts can fill the logs and hide the root cause.<\/p>\n<p>Fix the application error first. If you need to stop the loop temporarily during diagnosis, stop the service and inspect its journal instead of permanently changing the configuration:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl stop example-service.service\nsudo journalctl -u example-service.service --since &quot;10 minutes ago&quot; --no-pager<\/code><\/pre>\n<p>If you decide to change <code>Restart=<\/code>, back up the current file or override first. For example, <code>Restart=on-failure<\/code> may be a narrower choice when the service should restart only after an error, but the correct setting depends on the application&#8217;s expected operating model. Do not change a production service without recording the purpose and rollback command.<\/p>\n<p>You can save the currently rendered unit before editing it:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo sh -c &#039;systemctl cat example-service.service &gt; \/root\/example-service.service.backup&#039;<\/code><\/pre>\n<p>This backup records the main unit and its visible drop-ins. Also back up application configuration separately, and confirm where each file will be restored before making a data-changing edit.<\/p>\n<p>After many failed attempts, systemd may limit new starts. Once the root cause is fixed, clear the failed-state counter:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl reset-failed example-service.service\nsudo systemctl start example-service.service<\/code><\/pre>\n<p><code>reset-failed<\/code> only clears systemd&#8217;s failure state. If the application still exits, the service will become failed again. Observe at least several restart intervals after starting it.<\/p>\n<h2><span id=\"Apply_the_fix_and_verify_it\">Apply the fix and verify it<\/span><\/h2>\n<p>If you changed the unit or an override, systemd must read the new content:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl daemon-reload<\/code><\/pre>\n<p>Then start the service and perform several checks:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl restart example-service.service\nsudo systemctl is-active example-service.service\nsudo systemctl status example-service.service --no-pager -l\nsudo journalctl -u example-service.service --since &quot;2 minutes ago&quot; --no-pager<\/code><\/pre>\n<p>An <code>active<\/code> result from <code>is-active<\/code> is not enough by itself. Confirm that the application is listening on the expected port, that the required endpoint responds and that no new errors appear in the journal. For an externally accessed web application, application logs and the web server&#8217;s 4xx and 5xx records represent different layers. The existing guide on <strong><a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-ci-cd-to-a-vps-the-friendly-rsync-symlink-systemd-playbook-i-keep-reusing\/\">reading hosting server logs<\/a><\/strong> can help with that comparison.<\/p>\n<p>If the problem appeared during a new deployment, rolling back to the previous known-good release may be safer than editing the unit immediately. With versioned symbolic-link directories, confirm that the old target still exists and that its application files and configuration remain compatible. If the service is stable after rollback, investigate the new release&#8217;s dependencies as a separate maintenance step.<\/p>\n<p>For WordPress or Node.js applications, systemd is only the start layer. The application&#8217;s dependencies, release command and proxy settings also need review. If you are redesigning a deployment process, compare your current definition with an existing guide on <strong><a href=\"https:\/\/www.dchost.com\/blog\/en\/how-i-host-node-js-in-production-without-drama-pm2-systemd-nginx-ssl-and-zero-downtime-deploys\/\">PM2 and systemd deployments<\/a><\/strong>, and make sure two process managers are not managing the same application at once.<\/p>\n<h2><span id=\"Frequently_Asked_Questions\">Frequently Asked Questions<\/span><\/h2>\n<h3><span id=\"Why_does_a_service_restart_while_status_still_says_active\">Why does a service restart while status still says active?<\/span><\/h3>\n<p><code>status<\/code> is a point-in-time view. The command may run during the interval between two attempts. Use the journal to compare PIDs and the timestamps of each start.<\/p>\n<h3><span id=\"Can_a_service_restart_without_systemd_being_the_cause\">Can a service restart without systemd being the cause?<\/span><\/h3>\n<p>Yes. An application can exit by itself, a supervisor can send a signal, or the kernel can terminate it under memory pressure. Check the unit&#8217;s parent process, application logs and kernel journal.<\/p>\n<h3><span id=\"Should_I_disable_Restart_while_troubleshooting\">Should I disable Restart= while troubleshooting?<\/span><\/h3>\n<p>Not necessarily. Stopping the service temporarily is often less disruptive than changing the unit. If you do change the setting, back up the definition and restore it after the diagnosis.<\/p>\n<h3><span id=\"What_should_I_check_if_the_service_works_after_a_manual_start\">What should I check if the service works after a manual start?<\/span><\/h3>\n<p>Compare the manual shell with the unit&#8217;s <code>User<\/code>, <code>WorkingDirectory<\/code>, <code>ExecStart<\/code>, <code>PATH<\/code> and environment files. Also check whether the manual process is already occupying the application&#8217;s port.<\/p>\n<h2><span id=\"Final_checklist\">Final checklist<\/span><\/h2>\n<ul>\n<li>Confirm the real unit name and every active override file.<\/li>\n<li>Use <code>systemctl status<\/code> and <code>journalctl -u<\/code> to find the exit code, signal and first application error.<\/li>\n<li>Test <code>ExecStart<\/code>, the user, working directory, environment file and file permissions under the same conditions as the service.<\/li>\n<li>Check port conflicts, dependency readiness and memory pressure separately.<\/li>\n<li>Do not hide the loop with only <code>RestartSec<\/code> or <code>Restart=<\/code> changes before fixing the application error.<\/li>\n<li>Save a backup and rollback path before changing anything; if the unit changed, run <code>daemon-reload<\/code>, start the service in a controlled way and verify the journal.<\/li>\n<\/ul>\n<p>Your next step is to compare the service status with its last 200 journal lines over the same time period and isolate the first real error. Once you identify it, fix the layer responsible for that error rather than changing systemd blindly.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A systemd service that keeps restarting usually reflects an application, permission, port or environment failure. Learn how to find and verify the real cause.<\/p>\n","protected":false},"author":4,"featured_media":5802,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[182],"tags":[60,591,639,635,95],"class_list":["post-5805","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server","tag-linux","tag-server-troubleshooting","tag-service-management","tag-systemd","tag-vps"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5805","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5805"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5805\/revisions"}],"predecessor-version":[{"id":5807,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5805\/revisions\/5807"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5802"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5805"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5805"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5805"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}