Re: [systemd-devel] Debug hanging unit stop on shutdown?
Thanks, I'll check it out. Mantas Mikulėnas <graw...@gmail.com> schrieb am Fr., 28. Juli 2017, 10:52: > On Thu, Jul 27, 2017 at 10:33 PM, Benno Fünfstück < > benno.fuenfstu...@gmail.com> wrote: > >> Hi, >> >> when shutting down my system, I sometimes get a "Stopping ..." from >> systemd, where it waits 90 seconds before it kills the affected session / >> unit / scope / ... . Is there any way to debug this live, without enabling >> persistent journal and hoping that the journal has enough information? >> >> Ideal would be a way to "interrupt" shutdown in this case and be able to >> correct the mistake / fix the error. >> > > Start debug-shell.service (or boot with "systemd.debug-shell"). During > shutdown, switch to tty9 and use `systemctl list-jobs`, then `systemctl > cancel` to flush all pending jobs. > > -- > Mantas Mikulėnas <graw...@gmail.com> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Debug hanging unit stop on shutdown?
Hi, when shutting down my system, I sometimes get a "Stopping ..." from systemd, where it waits 90 seconds before it kills the affected session / unit / scope / ... . Is there any way to debug this live, without enabling persistent journal and hoping that the journal has enough information? Ideal would be a way to "interrupt" shutdown in this case and be able to correct the mistake / fix the error. Regards, Benno Fünfstück ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Group of temporary but related units?
Hey list, what would be a good way to manage temporary development environments with systemd? For example, if I quickly want to spawn up an environment where my service + perhaps some db or a queue or some other services are running. It would be nice to reuse systemd's service management capabiltiies for this. Or should I really write two sets of unit files for my services, one for spinning up a testing / development environment using some other supervision suite + another one for deployment with systemd? Perhaps there is a more lightweight alternative of systemd-nspawn, that doesn't require root and doesn't replace the file system? Kind regards, Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a set of group isolated from other services?
Great, thanks! Lennart Poettering <lenn...@poettering.net> schrieb am Sa., 29. Apr. 2017, 19:32: > On Wed, 26.04.17 11:08, Benno Fünfstück (benno.fuenfstu...@gmail.com) > wrote: > > > > I have the problem that I want to run a set of services that are > isolated > > > from the other services. In particular, I'd like to: > > > > > > * share some environment variables between these services, that aren't > > > available for services outside the group > > > * be able to stop all the services in the group and wait for proper > > > shutdown > > > * (would be nice) load services for the group from a different > directory > > > than the default one > > > * (would be nice) be able to add transient services to the group with > > > systemd-run > > > > > > Is such a thing possible with systemd? If not, is it feasible to > implement > > > something like this (even if it doesn't match exactly what I want)? > > > > > > Regards, > > > Benno > > > > > > > Just to add if that wasn't clear: I'd like to run this group for multiple > > different sets of environment variables, and be able to "start" the group > > for some assignment of environment variables (these variables will not > > change during the lifetime of the group though) > > If you want multiple instantation you can use systemd's instance > logic. i.e. you could have: > >mygroup@.target > > This target unit could then have Wants= deps on your various services, > always passing along the instance identifier: > > [Unit] > Wants=myservice1@%i.service myservice2@%i.service > > Then, insce the service units you'd add a PartsOf= dep back: > > [Unit] > PartOf=mygroup@%i.target > > And then pull in the environment file based on the instance: > > [Service] > EnvironmentFile=/path/to/my/env-file-%i.conf > > I hope that makes sense, > > 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] Running a set of group isolated from other services?
Benno Fünfstück <benno.fuenfstu...@gmail.com> schrieb am Mi., 26. Apr. 2017 um 13:05 Uhr: > Hi, > > I have the problem that I want to run a set of services that are isolated > from the other services. In particular, I'd like to: > > * share some environment variables between these services, that aren't > available for services outside the group > * be able to stop all the services in the group and wait for proper > shutdown > * (would be nice) load services for the group from a different directory > than the default one > * (would be nice) be able to add transient services to the group with > systemd-run > > Is such a thing possible with systemd? If not, is it feasible to implement > something like this (even if it doesn't match exactly what I want)? > > Regards, > Benno > Just to add if that wasn't clear: I'd like to run this group for multiple different sets of environment variables, and be able to "start" the group for some assignment of environment variables (these variables will not change during the lifetime of the group though) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running a set of group isolated from other services?
Hi, I have the problem that I want to run a set of services that are isolated from the other services. In particular, I'd like to: * share some environment variables between these services, that aren't available for services outside the group * be able to stop all the services in the group and wait for proper shutdown * (would be nice) load services for the group from a different directory than the default one * (would be nice) be able to add transient services to the group with systemd-run Is such a thing possible with systemd? If not, is it feasible to implement something like this (even if it doesn't match exactly what I want)? Regards, Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
> > Increased complexity in *all* software — each and every thing you start > must > support multiple sessions. > Oh, why is that? I wasn't suggesting to replace the existing systemd --user instance, only to add a new one for each session. So software that does not support multiple sessions still does not have to: if firefox does not support multiple sessions, then so be it, then that means you can only use it on a single session and it continues to use the per-user instance. Or is it not that easy? Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
Thank you Lennart for taking the time to answer my question. It does make sense that you wouldn't want to support multiple sessions in big desktop environments like Gnome or KDE or any complex software. However, it seems to me that there would be quite some usecases that fall outside these where multiple sessions make sense: * first, while most software may not support multiple *graphical* sessions, it would be nice to be able to isolate my non-graphical sessions (like tty or ssh or whatever) from the, perhaps single, graphical session. As it stands, if I want to use systemd for managing graphical daemons, I have to import things like DISPLAY into the systemd --user instance which feels wrong to me, as there may be many other user services that do not rely on that variable at all and should not care. * second, you say that big, complex software does not support multiple sessions sanely. However, I feel like this is a feature that would be most used by people running very lightweight graphical sessions. For example, I currently start my graphical services in `.xinitrc`. It would be very nice to be able to use systemd for this, as that would allow me to sanely stop all daemons at logout time. I understand that for most users this feature may not be strictly necessary. There is a cost associated with maintaining this in systemd. But couldn't most of the code be shared with systemd user support? Or are there any other costs that I'm overlooking, apart from the increased complexity & maintenance cost to the systemd codebase? Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd --session instance?
> > On Sat, Apr 22, 2017 at 02:07:49PM +, Benno Fünfstück wrote: > > Hello list, > > > > currenty, systemd runs a system instance and a per-user one. However, > > sometimes it would be nice to have a per-session instance, for example > for > > users of lightweight desktop environments that don't have their own > service > > manager. Then you could use systemd to spawn things like panels or > desktop > > notification daemons etc. Would it be possible to add such a thing, even > if > > it may require some work? Or are there any fundamental problems with it? > > It would require a fundamental amount of work. We (people developing > systemd, large graphical environments, dbus, ...) to move towards > user-sessions, > and limit support to one graphical session per user. The thinking is that > one graphical session is enough for one user. > > In principle you could still have a single systemd --user instance, > and e.g. start various services multiple times using templating > (terminal-daemon@.service, file-manager@.service, etc). This isn't too > hard to get working in a limited scope, but making it work in general > is hard, and would require a lot of support from various > programs. Your use case would be neat, but also a bit fringe, and it's > complicated enough to get graphical envs working with one session per > user. > > Zbyszek > Thanks for the answer! Can you go into some more detail about what particular challenges there are with making such a thing possible? (Just some, because currently I feel like it would be easy and I would like to get a feeling for the kind of problems this would cause / would have to be dealt with) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd --session instance?
Hello list, currenty, systemd runs a system instance and a per-user one. However, sometimes it would be nice to have a per-session instance, for example for users of lightweight desktop environments that don't have their own service manager. Then you could use systemd to spawn things like panels or desktop notification daemons etc. Would it be possible to add such a thing, even if it may require some work? Or are there any fundamental problems with it? Thanks, Benno Fünfstück ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
