Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 19283 - /etc/init.d/net.eth0 doesn't start sshd and cupsd
Summary: /etc/init.d/net.eth0 doesn't start sshd and cupsd
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-14 03:55 UTC by Martin Mokrejš
Modified: 2003-04-24 15:07 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2003-04-14 03:55:00 UTC
root # /etc/init.d/net.eth0 stop
 * Stopping cupsd...                                                      [ ok ]
 * Unmounting network filesystems...                                      [ ok ]
 * Stopping sshd...                                                       [ ok ]
 * Bringing eth0 down...                                                  [ ok ]
root # /etc/init.d/net.eth0 start
 * Bringing eth0 up...                                                    [ ok ]
 *   Setting default gateway...                                           [ ok ]
root # 

I think the "start" option should start up again sshd, cupsd, it's a question if
it should do "mount -a" or even better during the "stop" procedure write down
/etc/mtab and mount all such filesystems again during the "start" procedure,
unless the system hasn't been rebooted since the "stop" cycle.

Actually, I don't care about the mount step, but starting sshd and cupsd sucks.
;) Thanks!

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2003-04-14 04:37:12 UTC
I should think you could just reinit your runlevel and that would sort you out.
Comment 2 Stefan Förster 2003-04-14 06:41:34 UTC
For this to achieve, you would need a mechanism to keep track of services running before a peticular service is stopped (and dependent services are, too).

Now tell me, how would you like an /etc/init.d/net.foo start to behave? Just start you ethernet service? Start all services which are dependent on that service? The problem is, the system cannot _know_ if you want to restart dependent services - and it shouldn't try to guess that.

If you want a complete reinitialization of a runlevel, use telinit.

This is not a bug in baselayout, IMHO.
Comment 3 Martin Mokrejš 2003-04-14 07:15:51 UTC
I know that would need magic. Actually, the only thing I expect from net.eth0 stop is that the interface is downed. I don't know why sshd/cupsd should be shut down too. If they won't be shut down, I won't complain. ;)
Comment 4 Stefan Förster 2003-04-14 07:25:28 UTC
Well, samba is a service which usually needs the network up and running, so IMHO it is the correct behaviour to shut down all services which need net when bringing one interface down - yes, "only" one, the vast majority of boxes will only have one ethernet interface, so it is fully sufficient that networking with a single interface works out of the box. If you need to further customize this, it is no problem to change the provide statments in your net.foo scripts and the depends in you service startup scripts.
Comment 5 Martin Mokrejš 2003-04-14 10:26:46 UTC
I don't need to customize anything. All daemons should/will survive with network card downed. Maybe they will log some extra messages, but in principle then should stay.

The script is simply named net.eth0 so it should just down eth0 and nothing else. There may be scripts for shutting down whatever services, as is commonly used. For example, Debian /etc/init.d/networking just warns that it has NOT deconfigured samba. It really doesn't do anything else then ifup/ifdown.

I think those extra operation should be moved out of the net.eth0 script.
I can't imagine that

net.eth0 stop
net.eth0 start

does NOT bring me to the same stage. I find it unexpected behaviour.
Comment 6 Stefan Förster 2003-04-14 12:43:31 UTC
Why unexcpected? Imagine a service is bound to the IP of an interface. You bring the interface down and bring it up again with a new IP address. Your service will continue to run, but not reachable from the outside. This is what I would call "unexcpected", YMMV.

Remember, the bind(2) call works with local addresses, not specific interface names. _Not_ stopping the services might really cause "unexcpected" results.
Comment 7 Martin Mokrejš 2003-04-14 13:17:42 UTC
I agree that such services might have problems. But I think it makes sense to move that part out of the net.eth0 script. If I manually shut down the interface, then I possibly know what I'm doing. If not, my problem.

If I manually startup the interface, I expect the process restores previous status when it has shut down also some services.

I think we won't come to a common word here :( ... I don't have an access to RedHat or any other linux box, but maybe you would like to check what other Linux distributions do at least. I'm not an expert, so I'll accept you decision then.

BTW: Has the gateway/static route be reconfigured?
Comment 8 Martin Schlemmer (RETIRED) gentoo-dev 2003-04-14 14:32:34 UTC
It is a feature, not a bug.  Stefan have covered most of this.

Here is an example of how to get past some of the issues you have without
editing:

1)  Stop net.eth0 without dependencies:

  # /etc/init.d/net.eth0 pause

2)  Say you did run:

  # /etc/init.d/net.eth0 stop

and now you want to start them all again:

  # rc
Comment 9 Martin Mokrejš 2003-04-24 07:52:25 UTC
Well, actually I really have to change IP address of an interface as well as gateway. But, the solution in comment #8 is exactly what I wanted. I'm just curious, why I do not see the pause option in /etc/init.d/net.eth0. Also, could that be listed in the /etc/init.d/net.eth0 file somewhere in the front, that after editing one can use the "net.eth0 pause" with "rc" trick? Thanks.
Comment 10 Martin Schlemmer (RETIRED) gentoo-dev 2003-04-24 15:07:18 UTC
Just run any initscript without arguments .... its a build-in command ...