Bug 89956 - cups + samba + vmware causing endless loop in init scripts
|
Bug#:
89956
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: printing@gentoo.org
|
Reported By: Steve@genyinfo.com
|
|
Component: Printing
|
|
|
URL:
|
|
Summary: cups + samba + vmware causing endless loop in init scripts
|
|
Keywords: Bug
|
|
Status Whiteboard:
|
|
Opened: 2005-04-21 12:13 0000
|
this bugs is some kind of replicate of bug #15492
We need to restart samba deamon to have printer sharing activated.
Reproducible: Always
Steps to Reproduce:
1. Have CUPS and samba for restart with default config from example
2. add samba and cups to default runlevels
3. reboot
4. try access printer after reboot.
Actual Results:
the printer are not listed
Expected Results:
The printer should work normaly
if we look at the service startup, cups is started right after samba so samba
dont load the printer on startup.
added use samba to cupsd init file
Ok, but now samba also still 'use cups', and you get:
----
* Caching service dependencies ...
* Services 'samba' and 'cupsd' have circular
* dependency of type 'iuse'; continuing...
samba herd: please remove use cups from samba-init
Doesn't this make samba start BEFORE cups?
maybe it's just me, but cups should be running first, so samba can ask it for it's printers, or am i wrong?
sorry, you are completly right, reverted the changes
this bug has to be in baselayout then
ahh, thought so, didn't make much sense :)
initial reporter: does your problem persist?
Yes the bugs still happen.
I've played around the use flags to try solve the problem but with no success.
But then, i could try to get it work if i know where to look. Do you have some advice, or some place i should look for.
try to change "use cups" to "after cups" in the samba init file
I've tryed with 2 alternative for it.
before cups
and
before cupsd
nothing has change with these modification. But i've notice that Vmware sevice load bettween those 2 maybe this bug comming from a dependency in the vmware 4.5 suite ? I'll investigate on this case later.
forget to tell i've also tryed the after cups and after cupsd thing :p
I've checked up the init script of cups and in the depends functions there is a
use vmware. Why does cups need to use vmware, it should be vmware that use
cups.
I'll change the init script to add the depends in vmware and remove it from
cups.
I'll give more detail twomorrow morning if it has worked.
Ok now everything is working just fine.
Please remove the dependency to vmware in cups and add it to vmware.
I'll leave the bug open for you all to see it and it solution.
no, cups needs to be started before vmware, take a look at bug #23971. what if
you change use vmware to after vmware?
Well cups was started after vmware before.
When i've change the dependency of cups to vmware and vmware to cups everything worked fine and cups was started way before samba or vmware had the chance to start ( Cups even started before dbus and HAL ).
I've checked the bugs #23971 about cups not starting because of vmnet not being there. I can say i dont have this problem with my installation of vmware.
I'll investigate about this problem and bugs and post my solution.
Ok now the main problem is we have a big cyclique dependency problem that
affect
samba print with cups. And Vmware is causing all these problem.
So if i explain myself we have samba, vmware and cupsd starting in that order.
The reason why is that vmware need samba to startup the samba share into
vmware.
Cupsd need to be started after vmware because cups may be binded to a vmware
network interface. And to finish we need cupsd started before samba to have it
printer readed by the samba daemon.
The only solution i can think of is reloading samba right after cupsd is
started
if and only if samba is already started.
Just learned about this problem the hard way. Couldn't print from
windows host, which I could yesterday (boot in between).
I added
/etc/init.d/samba restart
to /etc/conf.d/local.start
And since the local initscript is executed last ;-)
But solving this in the initscripts themselves would be appreciated!
what i have done is remove the cups depedencies to vmware since my cups
configuration is not bind to vmware virtual network interface. Then everything
work fine. In the ideal world would be that cups retry to bind itself to the
interface servral time after being started and give an error after a maximum of
retry and have a bind to minimaly 127.0.0.1, not completly fails on startup and
brings down the deamon that depends on it.
The reason for this bug is the additional "after vmware" in /etc/init.d/cupsd.
Vmware has "use samba", samba has "use cupsd" and cupsd has "after vmware", this
way it is a round dependency. Removing "after vmware" from /etc/init.d/cupsd
should solve the problem. And this is the logical way, because cupsd should be
started first, needed by samba, and samba is needed by vmware to share files and
printers with the host.
this bug cannot be fixed, because then #23971 would neeed to be reopened. If
you can think of a solution, that takes both issues into account please tell me
and reopen.
*** Bug 118270 has been marked as a duplicate of this bug. ***
*** Bug 119065 has been marked as a duplicate of this bug. ***
Well, causing lock up in init scripts and breaking boot process for users is
the worst of available options, this is not acceptable, really.
I'm amazed that no-one has thought of the obvious solution to the circular
dependency which is to split vmware networking off into a separate init script
(vmnet fex) or create it as a baselayout netscripts module.
*** Bug 119516 has been marked as a duplicate of this bug. ***
Argh! I have been having this problem (boot hanging) and finally found out it
is something with cups/vmware/samba and finally found this bug.
*** Bug 120256 has been marked as a duplicate of this bug. ***
*** Bug 127570 has been marked as a duplicate of this bug. ***
This is still a problem. With parallel startup enabled, my system will hang
because samba uses cups, which wants to start after vmware, which wants to
start after samba.
I fix this by commenting out the "after samba" in the vmware script. This
really seems to be the most logical thing to do to me. In fact, some users may
want samba to start *after* vmware, for the same reason as cups; to allow samba
to bind only to the vmware interfaces.
Is there some use case for the vmware _services_ needing samba to be running?
I can see the need when I actually startup a virtual machine, but I don't see
any value in requiring samba to be running for the vmware services.
*** Bug 150556 has been marked as a duplicate of this bug. ***
is it possible to split vmware: vmware-net that should be start before cups,
and vmware-services that use samba?
Ehh... sure.
Feel free to attach a patch to do it and I'll commit it. Otherwise, it'll have
to wait until I drum up some time to look into it more closely. The init
script-fu for VMware kinda scares me. The biggest problem is that we're
actually using VMware's init script with just a wrapper, instead of our own
script.
I've been planning on completely rewriting VMware's script as a Gentoo init
script, but that's still a ways off. If someone wanted to do it for me and
submit it to this bug, I'd be much appreciative.
I have 2 patches, for /etc/vmware/init.d/vmware, but the original have VMWare
Copyright. Your rewrite is welcome.
I dont use samba on vmware. For me it is a cosmetical bug.
sorry for broken english.
Created an attachment (id=99347) [details]
Patches for splitting vmware
Here is my full patchset for splitting by duplicate & remove-unneeded.
services contains only dhcpd and samba
litle more tested with vmware-player-1.0.1.19317-r4
#Installing-instructions:
/etc/init.d/vmware stop
cp /etc/init.d/vmware /etc/init.d/vmware.bak
cp /etc/init.d/vmware /etc/init.d/vmware-services
cp /etc/vmware/init.d/vmware /etc/vmware/init.d/vmware-base
cp /etc/vmware/init.d/vmware /etc/vmware/init.d/vmware-services
patch /etc/init.d/vmware init.d/vmware.diff
patch /etc/init.d/vmware-services init.d/vmware-services.diff
patch /etc/vmware/init.d/vmware-base mod/vmware-base.diff
patch /etc/vmware/init.d/vmware-services mod/vmware-services.diff
/etc/init.d/vmware-services start
*** Bug 156047 has been marked as a duplicate of this bug. ***
Guys, I hate to ask this so far down the line, but does vmware really require
samba? As far as I was aware, vmware starts it's *own* samba server to support
the "shared folders" feature, which may not even be required, and otherwise I'm
not aware of any reason why the system samba needs to be started before vmware,
or why there is any dependency between them at all.
Could someone who has samba installed and uses vmware's shared folders feature
please verify whether vmware actually needs the system samba service to be
started to still function properly?
The problem is not that vmware need samba to work but mostly samba need vmware
Network interface for some case on user config placing restriction on the
specific IP address. Sames goes with cups and other deamon that the user put a
specific configuration on an IP address provided by VMWare modules.
The provided solution is ideal cause it can overcome any kind of user config
that we could came across.
Regarding the the previous duplicate comment bugs, maybe juste the vmware init
script is not updated ?
(In reply to comment #40)
> Guys, I hate to ask this so far down the line, but does vmware really require
> samba?
That was my question in #31. I'm still not aware of any case where samba
and/or cups need to be running before the vmware services start. I certainly
need them to start before my actual virtual machine(s) startup, but that
happens later.
> Could someone who has samba installed and uses vmware's shared folders feature
> please verify whether vmware actually needs the system samba service to be
> started to still function properly?
No, samba does not need to be running for shared folders to work.
Ok, the last comment was on 2006. I just emerged vmware-player and added
vmware to default. And this is still happening. The loop is still there in
the init scripts.
any definitive solution? What I did was that I substituded after samba to
after local. That gave a circular because local is supposed to start after *,
but the machine started (grin).
Ok, I know that was an ugly fix, but at least it works. Any approved fixes?
thanks
It seems that I had to learn about this issue the hard way, too. Any progress?
removed after vmware from cups init scripts for now. Feel free to continue with
the splitup in vmware and readdit then.