[systemd-devel] "dev-xxx.device" is trying to start indefinitely long
Hi, I'm not sure if I'm writing to the right mailing list, please redirect me if I'm wrong. I'm trying to make some custom initramfs image with systemd and I encounter very strange behaviour. Namely, when I boot into it with "root=/dev/hda" kernel command line option the boot process stops right after "Reached target Basic System" trying to start dev-hda.device, i.e I see "A start job is running for dev-hda.device (1min 8s / no limit)" forever. However, if I break the boot process on an early stage and run the rescue shell, I can see /dev/hda and it can also be mounted without any problem. But if I 'systemctl start dev-hda.device' manually it also waits forever. Have anyone here encountered something similar and what dev-hda.device unit is actually trying to do? Could you give me any tips for debugging this? Thanks, Anton Gerasimov -- Anton Gerasimov, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk Pöschl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Sharing processes across services
On 09/14/2016 01:31 AM, Michal Koutny wrote:
> Currently one PID can belong up to two services
> (manager->watch_pids{1,2}). If more than one why just two? And when can
> such a situation happen?
I've found origin of this change in [1]. Still, I wonder why it is
"interesting to map a PID to two units at the same time". Is
getty->login the only use case? Wouldn't it make more sense to move the
PID to another unit rather than share it?
Thanks,
Michal
[1]
https://github.com/systemd/systemd/commit/5ba6985b6c8ef85a8bcfeb1b65239c863436e75b
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "dev-xxx.device" is trying to start indefinitely long
Hello Anton, Anton Gerasimov [2016-09-19 18:08 +0200]: > I'm trying to make some custom initramfs image with systemd and I > encounter very strange behaviour. Namely, when I boot into it with > "root=/dev/hda" kernel command line option the boot process stops right > after "Reached target Basic System" trying to start dev-hda.device, i.e > I see "A start job is running for dev-hda.device (1min 8s / no limit)" > forever. > > However, if I break the boot process on an early stage and run the > rescue shell, I can see /dev/hda and it can also be mounted without any > problem. But if I 'systemctl start dev-hda.device' manually it also > waits forever. > > Have anyone here encountered something similar and what dev-hda.device > unit is actually trying to do? Could you give me any tips for debugging > this? Actually yes. Occasionally our upstream CI fails with a similar problem where it indefinitely hangs waiting for dev-ttyS0.device; and just today I got a bug report with a similar symptom like your's [2]. Apparently udev sometimes misses to attach the "systemd" tag to that device which causes systemd to never "see" it. We don't understand the bug at all yet, nor are able to reproduce it with reasonable effort. Does your problem happen at every boot, or only sometimes? In the former case it might actually not be a race condition but a more systematic error, such as missing some udev rules, or not re-triggering all udev devices during boot, etc. Martin [1] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/i386/s/systemd-upstream/20160903_005404@/log.gz [2] https://bugs.launchpad.net/bugs/1625217 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "dev-xxx.device" is trying to start indefinitely long
19.09.2016 20:24, Martin Pitt пишет: > > Does your problem happen at every boot, or only sometimes? In the > former case it might actually not be a race condition but a more > systematic error, such as missing some udev rules, or not > re-triggering all udev devices during boot, etc. > CONFIG_FHANDLE comes in mind ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 231 and /dev/console in a docker container Update
I also found that when i start docker run --rm -it --security-opt=seccomp:unconfined --cap-add SYS_ADMIN --cap-add MKNOD -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora-25-image bash and then run the systemd (so that it is not pid 1) /lib/systemd/systemd --system --show-status=true --log-level=debug ==> then systemd starts normally (as pid 2) and the /dev/console node is _not_ deleted and it works as expected! So still puzzled what is happening, then run this as described below. docker --version Docker version 1.12.1, build 23cf638 cat /proc/version Linux version 4.7.3-200.fc24.x86_64 (mockbu...@bkernel01.phx2.fedoraproject.org) (gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC) ) #1 SMP Wed Sep 7 17:31:21 UTC 2016 Am 18.09.2016 um 14:30 schrieb bal...@email.de: > > Hello, > > i hope this is the right list to ask this, if not it would be kind if > you would point me to the right forum. Currently i have systemd > running in a docker container, which works well in version 229 > (fedora 24 image). I have configured journald there to log to > console, so that i can see the logs via a simple docker logs -f > . Everything works fine with this. > > Recently i decided to to to run systemd 231 on fedora 25 beta and > rebuild my Dockerfile for fedora 25. After starting the container it > turned out that nothing was shown in docker logs -f > and after some investigation, that journald was terribly slow with > logging. After some strace sessions in the container i found that > writing to /dev/console was failing with "EIO" (-1). So i did > another test if this was docker problem and run simply a bash shell > with the container. To my surprise this worked fine. > > With a "docker exec run -it fedora-25-image bash" i could write to > console without any problems, when i did run a 'echo "Hello world" > >/dev/console" in the container. So i came to the conclusion that the > problem lies within systemd 231 and not withing Docker, as this worked > fine for fedora-24 based systemd 229 and also the simple bash test. > > At this point i investiged what was the difference. Basically it > turned out that on bash (and also on systemd 229 on fedora 24) the is > shown when i do a > > cat /proc/1/mountinfo |grep console ( /33 varies if you run more > than one container) > > 2769 2749 0:20 /33 /dev/console rw,nosuid,noexec,relatime - devpts > devpts rw,gid=5,mode=620,ptmxmode=0 > > when i do this with a fedora 25 image, where systemd is started as > process 1 i get for > > cat /proc/1/mountinfo |grep console > 2769 2749 0:20 */33//deleted */dev/console rw,nosuid,noexec,relatime - > devpts devpts rw,gid=5,mode=620,ptmxmode=000 > > > It seems that systemd somehow has deleted the /dev/console device, and > therefore a journald which wants to log to /dev/console in the > container gets an EIO . > > > In general i have started the systemd runs with the following options > (24 or 25) > docker run --rm -it --security-opt=seccomp:unconfined --cap-add > SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro fedora-25-image > /lib/systemd/systemd > > > My question is now is this a bug, or is this some kind of new feature, > where i need to set a special flag in systemd 231 (which one?) > > > Hope the description was sufficient. > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
