it seems openrc dependency algorithm screws up again # mount | grep /dev /dev/root on / type ext4 (rw,relatime,data=ordered) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755) /dev/sda1 on /boot type ext2 (rw,noatime,nodiratime) the problem is: /dev is mount *after* (yet expected to be before) /dev/shm and /dev/pts (same as when i read the boot message) anything pop out in /dev/pts is not visible to user space app because it's overlay by /dev devfs should start *after* (yet before) udev-mount when udev-mount is pull in automatically by dependency rc-update del dev-mount sysinit -> reproduced. this is the default case rc-update add dev-mount sysinit -> not reproduced Reproducible: Always Steps to Reproduce: 1. reboot 2. ssh into the box Actual Results: PTY allocation request failed on channel ... Expected Results: no error $ /sbin/rc-update -s |grep udev udev | sysinit udev-postmount | default $ cd /etc/init.d; grep dev-mount * udev: need sysfs udev-mount devfs: need dev-mount udev-mount: provide dev-mount devfs uses dev-mount provided udev-mount, so udev-mount is supposed to be pull in and started before devfs
Which version of sys-apps/openrc ?
tried both 0.11.1, 0.11.2
It looks like you missed the warning wrt adding udev-mount to sysinit. Please run this command: rc-update add udev-mount sysinit
i don't see the warning in ebuild file nor when i build it. and yes i do see about the "workaround" in forum, yet it's just a workaround. the scripts provide enough dependency info, "devfs" is added to default runlevel, udev-mount should be pull in automatically and started before devfs
The warning is in the latest udev (171-r8 if you are running stable udev). devfs is actually in the sysinit runlevel, and its dependency on dev-mount is "use dev-mount". That means run a provider of dev-mount before this script, *if* one is in the runlevel. It can't be changed to "need" because someone might be using static /dev, which means they would not have a dev-mount provider. Udev-mount is running before udev (see the "need udev-mount" line in /etc/init.d/udev), but not before devfs (see the "use dev-mount" line in /etc/init.d/devfs). That is why udev-mount needs to be added to sysinit. I'll be doing this automatically with the next OpenRC update if udev is in sysinit.
I have udev in the sysinit runlevel. udev has "need udev-mount". I also have devfs in the sysinit runlevel. devfs has "use dev-mount". Since udev pulls udev-mount into the runlevel, shouldn't devfs run *after* dev-mount has been provided by udev-mount? Adding udev-mount to the sysinit runlevel made it work, but that shouldn't be necessary.
(In reply to comment #6) > I have udev in the sysinit runlevel. udev has "need udev-mount". I also have > devfs in the sysinit runlevel. devfs has "use dev-mount". Since udev pulls > udev-mount into the runlevel, shouldn't devfs run *after* dev-mount has been > provided by udev-mount? Adding udev-mount to the sysinit runlevel made it > work, but that shouldn't be necessary. Actually udev doesn't pull anything into the runlevel. The "need dev-mount" makes OpenRC go out and look for a dev-mount provider and try to run it. If there isn't a provider in the runlevel, the only reason udev-mount is runnig is that there isn't another provider installed in init.d. It is safest to add udev-mount to the runlevel. That makes sure we don't resolve the virtual with another init script.
(In reply to comment #7) > Actually udev doesn't pull anything into the runlevel. The "need dev-mount" > makes OpenRC go out and look for a dev-mount provider and try to run it. If > there isn't a provider in the runlevel, the only reason udev-mount is runnig > is that there isn't another provider installed in init.d. It is safest to > add udev-mount to the runlevel. That makes sure we don't resolve the virtual > with another init script. I understand that, but udev actually has "need udev-mount", not "need dev-mount". This means udev-mount will always be started before udev, and thus there should be no need to explicitly add it to the runlevel. Anyway, the dependency resolution in OpenRC seems to be a little flawed. It ought to completely resolve the "need" and "use" dependencies first to determine the set of all services that are to be started, and *then* calculate the start order by considering the "need", "use", "before", and "after" constraints of all the services in the set. Side question: What's the difference between "use" and "before"? The man page says "use" "will attempt to start any services we use that have been added to the runlevel," but if they're in the runlevel, then "before" would achieve the same effect, wouldn't it?
now you mention it, i finally find it in man page. not on openrc official webpage the last time i tried if those lines about need/use/before/after are all others (except the author) can know about design of openrc dependency, it's definitely unclear. either the rules are not strict enough for us to write the script right, or openrc failed to do the right thing while the init.d script writer (even if it's openrc author) follow the loosely defined rules system. what rule shall or shall not add service to the level automatically what will happen when a circular dependency is made, i don't see a critical warning afaik until reboot what will happen when a service@sysinit depends on service@default beside simply fixing init.d scripts or openrc to avoid problems we found so far, please also make the rules design and what openrc will do about it in detail, let everyone think about to prove (or just feel) it right
(In reply to comment #8) > (In reply to comment #7) > I understand that, but udev actually has "need udev-mount", not "need > dev-mount". This means udev-mount will always be started before udev, and > thus there should be no need to explicitly add it to the runlevel. You are right about the relationship between udev-mount and udev. Sorry I mislead you in the previous comment. the relationship in question is between dev-mount (provided by udev-mount) and devfs. devfs must run between dev-mount and dev (which is provided by udev). If there isn't a dev-mount provider in the runlevel, the "use dev-mount" dependency in devfs doesn't try to start anything. Adding udev-mount to the runlevel makes it satisfy the "use dev-mount" dependency so that devfs gets run in the correct order. > Side question: What's the difference between "use" and "before"? The man > page says "use" "will attempt to start any services we use that have been > added to the runlevel," but if they're in the runlevel, then "before" would > achieve the same effect, wouldn't it? Before means start the current service before the listed services and stop the current service after the listed services. Use means try to start the listed services before the current service. The "listed services" must be scripts in a runlevel or be provided by scripts in a runlevel. None of these dependencies care whether the listed services start successfully or not. (In reply to comment #9) > now you mention it, i finally find it in man page. not on openrc official > webpage the last time i tried > if those lines about need/use/before/after are all others (except the > author) can know about design of openrc dependency, it's definitely unclear. > either the rules are not strict enough for us to write the script right, or > openrc failed to do the right thing while the init.d script writer (even if > it's openrc author) follow the loosely defined rules system. > > what rule shall or shall not add service to the level automatically No dependencies automatically add services to the current runlevel. I do want to look into this code more after we get 0.11.x to stable, because there is an internal runlevel called "needed" which I think is where needed services are supposed to be added. I don't want to pursue that on this bug however. You can see what is in the runlevels by doing: rc-status -a > what will happen when a circular dependency is made, i don't see a critical > warning afaik until reboot The problem is that there isn't an easy way to detect those when the dependency tree is being generated. this would have to be another tool that scans the deptree probably. Again, I don't really want to pursue that on this bug. > what will happen when a service@sysinit depends on service@default That depends on what the dependency is. If it is use, before or after, nothing will happen. But if it is need, the service gets started. I would question though why a service in sysinit needs to depend on something in default. > beside simply fixing init.d scripts or openrc to avoid problems we found so > far, please also make the rules design and what openrc will do about it in > detail, let everyone think about to prove (or just feel) it right I'm not exactly sure what you mean by this.
I'm closing this since openrc-0.11.3 will automatically add udev-mount to the sysinit runlevel if udev is there. This needs to be added in this situation because the "use dev-mount" dependency in devfs is not satisfied if it is not added. You can't change use to need in this case, because there are situations where there will not be a dev-mount provider installed (such as static /dev).
Couldn't you just add "after udev-mount" to devfs? Then when udev pulls in udev-mount, devfs will start after it. Or am I not understanding OpenRC's startup sequencing algorithm? It seems intuitively that the algorithm is deficient.
you're telling us that the following dependency is not enough to make devfs starts after udev-mount while only udev and devfs is added to rundevel udev: need sysfs udev-mount devfs: need dev-mount udev-mount: provide dev-mount please fix openrc instead of init.d or ebuild script
No, devfs has *use* dev-mount, as has been mentioned several times. Still, the behavior of OpenRC is counter-intuitive.
(In reply to comment #12) > Couldn't you just add "after udev-mount" to devfs? Then when udev pulls in > udev-mount, devfs will start after it. Or am I not understanding OpenRC's > startup sequencing algorithm? It seems intuitively that the algorithm is > deficient. It couldn't be "after udev-mount" because there is at least one other provider of dev-mount, so I would have to refer to the virtual. I would have to change the line that says "use dev-mount" to "after dev-mount" If you want to test, change line 8 of /etc/init.d/devfs from "use dev-mount" to "after dev-mount", remove udev-mount from your sysinit runlevel and reboot. (In reply to comment #13) > you're telling us that the following dependency is not enough to make devfs > starts after udev-mount while only udev and devfs is added to rundevel > > udev: need sysfs udev-mount > devfs: need dev-mount > udev-mount: provide dev-mount This breaks, as has been said several times, because "dev-mount" is optional. If someone isn't using a device manager at all but is running with static /dev nodes, they still need this devfs script, but they will not have a "dev" or "dev-mount" provider on their system.
