Re: [systemd-devel] Timeout for 'Activating (start)' status
11.07.2017 17:13, Lennart Poettering пишет: > On Tue, 11.07.17 14:46, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >> Or, please, give a hint how service, which works in 'start -> do >> something->exit' scheme (so this is oneshot type, as I understand: >> https://www.freedesktop.org/software/systemd/man/systemd.service.html : >> "Behavior of |oneshot| is similar to |simple|; however, it is expected >> that the *process has to exit* before systemd starts follow-up units."), >> be forced to be restarted on its failure. > There's an RFE issue about adding Restart= for Type=oneshot too: > > https://github.com/systemd/systemd/issues/2582 > > Would be happy to take patches that make that work... Thanks for info! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timeout for 'Activating (start)' status
Hello! 11.07.2017 13:49, Lennart Poettering пишет: > On Thu, 06.07.17 16:43, Mikhail Kasimov (mikhail.kasi...@gmail.com) 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.timerloaded active running Runs VBA32 Update Hourly >> == >> >> And that is normal. But 35 minutes for activating service is too long, >> as for me. > Well, process 6214 is still around as you can see above, and since you > appear to have set Type=oneshot, that's really the right behaviour: > the unit will be starting until process 6214 decides. if 35min is too > long for that process, then this indicates that something is wrong in > that process, and systemd is just the messenger. > > If you want to place a timeout on starting use TimeoutStartSec= and > set it to whatever you like. If the timeout is then hit, systemd will > abort the process and log about this and place the service in a failed > state. No problem at all. I 've modified vba32update.service by adding TimeoutStarSec= and Restart=on-failure directives, because I wanna force to restart service automatically if it gets 'failed' status. [1] k_mikhail@linux-mk500:~> cat vba32update.service [Unit] Description=VBA32 Anti-Virus Update Service Requires=network.target Wants=network-online.target After=network.target network-online.target [Service] Type=oneshot WorkingDirectory=/opt/vba/vbacl/ ExecStart=/opt/vba/vbacl/vbacl --update EnvironmentFile=/opt/vba/vbacl/vbacl.ini TimeoutStartSec=120s Restart=on-failure [Install] WantedBy=multi-user.target Then attempt to vba32update.service: k_mikhail@linux-mk500:~> systemctl status -l vba32update.service ● vba32update.service - VBA32 Anti-Virus Update Service Loaded: error (Reason: Invalid argument) Active: activating (start) since Вто 2017-07-11 02:48:54 EEST; 11h ago Main PID: 22712 (vbaupdx) CGroup: /system.slice/vba32update.service └─22712 ./vbaupdx http://anti-virus.by/beta/update Июл 11 02:48:54 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 11 02:48:54 linux-mk500 vbacl[22712]: Vba32 console scanner update process started Июл 11 02:48:54 linux-mk500 vbacl[22712]: Reading configuration options from ./vbacl.ini Июл 11 02:48:54 linux-mk500 vbacl[22712]: Using direct connection for update Июл 11 14:22:19 linux-mk500 systemd[1]: vba32update.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. Brilliant. Let's go to man-page https://www.freedesktop.org/software/systemd/man/systemd.service.html on Restart= directive text and we can see _no_ _info_ about such restriction. Lack-of-info on documentaion. Or, please, give a hint how service, which works in 'start -> do something->exit' scheme (so this is oneshot type, as I understand: https://www.freedesktop.org/software/systemd/man/systemd.service.html : "Behavior of |oneshot| is similar to |simple|; however, it is expected that the *process has to exit* before systemd starts follow-up units."), be forced to be restarted on its failure. > > But systemd is not a magic wand that can make hanging processes > suddenly work... I understand it. I just try to find the way how to resolve my usecase problem by options, which systemd provides. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timeout for 'Activating (start)' status
Hello, everyone! 06.07.2017 19:17, Mikhail Kasimov пишет: > > 06.07.2017 19:12, Mikhail Kasimov пишет: >> 06.07.2017 18:27, Michael Chapman пишет: >>> On Fri, 7 Jul 2017, Mikhail Kasimov wrote: >>>> 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.timerloaded 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. >>> I still think you want Type=simple there. A Type=simple service can >>> exit when it's finished doing whatever it needs to do. The service >>> will then transition back to its inactive state. >>> >>> Really, I think the only time Type=oneshot should be used is when you >>> have a _sequence_ of units, where one unit shouldn't be started until >>> the previous one has finished. You don't have that here. >> Ok, here is Type=oneshot. And we can see two sessions of our service >> (at1 7:06:52 and 18:06:57): >> == >> [1] >> Июл 06 17:06:52 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update >> Service... >> Июл 06 17:06:52 linux-mk500 vbacl[8058]: Vba32 console scanner update >> process started >> Июл 06 17:06:52 linux-mk500 vbacl[8058]: Reading configuration options >> from ./vbacl.ini >> Июл 06 17:06:52 linux-mk500 vbacl[8058]: Using direct connection for update >> Июл 06 17:06:56 linux-mk500 vbacl[8058]: Current di
Re: [systemd-devel] Timeout for 'Activating (start)' status
06.07.2017 19:12, Mikhail Kasimov пишет: > > 06.07.2017 18:27, Michael Chapman пишет: >> On Fri, 7 Jul 2017, Mikhail Kasimov wrote: >>> 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.timerloaded 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. >> I still think you want Type=simple there. A Type=simple service can >> exit when it's finished doing whatever it needs to do. The service >> will then transition back to its inactive state. >> >> Really, I think the only time Type=oneshot should be used is when you >> have a _sequence_ of units, where one unit shouldn't be started until >> the previous one has finished. You don't have that here. > Ok, here is Type=oneshot. And we can see two sessions of our service > (at1 7:06:52 and 18:06:57): > == > [1] > Июл 06 17:06:52 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update > Service... > Июл 06 17:06:52 linux-mk500 vbacl[8058]: Vba32 console scanner update > process started > Июл 06 17:06:52 linux-mk500 vbacl[8058]: Reading configuration options > from ./vbacl.ini > Июл 06 17:06:52 linux-mk500 vbacl[8058]: Using direct connection for update > Июл 06 17:06:56 linux-mk500 vbacl[8058]: Current dir is ./ > Июл 06 17:06:56 linux-mk500 vbacl[8058]: Start update from > http://anti-virus.by/beta/update > Июл 06 17:06:56 linux-mk500 vbacl[8058]: Receiving file list > Июл 06 17:06:56 linux-mk500 vbacl[8058]: File list received > Июл 06 17:06:56 linux-mk500 vbacl[8058]: Update is not needed > Июл 06 17:06:57 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update > Service. > > [2
Re: [systemd-devel] Timeout for 'Activating (start)' status
06.07.2017 18:27, Michael Chapman пишет: > On Fri, 7 Jul 2017, Mikhail Kasimov wrote: >> 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.timerloaded 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. > > I still think you want Type=simple there. A Type=simple service can > exit when it's finished doing whatever it needs to do. The service > will then transition back to its inactive state. > > Really, I think the only time Type=oneshot should be used is when you > have a _sequence_ of units, where one unit shouldn't be started until > the previous one has finished. You don't have that here. Ok, here is Type=oneshot. And we can see two sessions of our service (at1 7:06:52 and 18:06:57): == [1] Июл 06 17:06:52 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 06 17:06:52 linux-mk500 vbacl[8058]: Vba32 console scanner update process started Июл 06 17:06:52 linux-mk500 vbacl[8058]: Reading configuration options from ./vbacl.ini Июл 06 17:06:52 linux-mk500 vbacl[8058]: Using direct connection for update Июл 06 17:06:56 linux-mk500 vbacl[8058]: Current dir is ./ Июл 06 17:06:56 linux-mk500 vbacl[8058]: Start update from http://anti-virus.by/beta/update Июл 06 17:06:56 linux-mk500 vbacl[8058]: Receiving file list Июл 06 17:06:56 linux-mk500 vbacl[8058]: File list received Июл 06 17:06:56 linux-mk500 vbacl[8058]: Update is not needed Июл 06 17:06:57 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. [2] Июл 06 18:06:57 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 06 18:06:57 linux-mk500 vbacl[8842]: Vba32 console scanner update process started Июл 06 18:06:57 linux-mk500 vbacl[8842]: Reading configuration options from ./vbacl.ini Июл 06 18:06:57 linux-mk500 vbacl[8842]: Using direct connection for update Июл 06 18:07:00 linux-mk500 vbacl[8842]: Current d
Re: [systemd-devel] Timeout for 'Activating (start)' status
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.timerloaded 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:"). > > 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
[systemd-devel] Timeout for 'Activating (start)' status
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.timerloaded active running Runs VBA32 Update Hourly == And that is normal. But 35 minutes for activating service is too long, as for me. 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? 2) What is systemd's timeout by default for service activation (timer-activated, socket-activated)? If it is documentened, please, give me a hint. 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:"). Thanks for your assistance! OS: openSUSE 42.2, systemd v.228. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to stop service by timer
Hello! How does your service work from 10:00 till 18:45 -- with any interruption during this time-range, or constantly? I'm asking, because I'm not sure if RuntimeMaxSec= directive (https://www.freedesktop.org/software/systemd/man/systemd.service) is acceptable here|. | So, you start your service by timer on 10:00 and due to RuntimeMaxSec=31500 in [Service] section of your service, service should stop on 18:45:00 it should be stopped with exit code 0. But if it happens on 18:45:01 -- will stop with exit with failure state. In that case, if FailureAction= directive (https://www.freedesktop.org/software/systemd/man/systemd.service) for your service is set, it will be executed. 12.09.2016 21:13, Федор Короткий пишет: Hi, We are trying to setup a service that runs every day from 10:00 to 18:45. Starting is not a problem, we just used timer. But our solution for stopping the service seems ugly. We have second service with Type=oneshot which runs "systemctl stop first.service" at 18.45(by using second timer). Is there a better way to achieve this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timer: time format
23.08.2016 16:55, arnaud gaboury пишет: On Tue, Aug 23, 2016 at 3:52 PM, arnaud gaboury wrote: On Tue, Aug 23, 2016 at 3:39 PM, Michael Chapman wrote: On Tue, 23 Aug 2016, arnaud gaboury wrote: I am really sorry for this post as this may sound like a trivial one, but honestly the timer topic is difficult to understand for me (at least the time format). I am looking to run a service twice a day, never mind the time. I understand I must use OnCalendar, but I have no idea for the rest. You may find it more convenient to use the other On* directives. For example: OnBootSec=1h OnUnitActiveSec=12h Thank you for all these answers. In fact, without having a look at my emails, I finally found this solution (which is correct accordingly what I read): OnUnitActiveSec=12h Do I have to add: Persistent=true NO "Persistent=true" is needed, when critical task executing was missed in some reason. By default Persistent=no, so, you may not to specify it in your .timer file explicitly. Otherwise, yes, you need to specify Persistent=true in your .timer file explicitly. and an OnBootSec entry ? It's useful, if you wish to execute your task, when computer (server) is after reboot or being off. will trigger the associated service an hour after booting the system, and every 12 hours therafter. Take a look at the RandomizedDelaySec= and AccuracySec= directives too, to further specify how accurate the timer should be. - Michael -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timer: time format
Hello! Due to system.time (https://www.freedesktop.org/software/systemd/man/systemd.time.html) we have a construction "year-month-day hour:minute:second". Hence, OnCalendar=*:12:00 construction means ' run my service at any hour on 12th minute on 00 seconds'. To specify 'running every 12 hours ', use, for example, OnCalendar=00,12:00:00 or OnCalendar=*-*-* 00,12:00:00, which is equal. Or, if you need to run your service twice on specified day (for example): OnCalendar=Mon,Fri 00,12:00:00 (on Monday and Friday at 00 and 12 hours). Something like this way... 23.08.2016 12:38, arnaud gaboury пишет: I am really sorry for this post as this may sound like a trivial one, but honestly the timer topic is difficult to understand for me (at least the time format). I am looking to run a service twice a day, never mind the time. I understand I must use OnCalendar, but I have no idea for the rest. I was thinking of OnCalendar=*:12:00 for running every 12 hours. Is it right (or will it run every day at noon) ? Thank you for help ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to encrypt journalctl metadata
Ok, thanks for making this aspect more clear! 18.08.2016 18:00, Lennart Poettering пишет: On Thu, 18.08.16 15:55, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: Hello! Personally, don't we have philosophical contradiction here? -- Journal is positioned as syslog alternative with more wide functionality, but in current case we offer to turn off whole journal to make functionality only as transport. No problem, but is RFE to incorporate ExcludeMetaData= parameter to /journald.conf acceptable here? No, we explicitly never had the goal to be as featureful as rsyslog or syslog-ng. The journal has a different feature set, and puts a strong emphasis on structured log events, implicit metadata and indexed lookups. It's completely OK if people look for a different feature set and it's easy to install a different logger side-by-side to journald and it will get all the same data the journal gets. Quite frankly, I am very much against turning the journal into something that processes log data at collection time with matches and regexes and suchlike. If you don't want the journal to collect metadata, then the journal is probably not the tool you want, but something else, and in that case turn stroage in it off, and just use it as a multiplexer that collects data from all the various sources and passes it to the syslog implementation of your choice. Of course, you'll lose all the journal hook-up in tools like "systemctl status" if you don#t use the journal, but I think that's a fair deal. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to encrypt journalctl metadata
Hello! Personally, don't we have philosophical contradiction here? -- Journal is positioned as syslog alternative with more wide functionality, but in current case we offer to turn off whole journal to make functionality only as transport. No problem, but is RFE to incorporate ExcludeMetaData= parameter to /journald.conf acceptable here? Syntax: ExcludeMetaData=[meta[=keyword1,keyword2,...keywordN]] For current usecase: ExcludeMetaData=_CMDLINE. Or, to make it more flexible: ExcludeMetaData=_CMDLINE=[keyword1],[keyword2],...[keywordN]. E.g.: === ExcludeMetaData=_CMDLINE=pass,password ExcludeMetaData=_UID=1000,k_mikhail === to exclude defined parameters. Or: === ExcludeMetaData=_CMDLINE ExcludeMetaData=_UID === to exclude common (whole) metadata. Acceptable? 18.08.2016 14:25, Lennart Poettering пишет: On Wed, 17.08.16 12:10, Divya Thaluru (divya.thal...@gmail.com) wrote: Hi, Journalctl stores metadata like "_UID,_GID,_CMDLINE,_SYSTEMD_CGROUP etc…" for each message. Is there any way, can we encrypt metadata (commandline info) so sensitive information wont be stored. If encryption of metadata is not possible, can we disable collecting the metadata? The journal does not support encryption, and it does not disable collecting metadata implicitly. You may however turn off all storage by the journal by setting Storage=none in journald.conf. In that mode you may optionally connect another syslog daemon to it via ForwardToSyslog=yes, which implements the features you are looking for. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about OnUnitInactiveSec= directive
Seems, AccuracySec=1us parameter resolves this problem indeed: = Июл 09 10:55:30 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 09 11:00:30 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 09 11:00:32 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 09 11:05:32 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 09 11:05:35 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 09 11:10:35 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... = Haven't read about AccuracySec parameter in man-page carefully. :( Resolved. Thank you again! 09.07.2016 08:23, Andrei Borzenkov пишет: 09.07.2016 01:37, Mikhail Kasimov пишет: Hello! Have a .timer service like: == [Unit] Description=Runs VBA32 Update Hourly Requires=timers.target [Timer] OnBootSec=2min OnUnitInactiveSec=1h [Install] WantedBy=timers.target == to run vba32update.service in 1 hour after previous update-session is over (OnUnitInactiveSec=1h). From man-page: "|OnUnitInactiveSec=| defines a timer relative to when the unit the timer is activating was last deactivated." Ok, here is log-snippet: == Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update process started Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options from ./vbacl.ini Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for update Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./ Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from http://anti-virus.by/update Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. ... We see 22:05:02 (end of update-session) --> 23:05:13 (start of next update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start of next update-session) --> 00:05:24 (end of update-session) --> 01:05:50 (start of next update-session) --> 01:05:55 (end of update-session). Question: Why time of new update-session is *not* equal to time of end of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h = 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach this precise coincidence? Please check with "systemctl status" or "systemctl show" when unit was actually deactivated. Also see "AccuracySec" timer parameter. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question about OnUnitInactiveSec= directive
Hello! Have a .timer service like: == [Unit] Description=Runs VBA32 Update Hourly Requires=timers.target [Timer] OnBootSec=2min OnUnitInactiveSec=1h [Install] WantedBy=timers.target == to run vba32update.service in 1 hour after previous update-session is over (OnUnitInactiveSec=1h). From man-page: "|OnUnitInactiveSec=| defines a timer relative to when the unit the timer is activating was last deactivated." Ok, here is log-snippet: == Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update process started Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options from ./vbacl.ini Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for update Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./ Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from http://anti-virus.by/update Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 08 23:05:13 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 08 23:05:13 linux-mk500 vbacl[15289]: Vba32 console scanner update process started Июл 08 23:05:13 linux-mk500 vbacl[15289]: Reading configuration options from ./vbacl.ini Июл 08 23:05:13 linux-mk500 vbacl[15289]: Using direct connection for update Июл 08 23:05:17 linux-mk500 vbacl[15289]: Current dir is ./ Июл 08 23:05:17 linux-mk500 vbacl[15289]: Start update from http://anti-virus.by/update Июл 08 23:05:17 linux-mk500 vbacl[15289]: Receiving file list Июл 08 23:05:17 linux-mk500 vbacl[15289]: File list received Июл 08 23:05:17 linux-mk500 vbacl[15289]: Update is not needed Июл 08 23:05:17 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 09 00:05:20 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 09 00:05:20 linux-mk500 vbacl[16050]: Vba32 console scanner update process started Июл 09 00:05:20 linux-mk500 vbacl[16050]: Reading configuration options from ./vbacl.ini Июл 09 00:05:20 linux-mk500 vbacl[16050]: Using direct connection for update Июл 09 00:05:24 linux-mk500 vbacl[16050]: Current dir is ./ Июл 09 00:05:24 linux-mk500 vbacl[16050]: Start update from http://anti-virus.by/update Июл 09 00:05:24 linux-mk500 vbacl[16050]: Receiving file list Июл 09 00:05:24 linux-mk500 vbacl[16050]: File list received Июл 09 00:05:24 linux-mk500 vbacl[16050]: Update is not needed Июл 09 00:05:24 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 09 01:05:50 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update Service... Июл 09 01:05:50 linux-mk500 vbacl[16528]: Vba32 console scanner update process started Июл 09 01:05:50 linux-mk500 vbacl[16528]: Reading configuration options from ./vbacl.ini Июл 09 01:05:50 linux-mk500 vbacl[16528]: Using direct connection for update Июл 09 01:05:55 linux-mk500 vbacl[16528]: Current dir is ./ Июл 09 01:05:55 linux-mk500 vbacl[16528]: Start update from http://anti-virus.by/update Июл 09 01:05:55 linux-mk500 vbacl[16528]: Receiving file list Июл 09 01:05:55 linux-mk500 vbacl[16528]: File list received Июл 09 01:05:55 linux-mk500 vbacl[16528]: Update is not needed Июл 09 01:05:55 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. == We see 22:05:02 (end of update-session) --> 23:05:13 (start of next update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start of next update-session) --> 00:05:24 (end of update-session) --> 01:05:50 (start of next update-session) --> 01:05:55 (end of update-session). Question: Why time of new update-session is *not* equal to time of end of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h = 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach this precise coincidence? Thanks! Platform: x64, openSUSE Leap 42.1, systemd 210. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mounting the root file system using systemd unit file
Hello! /etc/systemd/system/root.mount change to /etc/systemd/system/-.mount As I remember, unit naming depends on path, where partition is to be mounted. So, schema is: /home -> home.mount; /my/mountpoint/ -> my-mountpoint.mount; / -> -.mount and so on. UPD: man systemd.mount: = Mount units must be named after the mount point directories they control. Example: the mount point /home/lennart must be configured in a unit file home-lennart.mount. For details about the escaping logic used to convert a file system path to a unit name, see systemd.unit(5). = 15.05.2016 15:28, fb.dev.gen пишет: Hi all, What should be the way to mount the root file system using systemd unit file (i.e: without any `/etc/fstab` configuration file)? Could it be right to do it like that: ``` # cat > /etc/systemd/system/root.mount << EOF [Unit] Description = Root file system mount point controlled and supervised by systemd [Mount] What = /dev/root Where = / Type = ext4 Options = default,discard,noatime 0 0 [Install] WantedBy = multi-user.target EOF ``` ...or is there a better "systemd way" to do it? -- Ben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Internals of journald
Hello! Try this one: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs 12.05.2016 15:19, P.R.Dinesh пишет: I would like to understand the internals of journald, how does journal works, could you please share some links on this subject. Thank you Regards Dinesh ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
12.02.2016 23:36, Lennart Poettering пишет: > On Fri, 12.02.16 23:12, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >> 12.02.2016 22:57, Lennart Poettering пишет: >>> On Fri, 12.02.16 22:28, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: >>> >>>>> TimeoutStopSec= is set to 90s by default. Because it is opt-out and >>>>> not opt-in it's set pretty much in all cases. >>>>> >>>>> Note that when the RuntimeMaxSec= timeout hits and systemd starts >>>>> terminating the service it does so by going through ExecStop= and >>>>> ExecStopPost=. The TimeoutStopSec= timeout applies to each of them >>>>> anyway. >>>> >>>> So, if systemd is going through ExecStop= and ExecStopPost= to stop unit >>>> with RuntimeMaxSec=, which is the normal procedure to exit with >>>> on-success exit-code, why systemd marks unit as "failed", when >>>> RuntimeMaxSec= is hit? Can't catch the logic yet... >>> >>> It's the same as with a daemon exiting non-zero. In that case we'll >>> also continue with ExecStop= and place the service in a failed state. >> >> So, if I define, for example, RuntimeMaxSec=15s, that means unit should >> stop its job in the interval=[0; 14.59]s and 15.00s will be interval >> overflow with exit-code 'failure'. OK. But what if unit will stop its >> job on, e.g., 13th second? Exit-code=success? > > Yes. > > RuntimeMaxSec= just says "abort this shit if it takes longer than > this". The usecase is to use it for stuff which is not supposed to > take this long, and where it's better to abort it, and complain than > to leave it running unbounded. Ok, got it. Thanks! And one more question -- will 'systemctl status' and 'journalctl' contain the explanation about RuntimeMaxSec= limit overflow in logs? E.g. "[FAILED] bla-bla-bla.service. Forced exit, because RuntimeMaxSec limit is hit". Or something around this. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
12.02.2016 22:57, Lennart Poettering пишет: > On Fri, 12.02.16 22:28, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >>> TimeoutStopSec= is set to 90s by default. Because it is opt-out and >>> not opt-in it's set pretty much in all cases. >>> >>> Note that when the RuntimeMaxSec= timeout hits and systemd starts >>> terminating the service it does so by going through ExecStop= and >>> ExecStopPost=. The TimeoutStopSec= timeout applies to each of them >>> anyway. >> >> So, if systemd is going through ExecStop= and ExecStopPost= to stop unit >> with RuntimeMaxSec=, which is the normal procedure to exit with >> on-success exit-code, why systemd marks unit as "failed", when >> RuntimeMaxSec= is hit? Can't catch the logic yet... > > It's the same as with a daemon exiting non-zero. In that case we'll > also continue with ExecStop= and place the service in a failed state. So, if I define, for example, RuntimeMaxSec=15s, that means unit should stop its job in the interval=[0; 14.59]s and 15.00s will be interval overflow with exit-code 'failure'. OK. But what if unit will stop its job on, e.g., 13th second? Exit-code=success? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
12.02.2016 22:17, Lennart Poettering пишет: > On Thu, 11.02.16 20:14, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >> 11.02.2016 19:48, Lennart Poettering пишет: >>> On Thu, 11.02.16 19:47, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: >>> >>>> 11.02.2016 19:32, Jóhann B. Guðmundsson пишет: >>>> >>>>>> * A new service setting RuntimeMaxSec= has been added that >>>>>> may be used >>>>>>to specify a maximum runtime for a service. If the timeout >>>>>> is hit, the >>>>>>service is terminated and put into a failure state. >>>>> >>>>> This does not sound right, why put it into failure state if I as an >>>>> admin specifically told the the service it could run for maximum X time >>>>> and then it should stop? ( after that time period the type unit should >>>>> be stopped cleanly basically systemctl stop foo.service and the state be >>>>> exactly the same as it yields right ? ) >>>> >>>> And if additional option Restart=on-failure is defined in [Service], the >>>> unit will be restarted again immediately. So, user will get unit, that >>>> will be active due to RuntimeMaxSec=, then it will be marked as "failed" >>>> and, if additional option Restart=on-failure is defined, will be >>>> restarted again... failed...restart and so on for eternity. Right? >>> >>> Sure, if that's how you configure things, then systemd does what you >>> are asking it for. >> >> >> I'm staring on TimeoutStopSec= directive description and I think it's be >> more logical a little bit to define RuntimeMaxSec= _only together_ with >> TimeoutStopSec=. > > TimeoutStopSec= is set to 90s by default. Because it is opt-out and > not opt-in it's set pretty much in all cases. > > Note that when the RuntimeMaxSec= timeout hits and systemd starts > terminating the service it does so by going through ExecStop= and > ExecStopPost=. The TimeoutStopSec= timeout applies to each of them > anyway. So, if systemd is going through ExecStop= and ExecStopPost= to stop unit with RuntimeMaxSec=, which is the normal procedure to exit with on-success exit-code, why systemd marks unit as "failed", when RuntimeMaxSec= is hit? Can't catch the logic yet... > Either way, I am happy to take a patch that makes this configurable. That was one of ways to use TimeoutStopSec=, as the first idea how to manke this mechanism more flexible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
11.02.2016 19:48, Lennart Poettering пишет: > On Thu, 11.02.16 19:47, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >> 11.02.2016 19:32, Jóhann B. Guðmundsson пишет: >> >>>> * A new service setting RuntimeMaxSec= has been added that >>>> may be used >>>>to specify a maximum runtime for a service. If the timeout >>>> is hit, the >>>>service is terminated and put into a failure state. >>> >>> This does not sound right, why put it into failure state if I as an >>> admin specifically told the the service it could run for maximum X time >>> and then it should stop? ( after that time period the type unit should >>> be stopped cleanly basically systemctl stop foo.service and the state be >>> exactly the same as it yields right ? ) >> >> And if additional option Restart=on-failure is defined in [Service], the >> unit will be restarted again immediately. So, user will get unit, that >> will be active due to RuntimeMaxSec=, then it will be marked as "failed" >> and, if additional option Restart=on-failure is defined, will be >> restarted again... failed...restart and so on for eternity. Right? > > Sure, if that's how you configure things, then systemd does what you > are asking it for. I'm staring on TimeoutStopSec= directive description and I think it's be more logical a little bit to define RuntimeMaxSec= _only together_ with TimeoutStopSec=. The logic is: if unit is still active, then systemd waits for time, defined in TimeoutStopSec=, and only after TimeoutStopSec= is hit, then mark unit as failed. Otherwise, if unit was stopped earlier then TimeoutStopSec=, marked as normally stopped. This looks more gentle. So, if RuntimeMaxSec= is defined in [Service] without TimeoutStopSec=, then systemd will ignore it. Your opinion? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
11.02.2016 19:32, Jóhann B. Guðmundsson пишет: >> * A new service setting RuntimeMaxSec= has been added that >> may be used >>to specify a maximum runtime for a service. If the timeout >> is hit, the >>service is terminated and put into a failure state. > > This does not sound right, why put it into failure state if I as an > admin specifically told the the service it could run for maximum X time > and then it should stop? ( after that time period the type unit should > be stopped cleanly basically systemctl stop foo.service and the state be > exactly the same as it yields right ? ) And if additional option Restart=on-failure is defined in [Service], the unit will be restarted again immediately. So, user will get unit, that will be active due to RuntimeMaxSec=, then it will be marked as "failed" and, if additional option Restart=on-failure is defined, will be restarted again... failed...restart and so on for eternity. Right? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] known but not-listed units
15.01.2016 16:30, Simon McVittie пишет: > On 15/01/16 14:13, Mikhail Kasimov wrote: >> ok, let be --systemspace (/usr/lib/systemd/system) --userspace >> (/etc/systemd/system) and --runtimespace (/run/systemd). > > /usr: --vendor? --static? --data? > /etc: --local? --conf? > /run: --runtime (this already exists for some other subcommands) > > Anything involving system or user would be inappropriate and confusing: > the distinction between system (pid 1) and user (systemd --user) is > orthogonal to the distinction between OS packages (/usr), local sysadmin > configuration (/etc) and transient runtime changes (/run). On https://github.com/systemd/systemd/issues/2327 requested for naming: --usr,--etc,--run. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] known but not-listed units
That were the first keynames, that came onto mind. :) ok, let be --systemspace (/usr/lib/systemd/system) --userspace (/etc/systemd/system) and --runtimespace (/run/systemd). 15.01.2016 13:13, Colin Guthrie пишет: > Mikhail Kasimov wrote on 14/01/16 15:27: >> 'systemctl list-unit-files --user': to display units-files from >> /etc/systemd/system dir > > I wouldn't use --user here as "systemctl --user" has an existing meaning. > > Col > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] known but not-listed units
Hello! As an additional idea -- to separate lists of 'systemctl list-unit-files' command with subkeys --system, --user and --runtime. By default 'systemctl list-unit-files' should display all unit-files, including runtime generated ones. 'systemctl list-unit-files --system': to display unit-files from /usr/lib/systemd/system dir 'systemctl list-unit-files --user': to display units-files from /etc/systemd/system dir 'systemctl list-unit-files --runtime': to display units-files from /run/systemd/ dir Acceptable? 14.01.2016 17:01, Lennart Poettering пишет: > On Wed, 13.01.16 17:26, Stijn De Weirdt (stijn.dewei...@ugent.be) wrote: > >> hi all, >> >> i'm having following situation on a centos 7.2 system (systemd-219-19.el7) >> >> there is a sysvinit service called netconsole that is not listed as a >> unit or unitfile, but the unitfile was generated and systemctl seems to >> be able to handle the unit. >> >> the only odd issue is that this service is not enabled (chkconfig shows >> all levels as off). >> this system has otehr sysvinit services that do show up as units (but >> for those, at least one level is on) >> >> is this "normal"? and what sort of units exits that are not listed as >> units or unitfiles in general? > > We currently do not show runtime generated unit files among the output > of "systemctl list-unit-files", but it would probably make sense if we > would. Unit files that are automatically generated for SysV scripts > are of this kind, and thus not visible in "systemctl list-unit-files". > > Please file a github issue requesting support for listing such > generated files in "systemctl list-unit-files". > > Thanks, > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Direct systemd-journald event-logs tranmssion to Zabbix\Cacti
26.10.2015 17:35, Lennart Poettering пишет: > On Mon, 26.10.15 15:54, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote: > >> Hello Lennart! The main question is not about why rsyslog is >> better/worst compared to systemd-journald. The main question is how to >> transmit journald event-log to centralized log-server (Zabbix\Cacti\so >> on) directly, without any additional assistant layers (rsyslog in this >> case). > > This is not supported, and I doubt we will ever support that. Why not? Can you declare in /etc/services that, for example, UDP 19531 is systemd-journald port (it's not native rsyslog supporting - it's only the same way of it to have a logically finished log-system, which has internal and external mechanisms of event-log transmission), and TCP 19531 and TCP 19532 are 'systemd-internal-log-transmission'? But ok, no problem, I'll also ask about getting logs of systemd-journald on Zabbix and Cacti forums. Possibly you're right in your original conception, but my intuition whispers, that not at all... > If you want syslog, use syslog, but systemd will not natively output syslog. > >> JSON, HTTP(S) etc. -- that's great, but HTTP(S) is actually used >> for web-surfing. And it often procced with port-redirections (on Squid >> for example), shaping the speed depending on web-content and so on. > > Well, HTTP is kinda the basic building block of most modern protocols, > because it can easily go through proxies. It's certainly not a thing > exclusively for web surfing... You can print via HTTP, you can > checkout your git tree, there's SOAP and REST APIs, and whatnot. It's > simply how you design internert protocols these days that fit into the > concept of HTTP requests/responses. And logging certainly does. > >> "It'd would be easy for external services to simply speak HTTP and get >> the data out of there." (с) - yes, but there're many factors (traffic >> shaping, other firewall ruling etc.) that potentially can affect on >> systemd-journald logs transmission. So, the systemd-journald's dedicated >> documented transports (open and secure) will be good idea. > > The http-based protocol journald-gatewayd and related tools speak is > pretty well documented. > > Again, we won't support BSD syslog natively. If you want syslog, > install a syslog implementation, there are many to choose from. Or use > the HTTP stuff we do, but don't expect us to natively to syslog in systemd. As you can notice, I, conversely, want to use systemd-journald event-log transmission to external log-collectors systems WITHOUT rsyslog. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Direct systemd-journald event-logs tranmssion to Zabbix\Cacti
Hello Lennart! The main question is not about why rsyslog is
better/worst compared to systemd-journald. The main question is how to
transmit journald event-log to centralized log-server (Zabbix\Cacti\so
on) directly, without any additional assistant layers (rsyslog in this
case). JSON, HTTP(S) etc. -- that's great, but HTTP(S) is actually used
for web-surfing. And it often procced with port-redirections (on Squid
for example), shaping the speed depending on web-content and so on.
"It'd would be easy for external services to simply speak HTTP and get
the data out of there." (с) - yes, but there're many factors (traffic
shaping, other firewall ruling etc.) that potentially can affect on
systemd-journald logs transmission. So, the systemd-journald's dedicated
documented transports (open and secure) will be good idea.
This will make the setting up the logs transmission much more easy and
we will not be depended on other web-content, channel overloads, traffic
shaping and other busy-stuff.
Besides, having a dedicated documented transport will be nice according
to security standards (e.g. PCI DSS). They're very sensitive about data
tranmssion and log-servers. What should I tell to auditor - "yes, my
logs are sent on not documented proto or on web-content proto!"? :)
If we send logs between internal helpers - gatewayd/-upload/-remote
(systemd sandbox of Juche :) ) -- no problem.
But when admin needs to have an external log-collector system (according
to different security standards), and -- that vey important -- in
realtime mode, he needs dedicated documented proto (like UDP 514 for
rsyslog), that has no risks on traffic shaping and so on.
"we just decided not to use UDP syslog, but something more featureful,
that knows strict ordering, retransmissition, complex datatypes, is
restarable, and so on... The syslog RFCs were written much much later
only documenting what has been seen in the wild, and that differs
widely. The newest iteration of the BSD syslog RFC is a different
beast even, as it documents structured stuff that pretty much nobody
actually implements..."
==
I'm not against pretty good features of systemd. :) I'd only like to
have dedicated systemd-journald documented UDP\TCP port to send
event-logs _directly_ (without any additional assistant layers) to
log-collectors sensors like it exists for rsyslog on UDP 514 and
syslog-tls 6514/tcp # Syslog over TLS [RFC5425]
syslog-tls 6514/udp # syslog over DTLS [RFC6012]
syslog-tls 6514/dccp# syslog over DTLS [RFC6012].
With maximum setting up like: iptables -p udp --dport $journald_port -j
REDIRECT --to-port 514.
26.10.2015 13:00, Lennart Poettering пишет:
> On Sat, 24.10.15 19:01, Mikhail Kasimov (mikhail.kasi...@gmail.com) wrote:
>
>> 1) Non-systemd:
>> +-+++ +-+
>> | System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
>> +-+++ +-+
>>
>> 2) Systemd-based Linux:
>> +-+++ +-+
>> | System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
>> +-+++ +-+
>> | A
>> | |
>> | | {/etc/systemd/journald.conf:
>> Store=volatile,ForwardToSyslog=yes}
>> | |
>> | +-+ +-+
>> -> |systemd-journald | --> {???} --> |Log-collector|
>>+-+ +-+
>
> Well, rsyslog tends to get the data of the journal on its own these
> days, ForwardToSyslog= is not used anymore and now defaults to
> off. For rsyslog this has the benefit that it can get access to the
> structured log data and not just the baseline that syslog offers. It
> also gets access to logs that happened during early system-boot that way.
>
>> If we want to send systemd-journald logs to remote log-collector system,
>> we have to set up forwarding to (r-)syslog(-ng) service.
>>
>> Systemd's native tools -- systemd-journal-gatewayd\-upload\-remote --
>> are designed to transmit logs between only homogeneous (systemd-based)
>> systems.
>
> Well, the protocol is just HTTP(s), and as payload there are multiple
> formats supported including JSON.
>
> It'd would be easy for external services to simply speak HTTP and get
> the data out of there.
>
> We didn't really come up with a new protocol there, we just decided
> not to use UDP syslog, but something more featureful, that knows
> strict ordering, retransmissition, complex data
Re: [systemd-devel] Direct systemd-journald event-logs tranmssion to Zabbix\Cacti
Anybody online?
24.10.2015 19:01, Mikhail Kasimov пишет:
> Hello!
>
> There is one more question I try to get a clearness for myself -- direct
> systemd-journald event-logs tranmssion to Zabbix\Cacti\other log-collector.
>
> As I understand nowadays we have such event-logs tranmssion schemas:
>
>
> Windows OS system:
>
> | Win System | -->|EventLog-To-Syslog Service| --> {UDP 514} -->
>
> --> |Log-collector|.
>
>
> Unix-like system:
>
> 1) Non-systemd:
> +-+++ +-+
> | System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
> +-+++ +-+
>
> 2) Systemd-based Linux:
> +-+++ +-+
> | System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
> +-+++ +-+
> | A
> | |
> | | {/etc/systemd/journald.conf:
> Store=volatile,ForwardToSyslog=yes}
> | |
> | +-+ +-+
> -> |systemd-journald | --> {???} --> |Log-collector|
>+-+ +-+
>
> If we want to send systemd-journald logs to remote log-collector system,
> we have to set up forwarding to (r-)syslog(-ng) service.
>
> Systemd's native tools -- systemd-journal-gatewayd\-upload\-remote --
> are designed to transmit logs between only homogeneous (systemd-based)
> systems.
>
> So systemd-based Linux system cannot transmit their event-logs to
> log-collectors _directly_ (key word in this topic!) via systemd-journald
> -- it's need to install one more eventlog-system ((r-)syslog(-ng)) to
> transmit logs to log-collector. That's redundacy again, as for me --
> just like the same to which I mentioned in "SSH -H key topic".
>
> I tried to find out the plugins for Cacti to have a dedicated
> systemd-journald tab compared to syslog (like here, for example:
> http://s16.postimg.org/e76umnxb9/pic2.jpg), but have no success on it.
>
> The problem is, I suppose, that systemd has no documented specification
> (RFC) on its own outgoing logs-transmission transport (in open and
> secure ways), instead of syslog:
>
> 'grep 514 < /etc/services':
> =
> syslog 514/udp
> ...
> syslog-tls 6514/tcp # Syslog over TLS [RFC5425]
> syslog-tls 6514/udp # syslog over DTLS [RFC6012]
> syslog-tls 6514/dccp# syslog over DTLS [RFC6012]
> =
>
> 'grep systemd < /etc/services' and 'grep journal < /etc/services' didn't
> give any result.
>
>
> Resume:
>
>
> 1. Because systemd-journald has NO a documented specification on
> logs-transmission transport, admins have to install other log-system in
> parallel to systemd-journald and set up systemd-journald in right way to
> have possibility to send event-logs to log-collector system (Redundancy,
> because two event-log services are in use).
>
> 2. To avoid the redundancy mentioned above, admins can stop and disable
> systemd-journald.socket and systemd-journald.service and use only
> (r-)syslog(-ng) service (one service in use).
>
> 3. If systemd-journald has a documented specification (RFC) on
> logs-transmission transport, admins will have pretty good choice
> (technically and/or ideologically) to use systemd-journald and\or
> (r-)syslog(-ng) at the same time or separately to send event-logs to
> Zabbix\Cacti\other log-collector.
>
>
> Which thing do I understand right and which wrong?
>
> Thanks and sorry for a long text - I'll really be glad to understand the
> current (and possibly, future) situation with systemd-journald event-log
> tranmission to Zabbix\Cacti\other log-collector _directly_.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Direct systemd-journald event-logs tranmssion to Zabbix\Cacti
Hello!
There is one more question I try to get a clearness for myself -- direct
systemd-journald event-logs tranmssion to Zabbix\Cacti\other log-collector.
As I understand nowadays we have such event-logs tranmssion schemas:
Windows OS system:
| Win System | -->|EventLog-To-Syslog Service| --> {UDP 514} -->
--> |Log-collector|.
Unix-like system:
1) Non-systemd:
+-+++ +-+
| System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
+-+++ +-+
2) Systemd-based Linux:
+-+++ +-+
| System | -->|(r-)syslog(-ng) | --> {UDP 514} -->|Log-collector|
+-+++ +-+
| A
| |
| | {/etc/systemd/journald.conf:
Store=volatile,ForwardToSyslog=yes}
| |
| +-+ +-+
-> |systemd-journald | --> {???} --> |Log-collector|
+-+ +-+
If we want to send systemd-journald logs to remote log-collector system,
we have to set up forwarding to (r-)syslog(-ng) service.
Systemd's native tools -- systemd-journal-gatewayd\-upload\-remote --
are designed to transmit logs between only homogeneous (systemd-based)
systems.
So systemd-based Linux system cannot transmit their event-logs to
log-collectors _directly_ (key word in this topic!) via systemd-journald
-- it's need to install one more eventlog-system ((r-)syslog(-ng)) to
transmit logs to log-collector. That's redundacy again, as for me --
just like the same to which I mentioned in "SSH -H key topic".
I tried to find out the plugins for Cacti to have a dedicated
systemd-journald tab compared to syslog (like here, for example:
http://s16.postimg.org/e76umnxb9/pic2.jpg), but have no success on it.
The problem is, I suppose, that systemd has no documented specification
(RFC) on its own outgoing logs-transmission transport (in open and
secure ways), instead of syslog:
'grep 514 < /etc/services':
=
syslog 514/udp
...
syslog-tls 6514/tcp # Syslog over TLS [RFC5425]
syslog-tls 6514/udp # syslog over DTLS [RFC6012]
syslog-tls 6514/dccp# syslog over DTLS [RFC6012]
=
'grep systemd < /etc/services' and 'grep journal < /etc/services' didn't
give any result.
Resume:
1. Because systemd-journald has NO a documented specification on
logs-transmission transport, admins have to install other log-system in
parallel to systemd-journald and set up systemd-journald in right way to
have possibility to send event-logs to log-collector system (Redundancy,
because two event-log services are in use).
2. To avoid the redundancy mentioned above, admins can stop and disable
systemd-journald.socket and systemd-journald.service and use only
(r-)syslog(-ng) service (one service in use).
3. If systemd-journald has a documented specification (RFC) on
logs-transmission transport, admins will have pretty good choice
(technically and/or ideologically) to use systemd-journald and\or
(r-)syslog(-ng) at the same time or separately to send event-logs to
Zabbix\Cacti\other log-collector.
Which thing do I understand right and which wrong?
Thanks and sorry for a long text - I'll really be glad to understand the
current (and possibly, future) situation with systemd-journald event-log
tranmission to Zabbix\Cacti\other log-collector _directly_.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd services via SSH (-H key)
23.10.2015 0:50, Jan Alexander Steffens пишет: > On Thu, Oct 22, 2015 at 11:07 PM, Mikhail Kasimov > wrote: >> Hello! >> >> 1. systemd services have a special key (-H) to connect to remote host >> via ssh. E.g. 'timedatectl -H user@host'. By default port 22 is used. >> But in very often cases admins change the default ssh-port in >> sshd-daemon settings (e.g. 41122). It's useful to avoid connections from >> ssh-bruteforce robots. >> But systemd has no way (I can't find it in man-pages for example) how to >> define the admin-defined ssh connection port (possibly, other ssh >> options are also not accessable). > > You can use ~/.ssh/config to alter any connection properties > associated with a certain hostname, even directing the connection to a > completely different host (a way of creating aliases). > > Example: > > Host foo > HostName foo.example.com > User bar > Port 41122 > > and henceforth, `timedatectl -H foo` will connect to > b...@foo.example.com:41122 Hmm... it's simple variant I didn't think about, thanks. But I have builded more complicated conception. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd services via SSH (-H key)
Hello! 1. systemd services have a special key (-H) to connect to remote host via ssh. E.g. 'timedatectl -H user@host'. By default port 22 is used. But in very often cases admins change the default ssh-port in sshd-daemon settings (e.g. 41122). It's useful to avoid connections from ssh-bruteforce robots. But systemd has no way (I can't find it in man-pages for example) how to define the admin-defined ssh connection port (possibly, other ssh options are also not accessable). The workaround is to define: 'ssh -p 41122 user@host' in console and then, after connection in on, proceed 'timedatectl' on remote host. But in this way it's not clear the profit of sysmted's -H key and this functionality looks redundant as for me. Solutions: == 1. To formalize the systemd-via-ssh connections like it was done for snmpssh [RFC5592] for example. 'grep snmp < /etc/services': snmp 161/tcp # SNMP snmp 161/udp # SNMP snmptrap 162/tcp # SNMPTRAP [Marshall_Rose] snmptrap 162/udp # SNMPTRAP [Marshall_Rose] snmp-tcp-port 1993/tcp # cisco SNMP TCP portsnmp-tcp-port 1993/udp # cisco SNMP TCP portoce-snmp-trap 2697/tcp # Oce SNMP Trap Port [Peter_Teeuwen] oce-snmp-trap 2697/udp # Oce SNMP Trap Port [Peter_Teeuwen] websphere-snmp 3427/tcp # WebSphere SNMP [Richard_Mills] websphere-snmp 3427/udp # WebSphere SNMP [Richard_Mills] snmpssh5161/tcp # SNMP over SSH Transport Model [RFC5592] snmpssh-trap 5162/tcp # SNMP Notification over SSH Transport Model [RFC5592] patrol-snmp8161/tcp # Patrol SNMP [Portnoy_Boxman] patrol-snmp8161/udp # Patrol SNMP [Portnoy_Boxman] snmptls10161/tcp# SNMP-TLS [RFC6353] snmpdtls 10161/udp# SNMP-DTLS [RFC6353] snmptls-trap 10162/tcp# SNMP-Trap-TLS [RFC6353] snmpdtls-trap 10162/udp# SNMP-Trap-DTLS [RFC6353] suncacao-snmp 11161/tcp# sun cacao snmp access point [Nick_Stephen] suncacao-snmp 11161/udp# sun cacao snmp access point [Nick_Stephen] So, we'll have systemd-ssh via hard-defined tcp\udp port described in RFC. And if there's no systemd on remote host, user will get a message like "Cannot proceed on non-systemd host". 2. To extend current -H key functionality with other ssh options (e.g. -p). 3. To delete the redundant functionality (-H key) from systemd services and to continue to use traditional non-systemd-ways (ssh -p 123 user@host). By the way, I think the 1. is also acceptable to systemd-journal-gatewayd\-upload\-remote, if their functionality would be extended with ssh-transmission suppotring (via scp). Thank you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
