On Thu, 6 Jul 2017, Mikhail Kasimov wrote:
Hello!'ve got an interesting trouble on timer-activated service -- 'systemctl status' returns a log with 'Activating (start)' status: [1] ========== k_mikhail@linux-mk500:~> systemctl status vba32update.service ● vba32update.service - VBA32 Anti-Virus Update Service Loaded: loaded (/etc/systemd/system/vba32update.service; disabled; vendor preset: disabled) Active: activating (start) since Чтв 2017-07-06 15:32:35 EEST; 35min ago Main PID: 6214 (vbaupdx) Tasks: 1 (limit: 512) CGroup: /system.slice/vba32update.service └─6214 ./vbaupdx http://anti-virus.by/beta/update Июл 06 15:32:35 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 06 15:32:35 linux-mk500 vbacl[6214]: Vba32 console scanner update process started Июл 06 15:32:35 linux-mk500 vbacl[6214]: Reading configuration options from ./vbacl.ini Июл 06 15:32:35 linux-mk500 vbacl[6214]: Using direct connection for update k_mikhail@linux-mk500:~> ========== Simultaneously: [2] ========== k_mikhail@linux-mk500:~> systemctl list-units -t timer UNIT LOAD ACTIVE SUB DESCRIPTION vba32update.timer loaded active running Runs VBA32 Update Hourly ========== And that is normal. But 35 minutes for activating service is too long, as for me.
Is this a Type=oneshot service?It's a bit weird, but Type=oneshot services are not considered to be fully started until the ExecStart= command has exited. Until that time they're still "activating".
You may be better off making the service Type=simple instead. A Type=simple service is fully started as soon as it has spawned the ExecStart= command.
And, by default, there is no way for user\admin to get message, that there is a problem with activating of some service, except periodical 'systemctl list-units -t timer' command output (in current described case). And systemd logs contain no interesting info, which can be useful to investigate the problem and its reasons, because there are no explicit error-messages for such case. So, my questions are: ================= 1) What is the correct systemd's behavior in such case?
If this is a Type=oneshot service, systemd is working as intended here.
2) What is systemd's timeout by default for service activation (timer-activated, socket-activated)? If it is documentened, please, give me a hint.
By default, Type=oneshot services don't have a start timeout.
3) If systemd's timeout from 2) is present, how can it be managed by user\admin? E.g. after 10 minutes of 'Activating (start)', service gets FAILED state with putting this info to systemd log, of course (something like "systemd[1] fails to start foobar.service[PID] by timeout. ExitCode:<number>").
If you do add a TimeoutStartSec= to a Type=oneshot unit, this will force the unit to be stopped (by killing the process) after that time. That's probably not what you want.
For a Type=simple service, the default TimeoutStartSec= is set in /etc/systemd/system.conf. It will be 90 seconds unless you've changed it.
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
