PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
For a systemd service, add a drop-in under /etc/systemd/system/example.service.d/override.conf with Restart=on-failure and an appropriate RestartSec= delay. Run systemctl daemon-reload, restart the unit, and verify it with systemctl status and journalctl. This recovers from crashes without treating an administrator’s intentional stop as a failure.
Use a systemd drop-in for crash recovery
Most Linux distributions use systemd to supervise long-running services. A unit’s restart policy belongs in its [Service] section. The usual setting for a daemon that should recover from unexpected failures is Restart=on-failure. The systemd project describes this as the recommended choice for long-running services because it attempts automatic recovery when an error occurs.
Do not edit the vendor unit in /usr/lib/systemd/system or /lib/systemd/system directly. Package upgrades can replace those files. A drop-in in /etc/systemd/system overrides selected settings while leaving the package-managed unit intact.
Minimal drop-in
# /etc/systemd/system/example.service.d/override.conf
[Service]
Restart=on-failure
RestartSec=5sReplace example.service with the real unit name. RestartSec=5s makes systemd wait five seconds before each restart attempt. Choose a delay that gives the process time to release resources and avoids a rapid crash loop; five seconds is an example, not a universal requirement.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application: attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Economical &Reusable: Built durable materials with a long-lasting battery,our CAGIWIRU air duster it's a sustainable alternative to disposable air cans.
Step-by-step configuration
1. Confirm the unit name and current state
- Find the service’s exact unit name. Names are case-sensitive and commonly end in
.service. - Check its current state and recent result:
systemctl status example.service - If the command says the unit does not exist, correct the name before creating a drop-in. A policy attached to a similarly named unit will not affect the process you intended to supervise.
2. Create the drop-in directory
sudo mkdir -p /etc/systemd/system/example.service.dThe directory name must be the complete unit name followed by .d. For api.service, use /etc/systemd/system/api.service.d.
3. Write the override
sudo editor /etc/systemd/system/example.service.d/override.confAdd:
[Service]
Restart=on-failure
RestartSec=5sSave the file with a .conf suffix. Keep these directives under [Service]; putting them under [Unit] or [Install] will not configure the service restart policy.
4. Reload unit definitions
sudo systemctl daemon-reloadSystemd reads unit files and drop-ins into memory. daemon-reload tells it to read the changed configuration. It does not itself start or restart the service.
5. Restart the service once
sudo systemctl restart example.serviceThis applies the new policy to the running unit. A restart requested by an administrator is an intentional operation; the policy is intended to govern what happens when the service later exits unexpectedly.
6. Verify state and logs
systemctl status example.service
journalctl -u example.service -bRead the status output for the active state, main process ID, exit result, and recent restart messages. The journal command shows messages for this unit since the current boot. Look for an exit code, signal, timeout, dependency error, missing file, permission problem, or environment difference that explains the crash.
What Restart=on-failure actually restarts
on-failure is selective. It asks systemd to start the service again when the supervised process ends in a way that indicates an error, rather than whenever it stops for any reason.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
- A non-zero exit code triggers a restart.
- Termination by a signal triggers a restart, subject to systemd’s documented exceptions for signals considered clean.
- An operation timeout triggers a restart.
- A watchdog timeout triggers a restart when watchdog monitoring is configured.
- An administrator-issued
systemctl stopdoes not trigger an automatic restart.
The distinction matters during maintenance. You can stop a service deliberately without systemd immediately bringing it back, while an unexpected failure can be recovered automatically.
Choosing among systemd restart modes
Use the least broad policy that matches the service’s intended lifecycle. The following comparison describes the practical distinction among commonly used modes; exact behavior can depend on the installed systemd version and the unit’s other settings.
| Setting | Restarts after | Clean exit remains stopped? | Typical use |
|---|---|---|---|
Restart=on-failure |
Non-zero exit, abnormal signal termination, operation timeout, or watchdog timeout, with documented clean-signal exceptions | Yes | Default choice for a long-running daemon that should recover from errors |
Restart=on-abnormal |
Abnormal termination such as qualifying signals, operation timeouts, or watchdog timeouts; it does not cover an ordinary non-zero exit | Yes | When only abnormal termination should be retried and an application’s error exit should remain stopped |
Restart=always |
Both clean and failed exits | No | A process that is expected to run continuously and must be relaunched even after a successful exit |
Restart=always is often surprising for command-style services. If the program exits normally after completing its job, systemd will start it again. Use it only when that behavior is intentional. For most persistent daemons, on-failure gives a safer boundary between a crash and a planned stop.
Set a restart delay that prevents a crash loop
Without a meaningful delay, a program that fails immediately can consume CPU, flood logs, repeatedly open network connections, or prevent an operator from intervening. RestartSec= controls how long systemd waits before scheduling the next attempt. Express the value with a unit such as 5s; select a delay based on startup time, dependency recovery, and the impact of repeated failures.
A delay does not fix the underlying fault. If the service fails because a configuration file is invalid, a port is already in use, a directory is missing, or credentials are unavailable, each attempt will likely fail again. Treat repeated restarts as a signal to investigate rather than as proof that the service is healthy.
Why systemd eventually stops retrying
Restarting indefinitely can turn one fault into an availability and diagnostics problem. Systemd rate-limits starts with StartLimitIntervalSec= and StartLimitBurst=. If too many starts or restart attempts occur within the configured interval, systemd can stop scheduling additional attempts. The unit may then be shown as failed even though Restart=on-failure is present.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
Inspect the limit before changing it
- Check the unit state and the last result:
systemctl status example.service - Read the complete service log:
journalctl -u example.service -b - Look for messages indicating that the start request was repeated too quickly or that the start limit was hit.
- Identify the first real failure in the log. Later “start request repeated too quickly” messages describe the rate limiter, not the original cause.
Raise limits only deliberately
If a service genuinely needs more attempts, configure StartLimitIntervalSec= and StartLimitBurst= in the unit’s [Unit] section through another drop-in, then reload systemd. Do not increase them merely to hide a bad binary, broken path, missing permission, or unavailable dependency. A higher limit can make a crash loop last longer and make logs harder to read.
After correcting the fault, clear the failed state and start the unit again:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemssudo systemctl reset-failed example.service
sudo systemctl start example.serviceUse reset-failed as a recovery step after the problem is addressed; it is not a substitute for fixing the cause.
Watchdog recovery for a hung process
A restart policy reacts to events systemd can observe. A process that is stuck but has not exited may not activate on-failure by itself. For applications that support systemd notifications, configure WatchdogSec= and have the service send keep-alive notifications before the deadline.
If the application misses the watchdog deadline, systemd treats it as a watchdog failure and terminates the service. With Restart=on-failure, Restart=on-watchdog, Restart=on-abnormal, or Restart=always, that event can lead to a restart. The setting alone is not enough: the program must implement the notification protocol and send heartbeats reliably.
When a watchdog is appropriate
- Use it for a service whose responsiveness can be measured and whose code can send keep-alive notifications.
- Choose a deadline longer than normal scheduling and I/O delays; an aggressive value can kill a busy but healthy process.
- Verify watchdog events in
systemctl statusand the journal before changing restart limits.
If the application cannot send notifications, rely on exit and operation timeouts that systemd can observe, or add health checking at another supervisory layer rather than enabling a watchdog that the process cannot satisfy.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
Docker containers: choose one supervisory layer
Containers have a separate Docker restart policy. Docker documents on-failure[:max-retries], which restarts a container when its main process exits with a non-zero code. The optional maximum limits how many retries Docker performs.
| Question | Docker restart policy | Host systemd policy |
|---|---|---|
| What it supervises | The container and its configured foreground process | A host service process, which may itself launch a container |
| Failure signal | Container exit with a non-zero code for on-failure |
Unit process exit, qualifying signal, timeout, or watchdog event according to the selected mode |
| Retry control | on-failure[:max-retries] |
Restart delay plus systemd start-rate limits |
| Logs to inspect | Container and Docker logs | journalctl -u unit.service and the service’s own logs |
| Dependency ordering | Container runtime configuration | Systemd unit dependencies and ordering |
Use one clear supervisory owner where possible. If Docker is restarting the container and systemd is restarting a wrapper service at the same time, two retry loops can obscure the cause and multiply load. Docker also notes that a process manager such as systemd or supervisor can manage a container or service when Docker’s policy does not fit the deployment. Whichever layer you choose, keep the application in the foreground so that the supervisor can observe its exit.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot a service that does not restart
The service was stopped intentionally
sudo systemctl stop example.service is an administrative action, not a crash. Restart=on-failure deliberately does not undo it. Start the unit again when maintenance is complete.
The program exits cleanly
A zero exit status is a clean exit. With on-failure, systemd leaves the unit stopped. If the program is supposed to run forever but exits successfully, fix its lifecycle or consider whether Restart=always is truly appropriate.
The unit was edited but systemd still uses the old settings
Run sudo systemctl daemon-reload after changing a drop-in. Then restart the unit. Check the effective configuration rather than relying on the file you edited:
systemctl cat example.serviceThis displays the main unit and its drop-ins, helping you detect a misspelled directory, an unexpected later override, or a directive in the wrong section.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
The restart limit was reached
Inspect status and the journal for start-rate-limit messages. Find and correct the first failure, then use systemctl reset-failed and start the service. Raising StartLimitBurst without diagnosing the crash only delays the same outcome.
The service starts manually but fails under systemd
Systemd may run the process with a different user, working directory, environment, path, or permission set than your interactive shell. Check the unit’s ExecStart=, referenced paths, file ownership, required directories, credentials, and dependencies. Use the exact command and account represented by the unit when reproducing the failure, and read the journal for the first permission or path error.
Recommended Free Tools
The application daemonizes itself
A supervisor must be able to observe the process it starts. If an application forks into the background and the tracked process exits, systemd may interpret that exit as a failure or lose visibility of the real worker. Configure the application to stay in the foreground when possible, and use a unit type and process model that match its behavior.
A dependency is unavailable
A restart can repeatedly fail while a required mount, network endpoint, socket, or supporting service is unavailable. Inspect the dependency’s status and the ordering relationships in the unit. Fix the dependency or its ordering rather than adding unlimited retries to the dependent service.
Test the policy safely
- Test in a staging system or during a maintenance window. An intentional production failure can interrupt users and trigger dependent systems.
- Record the service’s current status and recent journal entries so you can distinguish the test from an existing fault.
- Use a controlled test mode or a temporary configuration that exits non-zero, if the application provides one. Avoid killing a production process unless you have an approved rollback plan.
- Observe
systemctl status example.serviceimmediately after the failure. - Check
journalctl -u example.service -bfor the failure, the delay, and the subsequent start. - Confirm that an administrator-issued
systemctl stop example.serviceleaves it stopped, then start it normally. - Remove temporary test changes and verify the final drop-in with
systemctl cat example.service.
Operational checklist
- Put
Restart=on-failurein the unit’s[Service]section. - Set
RestartSec=to a delay that avoids a tight crash loop. - Use a drop-in under
/etc/systemd/system/<unit>.service.d/so package updates do not overwrite the policy. - Run
systemctl daemon-reloadafter every unit-file change. - Restart the unit once and verify both status and journal output.
- Remember that manual stops and clean exits are not failures under
on-failure. - Investigate start-rate-limit events before changing
StartLimitIntervalSec=orStartLimitBurst=. - Enable a watchdog only when the application sends the required keep-alive notifications.
- For containers, decide whether Docker or systemd owns retries and keep the supervised process in the foreground.
- Check the installed systemd version and current vendor documentation when using newer restart modes or options.
Example complete workflow
For a service called worker.service, the complete configuration and verification sequence is:
sudo mkdir -p /etc/systemd/system/worker.service.d
sudo editor /etc/systemd/system/worker.service.d/override.conf
# Add under [Service]:
# Restart=on-failure
# RestartSec=5s
sudo systemctl daemon-reload
sudo systemctl restart worker.service
systemctl status worker.service
journalctl -u worker.service -bIf the worker crashes with a non-zero status, systemd waits five seconds and attempts to start it again, subject to the unit’s start-rate limits. If you stop it with systemctl stop, systemd leaves it stopped. If it keeps failing, the journal and the rate-limit state tell you when to stop increasing retries and repair the worker itself.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
