Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment
What about rkt with systemd? https://coreos.com/rkt/docs/latest/using-rkt-with-systemd.html Any experiences? On Thu, Oct 20, 2016 at 2:02 PM, Lennart Poettering wrote: > On Thu, 20.10.16 12:35, Juanjo Presa (juan...@gmail.com) wrote: > > > I am comfortable with machinectl nowadays but maybe I miss some kind of > > versioning of images generated. Do you have any advice or recommendation > > about this? > > Versioning is hard. We have no concept for that in nspawn/machined, > and right now I have no good suggeston about it, except maybe that you > could include a version identifier in the container's name, the same > way deb/rpm packages do it... > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Single Start-job remains listed after startup in state waiting ...
Hello, we are observing a weird behavior with systemd 211. The issue: -After the startup is finished (multi-user.target is reached), one single job (typ: start, unit: service) remains in the job queue in state waiting o There seems not to be any unmet dependency o There are no units in state failed o The job is listed when calling systemctl list-jobs -The issue is seen sporadically, not on every startup -The startup is a mixture of o Units coming up as part of the dependency tree ending up in multi-user.target o And units started by a component using systemctl start § The started units might have a tree of depending units as well § The sub trees of several of such unit are not necessarily disjoint What I'm doing currently: -The issue is hard to reproduce. -That's why I'm trying to find out in which cases it is possible at all that a job in state waiting can remain in the job list -With a hypothesis, I can instrument systemd and try to reproduce it again How you can help me: -Maybe someone already knows such an issue. Maybe it has already been solved. Respective hints would be great. -Some of you have probably a better knowledge about how transactions and the job scheduling are working in systemd. Maybe such a person could already point me to the cases that could happen to see finally such a result. Thx in advance! Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschäftsführung: Wilhelm Grabow, Ken Yaguchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kexec -p option does not cause a reboot on panic
Hi, I was testing kexec on systemd (Ubuntu 16.04). Here are the steps I follow: 1. Install a kexec aware kernel (all the configs needed for kexec are enabled) 2. Give the following command after making sure we have set up crash memory: kexec -p --initrd= --reuse-cmdline 3. Check /sys/kernel/kexec_crash_loaded(it is 1) 4. Generate a panic: echo c >/proc/sysrq-trigger Even after waiting for a while, I see that no reboot is happening. However, the kexec -e option works just fine. Kexec -p works as expected on Ubuntu 14.04(which uses systemv) Has anyone seen this issue before? Is there any additional step required that I may have missed? It would be great if I could get some pointers. Thanks, Megha ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
