Re: [systemd-devel] Crash instead of emergency mode when mount failure
On Fr, 18.01.19 12:00, Yang Lyu (yang@axis.com) wrote: > Hi, > > > I have two questions about entering emergency mode when mount target fails. > > > If local-fs.target fails in booting stage, it will come into > emergency mode and wait for user interaction. In this failure case, > is it better to introduce a crash generate core dump and reboot > automatically? A coredump of what precisely? If you want to reboot automatically if some unit fails or can't be reached within some time use FailureAction=reboot or JobTimeoutAction=reboot. In case of local-fs.target using JobTimeoutAction=reboot sounds like a good solution. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl start second.service first.service
Thanks for your exhaustive reply, Jonathon. On Tue, Jan 08, 2019 at 04:02:47AM +0530, Jonathon Kowalski wrote: > [...] > I think systemctl should do something similar to that, internally > create a transient target unit through manager's bus API, add Wants= > (which gives it implicit After=) on all unit names passed, and then > invoke the startup of this target, so that it gets treated as anchor > job and generates a transaction where all dependencies are ordered > properly. Hence, I vote for the first option. I agree, this recycles most of the existing transaction engine logic and does not bring too many corner cases needing resolution. > [...] So I vote for both 2 and 1, 2 implemented using the 1st > approach. Problem with 2 is that it touches DBus API and hence it should be a well considered change. I don't think it's good to create such "macro" functions that would emulate something that could be done by other DBus methods (create the transient target, add deps for it, start it). > That said, I do think in practice if units are declared properly dependency > wise, they should already pull one another in a transaction, which would > then also take care of ordering deps, and anything that actually needs such > semantics from systemctl (or through the bus) is already broken. This is an argument I did not contemplate enough but once you pointed it out, I cannot agree more :) Units themselves should specify what they Wants= or Requires= in the transaction. This may be distributed in another unit, e.g. - U wants A and B, - B after A, - intended usecase is starting U. The manual invocation of `systemctl start B A` could be then understood rather as debugging operation. In this light, it makes a nice sense to me to introduce a new option to systemctl, that'd make sure a transient target is created and it aggregates the requested operations. Management of that unit then can be no special from others because by passing that unit, user should be expecting such a unit is created. You've concinced me about variant 1 with the behavior being triggered by explicit user request. Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Direct connection between peers in sd-bus
On Fr, 18.01.19 00:19, Stanislav Angelovič (angelovi...@gmail.com) wrote: > Hi, > > In sd-bus, I guess it is possible to have a one-to-one connection between a > service and a client, i.e. connection without D-bus daemon), am I right? If > yes, is there any example (in systemd source tree or elsewhere) of sd-bus > one-to-one communication usage that I could look at for inspiration and > learning on how is that done? systemctl and PID 1 optionally communicate with direct one-to-one connections, as one example. There's also a test that tests this mode of operation, which can be useful as an example too: https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/test-bus-server.c Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
Lennart Poettering on Wed, 2019/01/16 19:46:
> And in case the tag matches ^v[0-9]+-pre-.*$ may be this:
>
> A new systemd ☠️ pre-release☠️ has just been tagged. Please
> download the tarball here:
>
> https://github.com/systemd/systemd/archive/$TAG.tar.gz
>
> NOTE: This is ☠️ pre-release☠️ software. Do not run this on
> production systems, but please test this and report any issues you
> find to GitHub:
>
> https://github.com/systemd/systemd/issues/new?template=Bug_report.md
See the milestones for pending changes:
https://github.com/systemd/systemd/milestones
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgpk89OXKii4O.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Crash instead of emergency mode when mount failure
Hi, I have two questions about entering emergency mode when mount target fails. If local-fs.target fails in booting stage, it will come into emergency mode and wait for user interaction. In this failure case, is it better to introduce a crash generate core dump and reboot automatically? Replacing emergency mode by such a method can be useful when local-fs.target's failure is transient or user interaction is not convenient. A possible crash service may like this: [Unit] DefaultDependencies=no Description=Crash the system using the SysRq trigger [Service] ExecStartPre=-/bin/sh -c 'echo "crash-system.service started" > /dev/kmsg' ExecStart=/bin/sh -c 'echo c > /proc/sysrq-trigger' Type=oneshot And this new service(instead of current emergency.target) is used in OnFailure of local-fs.target. Does this sound good and useful? Or what is the drawback of this solution? Another question is: is there a configuration option to cause a reboot if local-fs.target fails? So that we can use the option directly. Thank you in advance. Best regards, Yang ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
