What happens if you choose "Retry communication" from the menu after booting up *without* restarting the client? Does it work then? If the main problem is really that your network is not ready when starting the service, this should help. Otherwise I'm afraid it must be caused by something else.

Hm, I just have to correct myself: it SHOULD, but DOESN'T!
See http://lists.alioth.debian.org/pipermail/pkg-boinc-devel/2007-November/001063.html

I couldn't find the relevant ticket in BOINC trac although from the debian report I assume that it has been reported upstream. Has this ever been solved?
(I can still reproduce it on my machine with 5.10.45)
Actually I think that rather than hacking with any delays in boinc init script we should ensure that the client uses the connection (even after some delay) when it is available, hm?

---

Milos Jakubicek

HOW do I tell the client to sleep 20 (or less) seconds before starting BOINC client as daemon ?

What do I have to add to which init script ?
...

See here in this same thread.

Waiting 15 seconds did solve the problem of boinc-client started as demon during boot being unable to connect to any site in the www ... Many thanks to everyone for helping.

I would prefer to add the "sleep X" to the script which calls "/etc/init.d/boinc-client" during boot and not to the start option of the boinc-client as this will put the client into sleep WHENEVER I start, restart or reload it :(
Even better would be to start boinc-client during boot in the background with a delay equal to the time I need to login after boot and start boinc-manager manually, so that I wont even notice that there is a delay ...
Can you please tell me which script is calling "/etc/init.d/boinc-client" for the first time during booting f9 ?

MfG, MEX

PS: Retry Communication was one of the first things I tried before even starting this topic :rollingeyes:

---

0xFF

I re-wrote the wiki article to reflect the fact that it's not necessary to add your username to the boinc group just to have the manager connect to the client without giving the password. I doubt adding your username to the boinc group could cause any problem (it never caused a problem for me) but if you do reinstall then perhaps try not adding username to the boinc group.

I did a bit of formatting to http://boinc.berkeley.edu/wiki/Installing_on_Linux#Fedora_7.2C_8_and_9 to make the commandos more clear for those which seldom use a shell, or are new to Linux.

On my FSC ESPRIMO Mobile V5535 I will now try to reduce the SLEEP to as few seconds as possible, and start the init script with this delay in the background to avoid unnecessary delaying the boot process.

For my PS3 I still need help how to get "powerpc-pc-linux-gnu" applications for the projects in which I am participating :(

Getting applications which use more than the PPC core of my PS3 would be the last step, for which I will need information about how to compile my own applications for the various projects to which my boinc-client is attached.

MfG, MEX

---

0xFF

/etc/rc starts all services including boinc-client. Open it in an editor and add the red lines

# Now run the START scripts.
for i in /etc/rc$runlevel.d/S* ; do

# Check if the subsystem is already up.
subsys=${i#/etc/rc$runlevel.d/S??}
[ -f /var/lock/subsys/$subsys ] && continue
[ -f /var/lock/subsys/$subsys.init ] && continue
if strstr $i "boinc-client"; then
echo "sleep 15 for boinc-client"
sleep 15
fi
check_runlevel "$i" || continue

Before the above mod, the rc script just runs each service's start script. The mod simply makes rc look at the name of each start script and if the name contains the string 'boinc-client' then rc sleeps for 15 seconds before it runs the script. Thus you should get the delay only at boot time, not whenever boinc-client starts.

This isn't exactly what I wanted, I would prefer to start the client in the BACKGROUND with a delay of 10-12 seconds so that the other scripts started during startup don't have to wait.

I assume my network is already started in the BACKGROUND to avoid delaying startup, and starting boinc as a demon can be added to this script AFTER starting the network instead of starting it on its own, which would make delaying boinc not necessary ...

I agree with Milos that hacking startup scripts is not the best fix so I submitted Trac ticket 707

Sadly the ticket is already closed as NICOLAS wasn't able to understand the problem and thought that a new feature of client 6.1.6

 <start_delay>
    Specify a number of seconds to delay running applications after client startup. New in 6.1.6

would cure the problem :rollingeyes:

But the problem isn't that I need a delay of the APPLICATIONS, I need a delay of the CLIENT !
So not the client needs to be modified, only the RPM for f9 needs to be modified in a way that makes sure that boinc is started as a demon AFTER the access to the www has been initialized ... or the wiki needs a new instruction how to start the client during startup as a demon if the user has the same problems with a delay of the initialisation of the network.

MfG, MEX

---

0xFF

So not the client needs to be modified, only the RPM for f9 needs to be modified in a way that makes sure that boinc is started as a demon AFTER the access to the www has been initialized ... or the wiki needs a new instruction how to start the client during startup as a demon if the user has the same problems with a delay of the initialisation of the network.

Once again: the client indeed NEEDS to be modified. It's a known issue that it cannot use newly available connections after its start. I've just got a message from Frank S. Thomas (who is the maintainer of the debian packages of boinc) that this should be fixed by the asynchronous GUI RPC in BOINC 6.4.

As a workaround for now I'll modify the init script to wait for the network or named facility -- this should solve the issue in your case but it cannot solve the problem generally (the most troubles regarding this come from laptop users migrating all the time between various wireless connections while not restarting their machines often but using suspend to ram/disk instead of it).

I'll release new package together with new BOINC 6...hopefully soon, I'm just waiting for the 6.2.15 bugfix release.

---

Milos Jakubicek

Sadly the ticket is already closed as NICOLAS wasn't able to understand the problem and thought that a new feature of client 6.1.6

 <start_delay>
    Specify a number of seconds to delay running applications after client startup. New in 6.1.6

would cure the problem :rollingeyes:

But the problem isn't that I need a delay of the APPLICATIONS, I need a delay of the CLIENT !

Not quite a respectful tone that ;)

And I did apologize for the misunderstanding in the ticket comments.

---

...You can introduce a delay by editing /etc/init.d/boinc-client and putting a line "sleep x", where x = the seconds to delay, just before the "echo -n Starting BOINC client as daemon". A 1 or 3 minute delay there might fix the problem...

Currently a delay of 12 seconds seem to cure my problem, while 10 seconds are not enough, and I will use this workaround until a new update is released.

Once again: the client indeed NEEDS to be modified. It's a known issue that it cannot use newly available connections after its start. I've just got a message from Frank S. Thomas (who is the maintainer of the debian packages of boinc) that this should be fixed by the asynchronous GUI RPC in BOINC 6.4.
(the most troubles regarding this come from laptop users migrating all the time between various wireless connections while not restarting their machines often but using suspend to ram/disk instead of it)

I have no problem with waiting for a new RPM as I currently know how to cure my problem, and as I don't use WLAN until now because of problems with my AR5007EG chip which seems to be a ZyDAS zd1211rw compatible chip modified by the new owner Atheros.
Because of BOINC, I also usually don't care about suspend to RAM/disk as my battery only lasts ~1 h (45min according to f9).

So not the client needs to be modified, only the RPM for f9 needs to be modified in a way that makes sure that boinc is started as a demon AFTER the access to the www has been initialized ... or the wiki needs a new instruction how to start the client during startup as a demon if the user has the same problems with a delay of the initialisation of the network.

As a workaround for now I'll modify the init script to wait for the network or named facility -- this should solve the issue in your case but it cannot solve the problem generally.

I'll release new package together with new BOINC 6...hopefully soon, I'm just waiting for the 6.2.15 bugfix release.

How about not starting the client as a demon during startup, but using CRON to start it with a user definable delay (12 seconds in my case ) after CRON has been started during booting f9 ?

Then a description HOW TO start boinc-client with CRON with a delay of X seconds after startup in the WIKI as another option which can be used instead of "/sbin/chkconfig boinc-client on" in http://boinc.berkeley.edu/wiki/Installing_on_Linux#Fedora_7.2C_8_and_9 would be enough, and wont hamper those which don't share my problem.

MfG, MEX

---

0xFF

Well, I can't see why you're so concerned over a 15 second delay. I mean really, if you reboot once a day then in 1 year you'll lose a total of 1.5 hours. If you schedule things properly you could find something productive to too in that 15 seconds, for example, tidy up your desk, get a coffee, loosen your collar, pet the dog, take a Valium, put on some music you find relaxing, practice not rolling your eyes, whatever.

As long as it will be the only UGLY patch, it wont matter ... but have you ever seen one of these cars with lots of ugly patches to conceal little damages and/or to avoid that water gets in and rust destroys the car ? Or even worse, one of these cars where the owner doesn't even care about applying patches ?
BOINC wont stay the only program I install on my notebook, and as I don't want to have many patches on my pristine f9, I intend to avoid the first one as long as possible :(
A delay of 12 seconds for a single program isn't much ... but when 10 programs would require a delay of 12 seconds each, I would need 2 minutes more WHENEVER I boot my notebook, which I usually do several times per day.

However, if you are absolutely certain your life is going to hell because you've lost 15 seconds then spend 20 minutes (that's a compelling economy) reading this thread where we've been discussing how to start the client (installed via Berkeley installer) after a delay.

...
if [ -x /home/poorboy/BOINC/boinc ]
then
echo "Starting BOINC in 10 seconds ..."
( cd /home/poorboy/BOINC; sleep 10; sudo -u poorboy ./boinc --daemon --allow_remote_gui_rpc ) &
fi
...

Does the & put the commands in ( ) separated by ; in the background and continues with the next command without waiting ?
Then this is exactly what I am looking for :D
Many thanks for the help.

MfG, MEX

PS: It seems to work as expected :D

[root@localhost mex]# /sbin/service boinc-client restart
Stopping BOINC client daemon:                              [  OK  ]
Starting BOINC client as a daemon in 11 seconds ...
[root@localhost mex]# 
Starting BOINC client as a daemon:                         [  OK  ]

---

0xFF

Does the & put the commands in ( ) separated by ; in the background and continues with the next command without waiting ?
Then this is exactly what I am looking for :D
Many thanks for the help.

As I understand it, the & does put a task in the background. In fact, I was reading about that late last week.

---

Kathryn :o)

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

I'm pretty curious whether this could solve your problem (without needing any further delays etc.)

Anyway its really strange to me that your network takes so long to come up. Did you measure how long does it take indeed (the best way is probably to boot up without networking and then type "time ifup eth0" -- assuming you're using the eth0 interface of course)?

---

Milos Jakubicek

Back to the Mac problem...

PS: "power-pc-linux-gnu" doesn't look right !
( I would expect ppc instead of pc or powerpc without -pc )
Can it be that there is a faulty platform name in the RPM ?

That's definitely not correct, it should be "powerpc-linux-gnu" according to what Kathryn told me (and what is on http://boinc.berkeley.edu/trac/wiki/BoincPlatforms) -- seems that the config.guess doesn't recognize the platform correctly. I've rebuilt boinc (still 5.10.45) with --with-boinc-platform=powerpc-linux-gnu and ppc64-linux-gnu respectively, please try the new RPM from:

http://koji.fedoraproject.org/koji/buildinfo?buildID=58570

Besides that, please read http://boinc.berkeley.edu/trac/wiki/BuildMacApp (however I don't know how much the information there is up to date).

---

Milos Jakubicek

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

This is ugly as normally desktops don't run DNS server.

Rather than straight sleeping for 12 seconds, one could implement a search for default route to appear. With optional max delay, such as this:

MAXWAIT=30   # wait for no longer than 30 seconds

WAIT=0
ISROUTE=`/sbin/route -n | grep "^0.0.0.0" >/dev/null; echo $?`
while [ ${ISROUTE} -eq  1 -o ${MAXWAIT} -gt ${WAIT} ]; do
    sleep 1
    ISROUTE=`/sbin/route -n | grep "^0.0.0.0" >/dev/null; echo $?`
    let WAIT=${WAIT}+1
done

This should mostly take care of no net connectivity at boot time. The problem of users with laptops using WiFi sporadically still remains though.

Hmmm ... I'm sure that the loop could be done a bit more elegant by moving the route construct to while line directly. I couldn't figure it right now ...


[edit]

Anyway its really strange to me that your network takes so long to come up.

Mex, I wonder if you're using static IP addresses or DHCP assigned ones? I've seen quite long network startup times when DHCP was in play ... sometimes DHCP servers just take some time to respond.

---

Metod ...

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

This is ugly as normally desktops don't run DNS server.

I'm unsure whether this facility indicates running a named (e.g. bind). In the LSB specification one can read:

$network: basic networking support is available. Example: a server program could listen on a socket.

$named: IP name-to-address translation, using the interfaces described in this specification, are available to the level the system normally provides them. Example: if a DNS query daemon normally provides this facility, then that daemon has been started.

Hence $named indicates rather resolution-ready system than running named daemon, doesn't it?

Rather than straight sleeping for 12 seconds, one could implement a search for default route to appear. With optional max delay, such as this:

Of course this is possible, but I still think there should be a more clean solution -- the very cleanest is to fix this ugly bug in the boinc client, but this doesn't seem to happen soon :(
Mex's problem still has a more-or-less acceptable solution, as opposed to the situation when the network is really not available at the boot and appears later (laptop & wireless)...

Mex, I wonder if you're using static IP addresses or DHCP assigned ones? I've seen quite long network startup times when DHCP was in play ... sometimes DHCP servers just take some time to respond.

I assume it to be so (slow DHCP response) -- but 12-15 seconds are too many in any case.

---

Milos Jakubicek

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

I'm pretty curious whether this could solve your problem (without needing any further delays etc.)

Anyway its really strange to me that your network takes so long to come up. Did you measure how long does it take indeed (the best way is probably to boot up without networking and then type "time ifup eth0" -- assuming you're using the eth0 interface of course)?

I try the comment "Required-Start: $network $named" as soon as possible ...

Currently I need at least "sleep 12" for boinc-client, which is ~ the time f9 needs to finish boot and I need to login & start boinc-manager.

I use a Buffalo WHR-G125-EU WLAN router with DHCP ( connected either to http://www.FunkFeuer.at or http://www.blizznet.at ) to which I currently connect my FSC ESPRIMO Mobile V5535 notebook with a LAN cable. Currently the WHR-G125-EU still has its original firmware and I use Fedora 9 on my V5535. I didn't have any problems when I used the Win XP client started as a service on my V5535, so i assume this is specific to how f9 installs Linux on my V5535.

MfG, MEX

---

0xFF

Currently I need at least "sleep 12" for boinc-client, which is ~ the time f9 needs to finish boot and I need to login & start boinc-manager.

OK, but maybe we could narrow the problem a bit if you'd try whether it's really caused by slow DHCP response or not. FYI I'm using V3550 and I can't remember about waiting for DHCP longer than 3 seconds on ethernet (wifi takes usually longer -- about 3 seconds to associate and next 3 waiting for DHCP response).

---

Milos Jakubicek

Mex, please, could you try changing the following line in the *original* init script:

# Required-Start: $network

into

# Required-Start: $network $named

This is ugly as normally desktops don't run DNS server.

I'm unsure whether this facility indicates running a named (e.g. bind).
In the LSB specification one can read:

$network: basic networking support is available. Example: a server program could listen on a socket.

$named: IP name-to-address translation, using the interfaces described in this specification, are available to the level the system normally provides them. Example: if a DNS query daemon normally provides this facility, then that daemon has been started.

Hence $named indicates rather resolution-ready system than running named daemon, doesn't it?

OK, changed the script to ask for $named and tried to undo my old changes to the script

...
case "$1" in
  start)
        cd $BOINCDIR

        if [ ! -d projects ] ; then
          echo -n "The BOINC client requires initialization (no projects attached)."
          echo_warning
          echo 
        fi

	echo -n "Starting BOINC client as a daemon:"
	( daemon --check $BOINCEXE --user $BOINCUSER +19 "$BOINCEXE $BOINCOPTS" >>$LOGFILE 2>>$ERRORLOG & );
	sleep 1; PID=`pidof -s -x -o $$ -o $PPID -o %PPID $BOINCEXE`;
	if [ $PID ]; then
	  touch $LOCKFILE && echo_success || echo_failure
	fi
	echo ;;
#   echo "Starting BOINC client as a daemon in 15 seconds ..."
# ( sleep 15; echo; echo -n "Starting BOINC client as a daemon:"
# ( daemon --check $BOINCEXE --user $BOINCUSER +19 "$BOINCEXE $BOINCOPTS" >>$LOGFILE 2>>$ERRORLOG & );
#   sleep 1; PID=`pidof -s -x -o $$ -o $PPID -o %PPID $BOINCEXE`;
#   if [ $PID ]; then touch $LOCKFILE && echo_success || echo_failure fi; echo ) & ;;
  stop)
...

As soon as I reboot, I will see if $named works as expected.

MfG, MEX

PS: after reboot, I still get the following error:

Fre 08 Aug 2008 13:55:03 CEST||Starting BOINC client version 5.10.45 for i686-pc-linux-gnu
Fre 08 Aug 2008 13:55:03 CEST||log flags: task, file_xfer, sched_ops
Fre 08 Aug 2008 13:55:03 CEST||Libraries: libcurl/7.18.2 NSS/3.12.0.3 zlib/1.2.3 libidn/0.6.14
Fre 08 Aug 2008 13:55:03 CEST||Executing as a daemon
Fre 08 Aug 2008 13:55:03 CEST||Data directory: /var/lib/boinc
Fre 08 Aug 2008 13:55:03 CEST||Processor: 1 GenuineIntel Intel(R) Celeron(R) CPU          540  @ 1.86GHz [Family 6 Model 22 Stepping 1]
Fre 08 Aug 2008 13:55:03 CEST||Processor features: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
Fre 08 Aug 2008 13:55:03 CEST||OS: Linux: 2.6.25.11-97.fc9.i686
Fre 08 Aug 2008 13:55:03 CEST||Memory: 2.71 GB physical, 3.99 GB virtual
Fre 08 Aug 2008 13:55:03 CEST||Disk: 62.98 GB total, 55.57 GB free
Fre 08 Aug 2008 13:55:03 CEST||Local time is UTC +2 hours
Fre 08 Aug 2008 13:55:03 CEST|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1482516; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SHA-1 Collision Search Graz|URL: http://boinc.iaik.tugraz.at/sha1_coll_search/; Computer ID: 31994; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|Rectilinear Crossing Numbers|URL: http://dist.ist.tugraz.at/cape5/; Computer ID: 39216; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|lhcathome|URL: http://lhcathome.cern.ch/lhcathome/; Computer ID: 9703324; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|orbit@home|URL: http://orbit.psi.edu/oah/; Computer ID: 8705; location: (none); project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SETI@home Beta Test|URL: http://setiweb.ssl.berkeley.edu/beta/; Computer ID: 29977; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4482760; location: home; project prefs: default
Fre 08 Aug 2008 13:55:03 CEST||General prefs: from orbit@home (last modified 27-Jun-2008 14:48:32)
Fre 08 Aug 2008 13:55:03 CEST||Host location: none
Fre 08 Aug 2008 13:55:03 CEST||General prefs: using your defaults
Fre 08 Aug 2008 13:55:03 CEST||Reading preferences override file
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit memory usage when active to 1388.09MB
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit memory usage when idle to 2498.56MB
Fre 08 Aug 2008 13:55:03 CEST||Preferences limit disk usage to 1.86GB
Fre 08 Aug 2008 13:55:08 CEST|Einstein@Home|Restarting task h1_0236.80_S5R4__39_S5R4a_1 using einstein_S5R4 version 602
Fre 08 Aug 2008 13:55:08 CEST|lhcathome|Sending scheduler request: To fetch work.  Requesting 1056 seconds of work, reporting 0 completed tasks
Fre 08 Aug 2008 13:55:14 CEST|lhcathome|Scheduler request failed: Couldn't resolve host name
Fre 08 Aug 2008 13:56:15 CEST|lhcathome|Sending scheduler request: To fetch work.  Requesting 1056 seconds of work, reporting 0 completed tasks
Fre 08 Aug 2008 13:56:17 CEST||Project communication failed: attempting access to reference site
Fre 08 Aug 2008 13:56:18 CEST||Access to reference site failed - check network connection or proxy configuration.
Fre 08 Aug 2008 13:56:20 CEST|lhcathome|Scheduler request failed: Couldn't resolve host name

---

0xFF

[mex@localhost ~]$ time ifup eth0
bash: ifup: command not found

real	0m0.001s
user	0m0.001s
sys	0m0.001s
[mex@localhost ~]$ su
Passwort: 
[root@localhost mex]# time ifup eth0
bash: ifup: command not found

real	0m0.002s
user	0m0.000s
sys	0m0.001s
[root@localhost mex]# time

real	0m0.000s
user	0m0.000s
sys	0m0.000s
[root@localhost mex]# help time
time: time [-p] PIPELINE
    Execute PIPELINE and print a summary of the real time, user CPU time,
    and system CPU time spent executing PIPELINE when it terminates.
    The return status is the return status of PIPELINE.  The `-p' option
    prints the timing summary in a slightly different format.  This uses
    the value of the TIMEFORMAT variable as the output format.
times: times
    Print the accumulated user and system times for processes run from
    the shell.
[root@localhost mex]#

Anyway its really strange to me that your network takes so long to come up. Did you measure how long does it take indeed (the best way is probably to boot up without networking and then type "time ifup eth0" -- assuming you're using the eth0 interface of course)?

HOW do I boot without networking ?
Shall I boot without the LAN cable connected to my V5535, or do I have to change my f9 boot process ?

MfG, MEX

PS: I am sure the problem originates from some ugly patch f9 has applied to itself during installation on my V5535 :rollingeyes:

---

0xFF

[mex@localhost ~]$ time ifup eth0
bash: ifup: command not found

Ifup is placed under /sbin which is by default not included in $PATH (hence you have to type "/sbin/ifup").

PS: I am sure the problem originates from some ugly patch f9 has applied to itself during installation on my V5535 :rollingeyes:

I doubt this will be the reason as it would affect more users, not only you as it seems to be as far.

---

Milos Jakubicek

[mex@localhost ~]$ time /sbin/ifup eth0
Benutzer können dieses Gerät nicht steuern.

real	0m0.080s
user	0m0.012s
sys	0m0.014s
[mex@localhost ~]$ su
Passwort: 
[root@localhost mex]# time /sbin/ifup eth0

IP-Informationen werden für eth0 bestimmt...dhclient(2177) is already running - exiting. 

This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.

Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com

exiting.
 fehlgeschlagen.

real	0m0.688s
user	0m0.041s
sys	0m0.038s
[root@localhost mex]#

Adding /sbin/ to ifup didnt help much ... please ask a networking & f9 expert which tools to use for solving this problem :(

PS: I am sure the problem originates from some ugly patch f9 has applied to itself during installation on my V5535 :rollingeyes:

I doubt this will be the reason as it would affect more users, not only you as it seems to be as far.

As long as we don't have verified that the same bug doesn't occur on another ESC ESPRIMO Mobile V5535 with a fresh installation of f9 from DVD, it is possible that some device drivers for my SiS Ethernet chips are the origin of my problem ... or maybe the new networkwork manager is causing it because I may have done something during installation which differs from the installation process of other users ...

MfG, MEX

PS: The following is from /var/log/messages

...
Aug 14 07:26:24 localhost kernel: sis190 Gigabit Ethernet driver 1.2 loaded.
Aug 14 07:26:24 localhost kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> GSI 19 (level, low) -> IRQ 19
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Read MAC address from EEPROM
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Unknown PHY transceiver at address 1.
...
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: Using transceiver at address 1 as default.
Aug 14 07:26:24 localhost kernel: 0000:00:04.0: SiS 191 PCI Gigabit Ethernet adapter at f88bc000 (IRQ: 19), 00:1e:33:03:02:ae
Aug 14 07:26:24 localhost kernel: eth0: RGMII mode.
Aug 14 07:26:24 localhost kernel: eth0: Enabling Auto-negotiation.
...
Aug 14 07:26:28 localhost NetworkManager: <info>  starting...
Aug 14 07:26:28 localhost NetworkManager: <info>  eth0: Device is fully-supported using driver 'sis190'.
Aug 14 07:26:28 localhost NetworkManager: <info>  Found new Ethernet device 'eth0'.
Aug 14 07:26:28 localhost NetworkManager: <info>  (eth0): exported as /org/freedesktop/Hal/devices/net_00_1e_33_03_02_ae
Aug 14 07:26:28 localhost NetworkManager: <info>  wlan0: Device is fully-supported using driver 'ath5k_pci'.
Aug 14 07:26:28 localhost NetworkManager: <info>  wlan0: driver supports SSID scans (scan_capa 0x01).
Aug 14 07:26:28 localhost NetworkManager: <info>  Found new wireless (802.11) device 'wlan0'.
Aug 14 07:26:28 localhost NetworkManager: <info>  (wlan0): exported as /org/freedesktop/Hal/devices/net_00_16_44_8d_47_e7
Aug 14 07:26:28 localhost NetworkManager: <info>  Trying to start the supplicant...
Aug 14 07:26:28 localhost NetworkManager: <info>  Trying to start the system settings daemon...
Aug 14 07:26:28 localhost nm-system-settings: Loaded plugin ifcfg-fedora: (c) 2007 - 2008 Red Hat, Inc.  To report bugs please use the NetworkManager mailing 
list.
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... 
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora:     error: File '/etc/sysconfig/network-scripts/ifcfg-eth0' specified device 'eth0', but the de
vice's type could not be determined.
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
Aug 14 07:26:29 localhost nm-system-settings:    ifcfg-fedora:     error: Ignoring loopback device config.
...
Aug 14 07:26:32 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): device state change: 1 -> 2
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): bringing up device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): preparing device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (eth0): deactivating device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): device state change: 1 -> 2
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): bringing up device.
Aug 14 07:26:32 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): preparing device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): deactivating device.
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): device state change: 2 -> 3
Aug 14 07:26:32 localhost NetworkManager: <info>  (wlan0): supplicant interface state change: 1 -> 2.
Aug 14 07:26:32 localhost nm-system-settings: Adding default connection 'Auto eth0' for /org/freedesktop/Hal/devices/net_00_1e_33_03_02_ae
...
Aug 14 07:26:42 localhost kernel: eth0: mii ext = 0000.
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 2 -> 3
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) starting connection 'Auto eth0'
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 3 -> 4
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 4 -> 5
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Aug 14 07:26:42 localhost NetworkManager: <info>  (eth0): device state change: 5 -> 7
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Beginning DHCP transaction.
Aug 14 07:26:42 localhost kernel: eth0: mii lpa = 45e1 adv = 01e1.
Aug 14 07:26:42 localhost kernel: eth0: link on 100 Mbps Full Duplex mode.
Aug 14 07:26:42 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 14 07:26:42 localhost NetworkManager: <info>  dhclient started with pid 2178
Aug 14 07:26:42 localhost NetworkManager: <info>  Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Aug 14 07:26:42 localhost dhclient: Internet Systems Consortium DHCP Client 4.0.0
Aug 14 07:26:42 localhost dhclient: Copyright 2004-2007 Internet Systems Consortium.
Aug 14 07:26:42 localhost dhclient: All rights reserved.
Aug 14 07:26:42 localhost dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Aug 14 07:26:42 localhost dhclient: 
Aug 14 07:26:42 localhost NetworkManager: <info>  DHCP: device eth0 state changed (null) -> preinit
Aug 14 07:26:42 localhost dhclient: Listening on LPF/eth0/00:1e:33:03:02:ae
Aug 14 07:26:42 localhost dhclient: Sending on   LPF/eth0/00:1e:33:03:02:ae
Aug 14 07:26:42 localhost dhclient: Sending on   Socket/fallback
Aug 14 07:26:43 localhost avahi-daemon[1955]: Registering new address record for fe80::21e:33ff:fe03:2ae on eth0.*.
Aug 14 07:26:44 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Aug 14 07:26:44 localhost dhclient: DHCPOFFER from 192.168.11.1
Aug 14 07:26:44 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Aug 14 07:26:44 localhost dhclient: DHCPACK from 192.168.11.1
Aug 14 07:26:44 localhost NetworkManager: <info>  DHCP: device eth0 state changed preinit -> bound
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) scheduled...
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) started...
Aug 14 07:26:44 localhost NetworkManager: <info>    address 192.168.11.2
Aug 14 07:26:44 localhost NetworkManager: <info>    netmask 255.255.255.0
Aug 14 07:26:44 localhost NetworkManager: <info>    gateway 192.168.11.1
Aug 14 07:26:44 localhost NetworkManager: <info>    nameserver '192.168.11.1'
Aug 14 07:26:44 localhost NetworkManager: <info>    domain name 'freiesnetz.www.funkfeuer.at'
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled...
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 4 of 5 (IP Configure Get) complete.
Aug 14 07:26:44 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) started...
Aug 14 07:26:44 localhost avahi-daemon[1955]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.11.2.
Aug 14 07:26:44 localhost avahi-daemon[1955]: New relevant interface eth0.IPv4 for mDNS.
Aug 14 07:26:44 localhost avahi-daemon[1955]: Registering new address record for 192.168.11.2 on eth0.IPv4.
Aug 14 07:26:44 localhost dhclient: bound to 192.168.11.2 -- renewal in 71351 seconds.
Aug 14 07:26:45 localhost NetworkManager: <info>  (eth0): device state change: 7 -> 8
Aug 14 07:26:45 localhost NetworkManager: <info>  Policy set (eth0) as default device for routing and DNS.
Aug 14 07:26:45 localhost NetworkManager: <info>  Activation (eth0) successful, device activated.
Aug 14 07:26:45 localhost NetworkManager: <info>  Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Aug 14 07:26:48 localhost boinc_client: Starting Boinc-Daemon, listening on port 31416.
Aug 14 07:26:51 localhost gconfd (gdm-2139): Beenden
Aug 14 07:26:51 localhost gconfd (mex-2281): starting (version 2.22.0), pid 2281 user 'mex'
...

---

0xFF

[mex@localhost ~]$ time /sbin/ifup eth0
Benutzer können dieses Gerät nicht steuern.

real 0m0.080s
user 0m0.012s
sys 0m0.014s
[mex@localhost ~]$ su
Passwort:
[root@localhost mex]# time /sbin/ifup eth0

IP-Informationen werden für eth0 bestimmt...dhclient(2177) is already running - exiting.

Of course you have to bring the network down first if it is already running. First type "/sbin/ifdown eth0" and then "time /sbin/ifup eth0" -- as root, naturally.

---

Milos Jakubicek