sonic-buildimage/files/build_templates/snmp.timer

[Unit]
Description=Delays snmp container until SONiC has started
PartOf=snmp.service
After=swss.service

[Timer]
OnUnitActiveSec=0 sec
OnBootSec=3min 30 sec
Unit=snmp.service

[Install]
WantedBy=timers.target swss.service sonic-delayed.target
Enable sairedis counter thread in 3 minutes after SONiC was started (#1805) 2018-06-22 21:53:51 -05:00			`[Unit]`
			`Description=Delays snmp container until SONiC has started`
[services] introduce sonic.target (#5705) - Why I did it Group all SONiC services together and able to manage them together. Will be used in config reload command as much simpler and generic way to restart services. - How I did it Add services to sonic.target - How to verify it Together with Azure/sonic-utilities#1199 config reload -y Signed-off-by: Stepan Blyshchak <stepanb@nvidia.com> 2021-02-25 06:26:24 -06:00			`PartOf=snmp.service`
[build_templates]: Start SNMP timer after SWSS service (#6195) Fixes #5663 - Why I did it It's currently possible for the SNMP timer to conflict with config reload (specifically if the timer triggers while config reload is stopping the SWSS service). config reload triggers SWSS to shutdown, which causes SNMP to shutdown, which conflicts with the SNMP timer causing SNMP to startup. See the linked issue for more details. - How I did it Including the After ordering dependency forces the SNMP timer to wait until SWSS finishes stopping, preventing the conflict. If there is an ordering dependency between two units (e.g. one unit is ordered After another), if one unit is shutting down while the other is starting up, the shutdown will always be ordered before the startup. In this case, that means that the SNMP timer is forced to wait for the SWSS shutdown to complete. Only then can the SNMP timer proceed. See here for more details. It's important to note that the After dependency will not cause SWSS to be started when the SNMP timer fires (assuming that SWSS has not yet been started). The existing Requisite dependency in the SNMP service will also not cause SWSS to be started, instead it will cause the SNMP service to fail if SWSS is not active. Signed-off-by: Lawrence Lee <lawlee@microsoft.com> 2020-12-16 18:39:14 -06:00			`After=swss.service`
Enable sairedis counter thread in 3 minutes after SONiC was started (#1805) 2018-06-22 21:53:51 -05:00
			`[Timer]`
[services] make snmp.timer work again and delay telemetry.service (#3742) Delay CPU intensive services at boot - How I did it Made snmp.timer work and add telemetry.timer. But this is not enough because it breaks the existing snmp dependency on swss. So, in this solution snmp timer is a wanted by swss service, but since OnBootSec timer expires only once it will not trigger snmp service, so I added line "OnUnitActiveSec=0 sec" which will start snmp service based on the last time it was active. On boot only OnBootSec will expire, on swss start/restarts only second timer will expire immediately and trigger snmp service. However, snmp service will not stop after "systemctl stop snmp" because of the second timer which will always expire when snmp service because unavailable. So there is a conflict which will be handled by systemd if we add "Conflicts=" line to both snmp.service and snmp.timer. So during boot: snmp does not start by default swss starts and starts snmp timer OnUnitActiveSec=0 does not expire since there is no snmp active OnBootSec expires and starts snmp service and snmp timer gets stopped During "systemctl restart swss" snmp stops because of Requisite on swss snmp unblocks snmp timer from running swss starts and starts snmp timer OnUnitActiveSec=0 expires imidiately and start snmp which stops snmp timer During "systemctl stop snmp" stop of snmp service unblocks snmp timer but no one starts the timer so it is not started by "OnUnitActiveSec=0" 2019-12-16 11:07:05 -06:00			`OnUnitActiveSec=0 sec`
Enable sairedis counter thread in 3 minutes after SONiC was started (#1805) 2018-06-22 21:53:51 -05:00			`OnBootSec=3min 30 sec`
			`Unit=snmp.service`

			`[Install]`
Grouping delayed services under a target for config reload checks (#7846) #### Why I did it Create a target for delayed service timers. Few services in sonic have delayed to speed up the bring up of the system and essential services. However there is no way to track when they start. This will be a problem when executing config reload as config reload expects all services to be up. Hence grouped all the timers that trigger the delayed services under one target so that they could be tracked in 'config reload' command #### How I did it Created delay.target service and add created dependency on the delayed targets. 2021-06-21 13:55:02 -05:00			`WantedBy=timers.target swss.service sonic-delayed.target`