Score:0

Warning: atop.service changed on disk. Run 'systemctl daemon-reload' to reload units

us flag

I was trying to change the atop log interval on CentOS 7 cPanel server from 600 to 60 seconds and tried editing the file /etc/system/system/multi-user.target.wants/atop.service (Environment="LOGINTERVAL=60") and did service atop restart, then edited /usr/share/atop/atop.daily(LOGINTERVAL=60) and did service atop restart but couldn't see that bringing intended result.

So, I tried editing /usr/lib/systemd/system/atop.service (Environment="LOGINTERVAL=60") which I saw in service atop status

After this when I checked service atop status I'm seeing a warning Warning: atop.service changed on disk. Run 'systemctl daemon-reload' to reload units.

[root@**** ~]# service atop status
Redirecting to /bin/systemctl status atop.service
● atop.service - Atop advanced performance monitor
   Loaded: loaded (/usr/lib/systemd/system/atop.service; enabled; vendor preset: disabled)
   Active: active (running) since *** ****-**-** **:**:** GMT; 29min ago
     Docs: man:atop(1)
  Process: 20856 ExecStartPost=/usr/bin/find ${LOGPATH} -name atop_* -mtime +${LOGGENERATIONS} -exec rm -v {} ; (code=exited, status=0/SUCCESS)
  Process: 20852 ExecStartPre=/bin/sh -c test -n "$LOGGENERATIONS" -a "$LOGGENERATIONS" -eq "$LOGGENERATIONS" (code=exited, status=0/SUCCESS)
  Process: 20851 ExecStartPre=/bin/sh -c test -n "$LOGINTERVAL" -a "$LOGINTERVAL" -eq "$LOGINTERVAL" (code=exited, status=0/SUCCESS)
 Main PID: 20855 (atop)
   CGroup: /system.slice/atop.service
           └─20855 /usr/bin/atop -w /var/log/atop/atop_******** 600

*
*
*
Warning: atop.service changed on disk. Run 'systemctl daemon-reload' to reload units.


[root@**** ~]# service atop restart
Redirecting to /bin/systemctl restart atop.service
Warning: atop.service changed on disk. Run 'systemctl daemon-reload' to reload units.


[root@**** ~]# service atop status
Redirecting to /bin/systemctl status atop.service
● atop.service - Atop advanced performance monitor
   Loaded: loaded (/usr/lib/systemd/system/atop.service; enabled; vendor preset: disabled)
   Active: active (running) since *** ****-**-** **:**:** GMT; 5s ago
     Docs: man:atop(1)
  Process: 25789 ExecStartPost=/usr/bin/find ${LOGPATH} -name atop_* -mtime +${LOGGENERATIONS} -exec rm -v {} ; (code=exited, status=0/SUCCESS)
  Process: 25785 ExecStartPre=/bin/sh -c test -n "$LOGGENERATIONS" -a "$LOGGENERATIONS" -eq "$LOGGENERATIONS" (code=exited, status=0/SUCCESS)
  Process: 25784 ExecStartPre=/bin/sh -c test -n "$LOGINTERVAL" -a "$LOGINTERVAL" -eq "$LOGINTERVAL" (code=exited, status=0/SUCCESS)
 Main PID: 25788 (atop)
   CGroup: /system.slice/atop.service
           └─25788 /usr/bin/atop -w /var/log/atop/atop_******* 600

*
*
*
Warning: atop.service changed on disk. Run 'systemctl daemon-reload' to reload units.

How should I proceed at this point? I didn't try running systemctl daemon-reload as I'm not sure what all changes it'll bring

in flag
It will reread the configuration files including your changes. Read the manual.
Score:1
jp flag

As explained in systemctl(1),

daemon-reload

Reload the systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.

However, you should not edit the units under /usr/lib/systemd/ as they are controlled by the RedHat Package Manager (RPM) and will be replaced by updates. See the correct paths from systemd.unit(5) Unit File Load Path.

Path Description
/etc/systemd/system System units created by the administrator
/usr/local/lib/systemd/system System units installed by the administrator
/usr/lib/systemd/system System units installed by the distribution package manager

You could place your setting as a dropin in /etc/systemd/system/atop.service.d/interval.conf:

[Service]
Environment=LOGINTERVAL=60

After that, yes, you need to run the sudo systemctl daemon-reload.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.