In my laptop I have two nics (wired and wireless). With udev-rules I have assigned eth0 to the wired nic and eth1 to the wireless nic. I have created a link for net.eth1. I have put net.eth0 and net.eth1 in the default runlevel. I use netplug and wpa_supplicant. If I boot with RC_PARALLEL_STARTUP="no" both nics work fine and all daemons are started including the daemons that depend on the network (e.g. netmount and sshd). If I boot with RC_PARALLEL_STARTUP="yes" both nics work fine, all net.eth daemons are started but all daemons that depend on the network are not started. If I remove one of the net.eth daemons from the default runlevel and I boot with RC_PARALLEL_STARTUP="yes" both nics work fine and all daemons are started. If I boot with RC_PARALLEL_STARTUP="yes" (both net.eth daemons are back in default runlevel), disable one interface (by removing the cable or stopping the radio), the corresponding daemon gets inactive, after enabling the interface, the corresponding daemon get active again, but all daemons that depend on the network are still not started. If I boot with RC_PARALLEL_STARTUP="yes", manually start all daemons in default runlevel with rc, disable radio, remove cable then both net.eth daemons are inactive and all the daemons that depend on the network are stopped. If I plugin the network cable net.eth0 is started and all the daemons that depend on the network are started. However if I don't plugin the network cable but enable radio then net.eth1 is started, but all the daemons that depend on the network are not started. If I boot with RC_PARALLEL_STARTUP="yes", manually start all daemons in default runlevel with rc, remove cable, disable radio then both net.eth daemons are inactive and all the daemons that depend on the network are stopped. If I enable radio net.eth1 is started and all the daemons that depend on the network are started. However if I don't enable the radio but plugin the network cable then net.eth0 is started, but all the daemons that depend on the network are not started. I hope I was able to describe the problem in a way that you understand what the problem is. If you need more information or you want me to test something then please let me know. Thanks! emerge --info Portage 2.1.1_pre5-r3 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r5 i686) ================================================================= System uname: 2.6.17-gentoo-r5 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.12.4 Last Sync: Sat, 26 Aug 2006 01:00:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--noconfmem" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.ISO-8859-1" LC_ALL="en_US.ISO-8859-1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi alsa arts artswrappersuid asf bash-completion bzip2 cups dbus directfb dri elibc_glibc exif ffmpeg flac foomaticdb gif gphoto2 gtk hal imagemagick input_devices_keyboard input_devices_mouse java jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux linguas_en mmx mp3 mpeg musicbrainz nfs nptl nptlonly nsplugin ogg opengl pdf png ppds python qt3 qt4 quicktime rdesktop real ruby samba sqlite sse ssl svg sysfs theora tiff truetype usb userland_GNU video_cards_i810 vim-with-x vorbis wifi win32codecs x264 xcomposite xine xorg xvid zlib" Unset: CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
If I have the following daemons in the default runlevel the problems occurs; netmount local net.eth0 net.eth1 syslog-ng vixie-cron sshd However if I add cpufreqd to the default runlevel the problem doesn't occur anymore. All daemons in the default runlevel are started after a boot. If I remove cpufreqd from the default runlevel the problem is back.
(In reply to comment #1) > However if I add cpufreqd to the default runlevel the problem doesn't occur > anymore. All daemons in the default runlevel are started after a boot. If I > remove cpufreqd from the default runlevel the problem is back. So to clarify, all above conditions work without error if cpufreq is in the default runlevel? Also, what is the issue with daemons not starting? Is it that they are inactive or something else?
(In reply to comment #2) > (In reply to comment #1) > > However if I add cpufreqd to the default runlevel the problem doesn't occur > > anymore. All daemons in the default runlevel are started after a boot. If I > > remove cpufreqd from the default runlevel the problem is back. > > So to clarify, all above conditions work without error if cpufreq is in the > default runlevel? Correct. If I put an extra non-network dependant daemon in the default runlevel. Everything works fine. If I remove this daemon and only have the previous mentioned daemons in the default runlevel. It doesn't work. > Also, what is the issue with daemons not starting? Is it that they are inactive > or something else? > The net.eth* daemons have status started, but the daemons that depend on the net.eth daemon have status stopped. If you have some trouble to reproduce this problem and if you want we can arrange something that I give you access to my laptop. Thanks.
(In reply to comment #3) > Correct. If I put an extra non-network dependant daemon in the default > runlevel. Everything works fine. If I remove this daemon and only have the > previous mentioned daemons in the default runlevel. It doesn't work. Strange. I'll try and replicate this. > > > Also, what is the issue with daemons not starting? Is it that they are inactive > > or something else? > > > > The net.eth* daemons have status started, but the daemons that depend on the > net.eth daemon have status stopped. Yes, but the daemons that depend on net would have either said "Error - deps not up" or "scheduled when net.foo has started". I'd like to see the exact message. Also, please attach your conf.d/rc and conf.d/net to this bug. > If you have some trouble to reproduce this problem and if you want we can > arrange something that I give you access to my laptop. I've not tried to replicate it yet due to just getting back off holiday :) I'll see if I get time during the week. Thanks for the offer, but I don't see how access would help as on reboot sshd won't start ;) Also, my laptop has wired and wireless connections at work, so I should be able to reproduce it.
(In reply to comment #4) > Yes, but the daemons that depend on net would have either said "Error - deps > not up" or "scheduled when net.foo has started". I'd like to see the exact > message. Also, please attach your conf.d/rc and conf.d/net to this bug. I get "scheduled when net.foo has started". I will attach both files.
Created attachment 95871 [details] /etc/conf.d/net
Created attachment 95872 [details] /etc/conf.d/rc
OK, I'm not seeing this. Could you tar up your /etc and email it to me please?
(In reply to comment #8) > OK, I'm not seeing this. Could you tar up your /etc and email it to me please? > Hi Roy, I have emailed my /etc to you. If you want I can give you access to my laptop. I know sshd wont come up in some cases, but then I can manually start it for you (or put something in cron).
Could you test the patch on bug #148700 to see if that fixes this for you?
(In reply to comment #10) > Could you test the patch on bug #148700 to see if that fixes this for you? > Hi Roy, I have tested the patch, but unfortunately the problem isn't resolved.
OK, after careful analysis, this is a two part bug. Part 1 is that services sometimes get stuck when scheduled to start unless RC_PARALLEL_STARTUP=yes Part 2 is that only the final net service that stops the others can schedule a start of those services Part 1 should be fixed in baselayout-1.12.5-r2 as that's bug #148700 Part 2 is too complex a fix for the 1.12 branch as it's now our "stable" branch and should be fixed in baselayout-1.13
OK, patch is in svn and will be in baselayout-1.13
(In reply to comment #13) > OK, patch is in svn and will be in baselayout-1.13 > I have just tried baselayout-1.13.0_alpha1 and it works great. All problems I mentioned are solved with this version. Great work, well done!! I'm very happy you were able to determine the cause for this problem. Also very nice that with parallel startup you now see all messages. I noticed a small problem in the output though; The warning messages are not correct, I get for example; WARNING: sshd is scheduled to start when net.eth0, net.eth1 or net.eth0 has started. or WARNING: netmount is scheduled to start when net.eth0, net.eth1 or net.eth0 and net.eth1 has started. Also there is something wrong with indentation. First warning starts at the left site of the screen, second 2/3 from the left and the third in the middle. Thanks again! Baselayout in Gentoo is super.
Also noticed another problem with baselayout-1.13.0_alpha1. My laptop doesn't shutdown anymore. It ends with; INIT: no more processes left in this runlevel Do you want me to create separate bugreports for these problems?
(In reply to comment #15) > Also noticed another problem with baselayout-1.13.0_alpha1. My laptop doesn't > shutdown anymore. It ends with; > INIT: no more processes left in this runlevel > > Do you want me to create separate bugreports for these problems? The reason why I emailed you instead of using bugzilla was because baselayout-1.13 isn't in portage yet, and I don't like bugs against things not in portage :) So until then, email me separately please!
baselayout-1.13.0_alpha1 is now in portage, package.masked.
(In reply to comment #16) > The reason why I emailed you instead of using bugzilla was because > baselayout-1.13 isn't in portage yet, and I don't like bugs against things not > in portage :) So until then, email me separately please! > Will do next time, I'm sorry, I didn't know this.
