Bug#589250: insserv: Strange sequencing of xdm
Petter> Any proposals on where to add such information? Which manual Petter> page or other documentation would have worked for you? I read /usr/share/doc/sysv-rc/README.Debian and I wasn't cured of my delusion, so I guess it should be there. -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD Ham is for reading, not for eating. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589250: insserv: Strange sequencing of xdm
severity 589250 minor thanks [Ian Zimmerman] > So, probably demote this bug to minor, mostly targeting > documentation so as to avoid the same confusion in other curious > people. Any proposals on where to add such information? Which manual page or other documentation would have worked for you? > BTW - why keep the symlink farm around at all when it is not used? The symlink farm is used by sysv-rc/insserv/startpar to know if a service is enabled or not for a given runlevel. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589250: insserv: Strange sequencing of xdm
Petter> I would expect some script having X-Start-Before (reverse Petter> dependency) on xdm. There is no special handling of xdm in Petter> insserv. I looked at the graph, and also at the insserv source code. I didn't find any more dependencies involving xdm than the ones we already knew about. I think the behavior is a consequence of this: /* * Put not existing services into a guessed order. * The maximal order of not existing services can be * set if they are required by existing services. */ in listing.c, plus the fact that I don't have any of the Should-Start services installed. I can't say for sure because I don't really understand the code, in fact it makes me cry. :-( However, further indirect evidence for this hypothesis is that xdm ends up sequenced the same even if I remove the 3 scripts immediately before it (cron, fetchamil, and mpd), leaving a hole in the sequence numbers. (Yes, I took care to first do insserv -f -r xdm, then insserv xdm.) I must also admit that I misunderstood how the parallelized /etc/rc works. I thought the symlink farm and the numbers still determined the scheduling; now I see all that is ignored and only the .depend.* files are relevant (and indeed xdm starts as early as the dependencies allow). So, probably demote this bug to minor, mostly targeting documentation so as to avoid the same confusion in other curious people. BTW - why keep the symlink farm around at all when it is not used? -- Ian Zimmerman gpg public key: 1024D/C6FF61AD fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD Ham is for reading, not for eating. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589250: insserv: Strange sequencing of xdm
[Ian Zimmerman] > As elaborated in [1] , one of the easiest ways to speed up booting, or > at least improve the perception of speed (and isn't perception > everything? :-P ) is to start the X display manager (xdm, kdm, gdm or > whatever) early in the sequence. I just did the insserv transition > and I'd been quite curious where the xdm script would end up. I was > quite disappointed to find it again close to the end: at rc2.d/S06, > just before bootlogs (S07) and after cron, fetchmail, and mpd (S05). Note that with parallel booting, which is the default in Squeeze, there is good in startpar to start xdm, kdm and gdm as early as possible, which will not be reflected in the static sequence numbers. > Furthermore, I can't see why insserv makes this decision: its > complete LSB dependencies are as follows: I suspect there is some reverse dependency in effect. Try to look at the dependency graph as generated by '/usr/share/insserv/check-initd-order -g' to get a better idea of the complete start ordering. > What is going on? Does the insserv sequence algorithm have a > special case for xdm? I would expect some script having X-Start-Before (reverse dependency) on xdm. There is no special handling of xdm in insserv. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589250: insserv: Strange sequencing of xdm
Package: insserv Version: 1.14.0-2 Severity: normal As elaborated in [1] , one of the easiest ways to speed up booting, or at least improve the perception of speed (and isn't perception everything? :-P ) is to start the X display manager (xdm, kdm, gdm or whatever) early in the sequence. I just did the insserv transition and I'd been quite curious where the xdm script would end up. I was quite disappointed to find it again close to the end: at rc2.d/S06, just before bootlogs (S07) and after cron, fetchmail, and mpd (S05). Furthermore, I can't see why insserv makes this decision: its complete LSB dependencies are as follows: # Required-Start:$local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: xfs $named slapd hal # Should-Stop: xfs $named slapd hal The components of *_fs are not present in rc2 ; I don't have anything from the Should-Start installed (ie. none of the packages with the scripts listed directly, nor any of the components of $named). What is going on? Does the insserv sequence algorithm have a special case for xdm? [1] http://www.debian-administration.org/articles/620 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.34.1-core2-i (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages insserv depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib insserv recommends no packages. Versions of packages insserv suggests: pn bootchart (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
