[systemd-devel] kexec -p option does not cause a reboot on panic

2016-10-28 Thread Dey, Megha

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 

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.


systemd-devel mailing list

[systemd-devel] Single Start-job remains listed after startup in state waiting ...

2016-10-28 Thread Hoyer, Marko (ADITG/SW2)

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 

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 

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
Tel. +49 5121 49 6948
Fax +49 5121 49 6999
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

Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment

2016-10-28 Thread Juanjo Presa
What about rkt with systemd?


Any experiences?

On Thu, Oct 20, 2016 at 2:02 PM, Lennart Poettering 

> 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