06.07.2017 17:18, Michael Chapman пишет: > 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.
Yes, Type=oneshot, because, if Type=simple, service will be active permanently in case of its start. But this is not what is needed here -- service should be started, then to check the updates of anti-virus software and then be successfully closed. Nothing more. Only one thing can impact here -- remote anti-virus server connection timeout. And if server connection timeout is set in wrong way, having a native systemd forced timeout for oneshot-services may be useful. > > >> 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. Ok, got that. > >> 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. In general way -- why not? For more twisted cases I can use OnFailure= directive here, I suppose. So, will try to play with TimeoutStartSec= directive. > > 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. Ok, thanks for clarifying and help! _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel