Re: [systemd-devel] Github systemd issue 6237
On Wed, Jul 05, 2017 at 08:10:15PM +1000, Michael Chapman wrote: > On Wed, 5 Jul 2017, Colin Guthrie wrote: > >Reindl Harald wrote on 04/07/17 19:50: > >>>When new configuration options are added, the same unit file can > >>>almost always be used with older systemd, and it'll just warn & ignore > >>>the parts it doesn't understand. Similarly, various configuration > >>>options might be unavailable on some architectures and with some > >>>compilation options. The current behaviour of warn provides > >>>for "soft degradation" in those cases. > >> > >>frankly a new option on the left side is a completly different thing > >>than a invalid value - just silently continue with invalid values of > >>existing options is playing a danergous game in a crucial component like > >>systemd > > > >It's a rare thing :p but I have to agree with you here! > > > >I'd say if "User=-notauser" then silently failing and using root is > >acceptable as per the usual semantics of "- prefix suppresses errors", > >but "User=notauser" should fail IMO. > > I'm pretty sure you'll find that it does. Specifically, it will fail > when the child process for the command being executed attempts to > map the username to a UID. > > The issue being discussed here is that systemd considers "0day" to > be _syntactically_ invalid for a username. See the > valid_user_group_name() function in basic/user-util.c. > > (In my opinion, we shouldn't be this restrictive. POSIX permits > usernames that start with a digit, and just because certain other > utilities can't deal with them doesn't mean systemd need forbid > them.) > > So the directive fails the syntactic check for User=, just like > Zbigniew's example of User="my name is pretty!". > > I do think we ought to have a list of "critical" directives, such > that any syntactic error in those directives causes the unit load > state to be "error". For better or worse, people simply don't look > at logs, so they'll never notice that important directives in their > units are being ignored. https://github.com/systemd/systemd/pull/6300 Zbyszek ___ 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
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] > Июл 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 dir is ./ > Июл 06 18:07:00 linux-mk500 vbacl[8842]: Start update from > http://anti-virus.by/beta/update > Июл 06 18:07:00 linux-mk500 vbacl[8842]: Receiving file list > Июл 06 18:07:00 linux-mk500 vbacl[8842]: File list received > Июл 06 18:07:00 linux-mk500 vbacl[8842]: Update is not needed > Июл 06 18:07:00 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update > Service. > == > > > And here when Type=simple: > == > Июл 06 18:47:29 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update > Service. > Июл 06 18:47:29 linux-mk500 vbacl[10042]: Vba32 console scanner update > process
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 dir is ./ Июл 06 18:07:00 linux-mk500 vbacl[8842]: Start update from http://anti-virus.by/beta/update Июл 06 18:07:00 linux-mk500 vbacl[8842]: Receiving file list Июл 06 18:07:00 linux-mk500 vbacl[8842]: File list received Июл 06 18:07:00 linux-mk500 vbacl[8842]: Update is not needed Июл 06 18:07:00 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. == And here when Type=simple: == Июл 06 18:47:29 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update Service. Июл 06 18:47:29 linux-mk500 vbacl[10042]: Vba32 console scanner update process started Июл 06 18:47:29 linux-mk500 vbacl[10042]: Reading configuration options from ./vbacl.ini Июл 06 18:47:29 linux-mk500 vbacl[10042]: Using direct connection for update ==
Re: [systemd-devel] Timeout for 'Activating (start)' status
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. 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? Well, it acts as a hard-limit for the service lifetime. If that's actually what you wanted, a more natural way to do it would be to use RuntimeMaxSec= on a Type=simple service. 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! No problem!___ 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
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] Realtime scheduling with CONFIG_RT_GROUP_SCHED=y
I'm running on a kernel with CONFIG_RT_GROUP_SCHED=y. I understand that
this is counter to the recommendation in the README ("We recommend to turn
off Real-Time group scheduling in the kernel when using systemd"), but
I don't have control over the kernel configuration.
On this system, it appears that starting "docker" (docker-ce-17.06.0.ce-1)
results in the creation of new cpu cgroups that for some reason apply to
systemd services. That is, after starting docker,
/sys/fs/cgroup/cpu/system.slice exists when previously it didn't.
Once this happens, a service that attempts to set realtime scheduling
(SCHED_RR) via sched_setscheduler() will fail, presumably because the
cgroup has no realtime budget in cpu.rt_runtime_us.
In older versions of systemd one could handle this using the directives
described in
https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/,
but unfortunately that document, despite being the number 1 search result
for pretty much anything involving "systemd" and "realtime", is obsolete
and those directives no longer exist.
Is there a way to make this work correctly with modern versions of
systemd? I've hacked around it for now by creating
/etc/systemd/system/myservice.service.d/realtime.conf that moves the
service back to the root cgroup and then uses chrt to set the scheduling
policy:
[Service]
ExecStartPost=/bin/cgclassify -g cpu:/ $MAINPID
ExecStartPost=/bin/chrt -r -p 99 $MAINPID
...and while that works, it seems really ugly. I've attempted to set
CPUSchedulingPolicy=rr in the unit, but that simply results in systemd
failing to start the service and logging "Failed at step SETSCHEDULER
spawning...".
Is there a better way of addressing this?
--
Lars Kellogg-Stedman
___
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
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. 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:"). 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 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] Is there a reason to run systemd Units with root access?
Am 04.07.2017 um 22:33 schrieb Mariusz Wojcik: I’m just asking because of the latest “not-a-bug” [1]. As far as I know, there aren’t many services that need full root access (maybe for getting a low port number). Except for that I don’t see many use cases. Therefore, I think it would be useful to make the decision for root access more explicit, e.g. User=root is needed to start units as root. Also I don’t think it is a sane default is to start any unit as root when there is no valid User property. Even the security of systemd would benefit because it would save people from accidentally running services as root. answer from a sysadmin: how do you imagine that every systemd-unit out there shipped by whatever distribution and much more critical every unit in /etc/systemd/system/ would get modified (for the second case i maintain alone some hundret spread ver 30 or so machines) "there aren't many services that need full root access" is simply not true at all, you just don't know enough software which needs to read certificate files which are only accessable as root (or at least should) and then drop privileges just as one example ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to run systemd Units with root access?
On Tue, 04 Jul 2017 at 20:33:54 +, Mariusz Wojcik wrote:
> As far as I know, there
> aren’t many services that need full root access (maybe for getting a low port
> number).
systemd system units are basically a replacement for LSB (or sysvinit
if you prefer) init scripts, which always run as full root, and can drop
privileges themselves if they want to.
Anything that runs with capabilities that trivially allow escalation to
full root (such as CAP_SYS_ADMIN, CAP_FSETID, CAP_SETUID, CAP_SYS_MODULE,
CAP_SYS_PTRACE) might as well be full root. Such processes are in the
trusted computing base (TCB): it would be within their technical ability
to break security policies.
Using an unscientific sample consisting of the 12 system services starting
with "a" or "b" on my Debian laptop:
* apt-cacher-ng has a non-trivial User (systemd starts it unprivileged)
* avahi-daemon starts as root to do some privileged setup, then drops
privileges itself (this is a common pattern, dbus-daemon does this too)
* alsa-{restore,state} don't necessarily need to be root, but do need
hardware access, are not persistent (they are "oneshot" services run
during boot and shutdown), and they are so simple that giving them
privilege separation seems like a poor use of anyone's time
* bluez runs as root but drops most capabilities
* the rest run as "full" root and are in the TCB, and seem like they
legitimately need it (for example atd and anacron have it as part of
their "API" that they can be used to run arbitrary tasks, including
being full root)
I personally think the syntactic/semantic validity distinction here
is not the least-astonishment behaviour, and my preferred resolution
for this issue would be for User=7up or User="this name is silly!" to
be exactly equivalent to specifying a User with a "normal" name that
happens to be missing from `getent passwd` (in other words, the unit
fails to start with exit status 217/USER). But you can tell I don't
think this is critically important by the fact that I haven't written
and proposed a patch with that behaviour. If this is more important to
you than it is to me, a reasonable next step would be to put together
that patch.
S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to run systemd Units with root access?
On Wed, 5 Jul 2017, Mariusz Wojcik wrote: Hi, I’m just asking because of the latest “not-a-bug” [1]. As far as I know, there aren’t many services that need full root access (maybe for getting a low port number). Except for that I don’t see many use cases. Therefore, I think it would be useful to make the decision for root access more explicit, e.g. User=root is needed to start units as root. Also I don’t think it is a sane default is to start any unit as root when there is no valid User property. Even the security of systemd would benefit because it would save people from accidentally running services as root. Making User= mandatory would be a backwards-incompatible change, and break a *lot* of existing units. People understand that omitting Unit= on a system unit means the unit runs as root, just as omitting it on a user unit means the unit runs as that user. Breaking units that work perfectly well right now and do exactly what the admin wanted them to do really isn't an option.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there a reason to run systemd Units with root access?
Hi, I’m just asking because of the latest “not-a-bug” [1]. As far as I know, there aren’t many services that need full root access (maybe for getting a low port number). Except for that I don’t see many use cases. Therefore, I think it would be useful to make the decision for root access more explicit, e.g. User=root is needed to start units as root. Also I don’t think it is a sane default is to start any unit as root when there is no valid User property. Even the security of systemd would benefit because it would save people from accidentally running services as root. Regards, Mariusz Wojcik [1]: https://github.com/systemd/systemd/issues/6237 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Am 06.07.2017 um 09:59 schrieb Jonathan de Boyne Pollard: Reindl Harald: > at least fall back to “nobody” Jonathan de Boyne Pollard: > That idea is wrong. > > https://news.ycombinator.com/item?id=14681377#14682059 Reindl Harald: > better than a stupid [...] Not really, no. It's the same category of error, in fact: substituting an account other than the one that the system administrator explicitly said to drop privileges to. yes, it's both nonsense, but when i only have the option to choose between two types of nonsense i take the one which don't give root permissions ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Reindl Harald: > at least fall back to “nobody” Jonathan de Boyne Pollard: > That idea is wrong. > > https://news.ycombinator.com/item?id=14681377#14682059 Reindl Harald: > better than a stupid [...] Not really, no. It's the same category of error, in fact: substituting an account other than the one that the system administrator explicitly said to drop privileges to.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Am Mittwoch, den 05.07.2017, 20:10 +1000 schrieb Michael Chapman: > I'm pretty sure you'll find that it does. Specifically, it will fail when > the child process for the command being executed attempts to map the > username to a UID. > > The issue being discussed here is that systemd considers "0day" to be > _syntactically_ invalid for a username. See the valid_user_group_name() > function in basic/user-util.c. What a valid username is, is defined in POSIX. If systemd wants to support only a subset of those, fair enough, but then it must totally fail anything that uses such a name. Falling back to another user is not acceptable. It being root is especially bad. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
