Skip to main content
+44 7575 472931[email protected]
HostaccentKnowledge BaseHosting, websites, SEO, and growth

How to Restart Apache on Ubuntu, CentOS and cPanel (2026)

How to restart Apache on Ubuntu, CentOS or cPanel in 2026: the exact commands, when to reload instead, and what to check if Apache won't start back up.

VPSWeb HostingBeginner Guide
How to restart Apache on Ubuntu, CentOS and cPanel servers, shown with terminal commands and the WHM Restart Services page

You edited a virtual host, installed a new SSL certificate or enabled a module, and nothing changes until the web server picks it up. Knowing how to restart apache takes about ten seconds to learn, but the wrong command on a busy server can drop every visitor in the middle of a checkout. This guide gives you the exact commands for Ubuntu, CentOS-family servers and cPanel/WHM, plus the habit that stops a routine restart from turning into downtime.

Quick Answer (as of September 2026): On Ubuntu or Debian, run sudo systemctl restart apache2. On CentOS, AlmaLinux or Rocky Linux, run sudo systemctl restart httpd. On a cPanel server, run /scripts/restartsrv_httpd or use WHM's Restart Services page. If you only changed configuration, use reload instead, because it applies the new settings without cutting live connections. Run apachectl configtest first, every time.

These commands come straight out of daily support work. On stacks like Hostaccent's, where Cloudflare sits in front of an Nginx reverse proxy and Apache handles the application layer behind it, our engineers resolve 20 to 30 client issues a day, and a fair number begin with a restart that went sideways. We wrote this so you can get it right yourself, first time. Everything below applies to Apache 2.4 and assumes SSH access with root or sudo rights.

Restart, Reload or Graceful: Which One Do You Actually Need?

For most configuration changes you need a reload, not a restart. A restart kills every Apache process and starts fresh. A reload (also called a graceful restart) re-reads the configuration and swaps workers over one by one as they finish their current requests.

That difference matters the moment you run a store. A full restart on a small server usually leaves the site unreachable for a second or two, and longer when Apache runs hundreds of workers. Any visitor mid-request in that window gets a failed page. A graceful reload avoids the gap, which is why the graceful restart vs reload apache question has a simpler answer than most guides admit.

On a systemd server, systemctl reload and a graceful restart are the same operation. As of September 2026, the stock apache2 unit on Ubuntu and the httpd unit on AlmaLinux and Rocky Linux both map reload to Apache's graceful signal, so sudo systemctl reload apache2 and sudo apachectl graceful do the same job with zero dropped connections.

| Action | Ubuntu / Debian command | CentOS / AlmaLinux / Rocky command | Drops live connections? | Use it when | |---|---|---|---|---| | Reload (graceful) | sudo systemctl reload apache2 | sudo systemctl reload httpd | No | You changed a vhost, SSL path, redirect or most directives | | Restart (hard) | sudo systemctl restart apache2 | sudo systemctl restart httpd | Yes, briefly | You switched MPM, upgraded Apache, or workers are stuck | | Graceful stop | sudo apachectl graceful-stop | sudo apachectl graceful-stop | No, but refuses new ones | You want open requests to finish before shutdown |

So when is a hard restart the right call? Three situations cover nearly every case:

  • You switched the multi-processing module, for example from prefork to event.
  • You upgraded the Apache package, or a module that needs a clean process.
  • Apache is misbehaving: workers are hung, memory keeps climbing, or requests go unanswered while the process claims to be running.

In that last case, a graceful reload keeps the broken parent process alive, which is exactly what you don't want.

A full restart also frees memory held by leaky modules, which can buy breathing room on a server that's slowly filling up. That treats the symptom, not the cause. If you're restarting to free RAM every few days, work through why a VPS keeps running out of RAM before it takes the site down at 3am.

Pro Tip: The official Apache guide to stopping and restarting the server explains the signal behind each command: TERM for an immediate stop, HUP for a hard restart, USR1 for a graceful one. You'll rarely send them by hand, but knowing them helps when a panel button doesn't behave as expected.

How to Restart Apache on Ubuntu and Debian

On Ubuntu and Debian the service is called apache2, and the reliable command is sudo systemctl restart apache2. Test the configuration first, then restart or reload, then confirm the service is healthy. The whole sequence takes under 30 seconds.

  1. Connect: ssh youruser@your-server-ip
  2. Test the configuration: sudo apache2ctl configtest. You want Syntax OK. If you see an error with a file name and line number, fix that line before going further.
  3. Apply the change. For a config edit, run sudo systemctl reload apache2. For a genuine restart, run sudo systemctl restart apache2.
  4. Check the service: sudo systemctl status apache2. Look for active (running) and a fresh start time.
  5. Confirm from outside: curl -I https://yourdomain.com should return 200 or your expected redirect.

Older tutorials still show sudo service apache2 restart. It works on current Ubuntu releases because service simply hands the request to systemd. It offers no benefit on a modern server, though, and scripts read better with one consistent style.

Debian-family systems add a detail most guides skip. Enable a site with a2ensite and the tool tells you to run systemctl reload apache2. Enable a module with a2enmod and it tells you to run systemctl restart apache2. That isn't random: a new site is just configuration, while some modules need a fresh process to load cleanly. Read the line the tool prints and follow it.

Keep two more commands handy. sudo systemctl enable apache2 makes Apache start after a reboot, and sudo systemctl is-enabled apache2 confirms it. Useful paths on Ubuntu:

  • Main config: /etc/apache2/apache2.conf
  • Site files: /etc/apache2/sites-available/
  • Error log: /var/log/apache2/error.log

The apachectl reference in the Apache documentation lists every option the wrapper supports.

Do I actually need a restart after editing .htaccess?

No. Apache reads .htaccess files on every request, so changes apply the moment you save. Restarting after an .htaccess edit does nothing useful and briefly interrupts traffic. If a change still isn't showing, the culprit is almost always a cache (browser, plugin or Cloudflare), not Apache. The same applies to most WordPress permalink and redirect changes made through a plugin, since those simply rewrite the .htaccess file.

Professional help available

Is this still affecting your store?

Tell us which customer journey is failing and what changed. We can investigate the application, payment, database, and hosting layers without moving your store.

Request store helpExplore eCommerce supportHosted elsewhere? One-time paid support is available after scope and price confirmation.

Restart httpd on CentOS, AlmaLinux and Rocky Linux

On Red Hat-family servers the service is called httpd, so the command is sudo systemctl restart httpd. Everything else follows the same test, apply, verify pattern as Ubuntu.

A quick reality check first. CentOS Linux 7 reached end of life on June 30, 2024, and CentOS 8 ended in December 2021. Most people who search "restart httpd centos" today are actually on AlmaLinux or Rocky Linux, the free RHEL rebuilds that replaced it. If you're still on CentOS 7, plan a move soon, because it no longer receives security patches. The commands are identical across all of them:

  • Test: sudo apachectl configtest or sudo httpd -t
  • Reload: sudo systemctl reload httpd
  • Restart: sudo systemctl restart httpd
  • Status and boot: sudo systemctl status httpd and sudo systemctl enable httpd

The file layout differs from Ubuntu, and that trips people up after a migration. The main config is /etc/httpd/conf/httpd.conf, extra files go in /etc/httpd/conf.d/, and errors land in /var/log/httpd/error_log. There's no a2ensite here; you add or remove .conf files directly and reload.

Across the 4,000+ sites Hostaccent has migrated since 2016, the step people most often get wrong after moving from Ubuntu to a RHEL-family box is exactly this. They edit a file in a folder Apache never reads, restart, and assume the restart failed. Run httpd -S to print the virtual hosts Apache actually loaded. If your domain isn't listed, the problem is the file location.

SELinux is the other gotcha. Move Apache to a non-standard port such as 8080 and a restart can fail with Permission denied: make_sock: could not bind to address. The config is fine; SELinux is blocking the port. Allow it with sudo semanage port -a -t http_port_t -p tcp 8080, then restart. Disabling SELinux also "works", but it removes a security layer you'll want later.

Insider Insight: When systemctl restart httpd returns instantly with no output, that only means systemd accepted the job. A config that loads but crashes a module can die two seconds later, so always follow up with systemctl status httpd and read the start time.

Restart Apache from WHM and cPanel

To restart Apache from WHM, log in as root, open Home » Restart Services » HTTP Server (Apache), and confirm. From the command line on a cPanel server, run /scripts/restartsrv_httpd, the same script the WHM button calls.

cPanel servers need their own rules. cPanel manages Apache through EasyApache 4, generates its own configuration, and watches the service with a monitor that checks roughly every 5 minutes by default. That changes three things.

Use cPanel's scripts rather than raw systemctl. A plain systemctl restart httpd also works, but the restartsrv scripts add cPanel's own pre-checks, log the result properly and print a clear success or failure message. That makes later troubleshooting far easier. The useful variations are:

  • /scripts/restartsrv_httpd for a normal restart
  • /scripts/restartsrv_httpd --graceful to apply changes without dropping connections
  • /scripts/restartsrv_httpd --status to check whether Apache is up

No SSH client handy? WHM's built-in Terminal (search "Terminal" in the sidebar) runs the same commands in your browser.

Don't edit httpd.conf by hand. On cPanel the main file is /etc/apache2/conf/httpd.conf. cPanel rebuilds it from templates, so manual edits vanish on the next rebuild. Put custom directives in WHM's Include Editor instead. The cPanel documentation for the rebuildhttpdconf script makes a point worth remembering: rebuilding the config does not restart Apache, so run restartsrv_httpd afterwards.

Stopping Apache doesn't keep it stopped. The service monitor notices and brings it back. For maintenance, disable Apache monitoring in WHM's Service Manager first, then switch it back on when you're done.

Can I restart Apache from my cPanel account on shared hosting?

No, and that's by design. On shared hosting one Apache process serves hundreds of accounts, so no single user can restart it. If your site is erroring, the cause is usually your account's limits, and our guide to shared hosting resource limit exceeded errors covers the fix. To restart Apache yourself you need root on your own server. Hostaccent's VPS plans give you full root access, so you can install cPanel/WHM or Plesk (licence sold separately) and run every command here. On Plesk, the restart button sits under Tools & Settings » Services Management.

What to Check When Apache Won't Come Back Up

When Apache refuses to start, the log almost always names the problem in its last few lines. Run sudo journalctl -u apache2 -n 50 --no-pager (or -u httpd) and read from the bottom up before changing anything.

A failed restart is a real outage: the old process is gone and the new one never started. Visitors see a connection error, or a 503 Service Unavailable response if a CDN sits in front. On a proxied stack it usually shows as a 502 instead, and our walkthrough on fixing a 502 Bad Gateway error with Nginx covers that side of the chain. The usual causes, most common first:

  1. Syntax error. AH00526: Syntax error on line 42 names the file and line. A missing </VirtualHost> is the classic.
  2. Port already in use. could not bind to address 0.0.0.0:80 means something else holds the port. sudo ss -tlnp | grep ':80' shows what.
  3. Missing SSL files. SSLCertificateFile: file ... does not exist or is empty means a certificate moved. Fix the path, or disable that one vhost to bring the rest back.
  4. Out of memory. dmesg | grep -i oom reveals a kernel kill. Restarting repeats the crash until you lower MaxRequestWorkers or add RAM.

Ignore AH00558: Could not reliably determine the server's fully qualified domain name. It's a warning that never stops Apache starting, so keep reading the log for the real cause.

Mistakes that turn a restart into an outage

Most restart downtime comes from habit, not Apache. Our engineers use a routine called the Test, Reload, Verify loop: run configtest, apply the change with a reload wherever possible, then check both systemctl status and a live curl request before closing the terminal. The loop takes about 15 seconds and prevents every mistake below.

  • Restarting at peak traffic. A hard restart during a sale drops every open request. Reload instead, or schedule real restarts for your quietest hour.
  • Restarting Apache to fix PHP. With PHP-FPM, a php.ini change needs sudo systemctl restart php8.3-fpm (match your version), not an Apache restart.
  • Rebooting the whole server. That takes one to three minutes instead of two seconds, and it hides the real cause.
  • Using restarts as a speed fix. Slow first bytes point to server response time, which our guide on fixing high TTFB in WordPress tackles properly. If pages error while Apache runs fine, check the database next with our guide to MySQL server has gone away errors.

Pro Tip: Before editing any Apache file, copy it: sudo cp site.conf site.conf.bak-$(date +%F). If a restart fails and you can't spot the problem within 5 minutes, restore the backup, get the site up, and debug calmly afterwards.

Your Next Step: A Server Where Restarts Are Never a Guessing Game

Now that you know a reload beats a restart for almost every config change, you can run the Test, Reload, Verify loop on any server you control. If you'd rather do it with engineers behind you, Hostaccent has supported 10,000+ clients since 2016 with 24/7 human help. The Basic plan at $7.99/mo (renewing at $7.99/mo) gives you full root access, NVMe storage, free 30 Gbps DDoS protection and a 99.99% uptime guarantee. One honest note: no control panel licence is included, so budget separately if you want WHM. Ready to practise how to restart apache on your own box? Start on the Basic VPS plan, backed by a 30-day money-back guarantee.

Frequently Asked Questions

How to restart Apache without downtime?

Use a graceful reload instead of a restart:

  • Ubuntu: sudo systemctl reload apache2
  • AlmaLinux or Rocky Linux: sudo systemctl reload httpd
  • cPanel: /scripts/restartsrv_httpd --graceful

A graceful reload re-reads the configuration and replaces worker processes only after they finish their current requests, so visitors never see an error. It covers vhost edits, SSL changes and most directives. You still need a full restart after switching MPM or upgrading Apache itself.

What is the difference between Apache reload and restart?

A restart stops every Apache process and starts new ones, which briefly drops open connections, usually for a second or two. A reload keeps the parent process running, re-reads the configuration, and swaps workers over gradually, so no connections are lost. On modern systemd distributions, reload is the same as Apache's graceful restart. Use reload for configuration changes. Use a full restart when workers are stuck, memory is leaking, or you've changed modules or the Apache package.

Why won't Apache start after a restart?

The most common causes are a syntax error in a config file, another process holding port 80 or 443, a missing SSL certificate file, the server running out of memory, or SELinux blocking a custom port. Run sudo journalctl -u apache2 -n 50 (or -u httpd) and read the last lines, which almost always name the file and line at fault. Fix that single issue, run configtest to confirm it passes, then start the service again.

Do I need to restart Apache after installing an SSL certificate?

You need to reload it, not fully restart it. Apache reads certificate files only when it loads its configuration, so a new or renewed certificate isn't served until you run sudo systemctl reload apache2 or sudo systemctl reload httpd. Certbot's Apache plugin reloads the server for you at renewal, and on cPanel servers AutoSSL does the same. If the old certificate still appears after reloading, check that the vhost points to the new certificate path.

How often should I restart Apache?

You shouldn't need to restart Apache on a schedule at all. A healthy server can run for months between restarts, reloading only when configuration changes. According to Hostaccent's support team, which resolves 20 to 30 client issues every day, servers that "need" a weekly restart almost always hide an underlying problem, such as too many workers for the available RAM or a leaking module. Fix that root cause, and routine restarts stop being necessary.

Professional help available

Checkout or store still affected? Bring in an eCommerce specialist.

Tell us which customer journey is failing and what changed. We can investigate the application, payment, database, and hosting layers without moving your store.

  • No hosting transfer required
  • Scope confirmed before paid work
  • No changes before your approval
Request store helpExplore eCommerce supportHosted elsewhere? One-time paid support is available after scope and price confirmation.
Reviewed by

Hostaccent Editorial Team

Reviewed for technical accuracy and clarity before publication.

Last updated

Sep 29, 2026

HostAccent Editorial Team publishes practical hosting guides, operations checklists, and SEO-focused tutorials for businesses building international web presence.

Discussion

Have a question or tip about this topic? Share it below — your comment will appear after review.

Your email stays private and is only used for moderation.

Write for the Community

Have a tutorial, tip, or insight to share? Get published on the Hostaccent Blog with your name, bio, and website link.

Become a Contributor

Need a faster setup for this workflow?