sonic-buildimage/files/build_templates/telemetry.timer

[Unit]
Description=Delays telemetry container until SONiC has started
PartOf=telemetry.service

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

[Install]
WantedBy=timers.target sonic.target sonic-delayed.target
[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			`[Unit]`
			`Description=Delays telemetry 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=telemetry.service`
[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
			`[Timer]`
[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			`OnUnitActiveSec=0 sec`
[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			`OnBootSec=3min 30 sec`
			`Unit=telemetry.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 sonic.target sonic-delayed.target`