Bug 189197

A small note: I forgot to specify that a restart of the zmd daemon clears these orphaned catalogs.

Assigned to Tambet.

BTW Narayan is your version correct (i.e. "on zmd 7.1.1-57
and 58.."), as of June 28th I believe we were at 7.1.1.0-39.42 so just wondering about the discrepancy and whether it was your own build.
Note that I assume 'rug sd' of the service works as expected.  
Is there any further information when debugging is enabled in /var/log/zmd-messages.log, if so can you please attach it.
Thanks.

I think the version is correct, I was refering to this one: ftp://mirrors.kernel.org/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/zmd-7.1.1.0-58.src.rpm 

I believe it is versioned 58, although I do see a 59 on that server I am going to have to try. Rug does delete the service correctly and I looked at the rug code to see if it was doing something significantly different that caused the correct action (besides using a different interface to zmd), but I didn't see anything. I am not that experienced with c# though, so I might have missed something.

Here are the logs around the delete event:

zmd-messages.log:
"30 Jun 2006 11:08:51 INFO  AuthModule           Got a correct username
30 Jun 2006 11:08:51 INFO  AuthModule           Successful authentication for: http://hawk:2544/zmd/RPC2
30 Jun 2006 11:08:51 DEBUG Progress             Running: /usr/lib/zmd/service-delete '/var/lib/zmd/zmd.db' 'ftp://mirrors.kernel.org/opensuse/distribution/SL-10.1/non-oss-inst-source'
30 Jun 2006 11:08:52 INFO  AuthModule           Got a correct username
30 Jun 2006 11:08:52 INFO  AuthModule           Successful authentication for: http://hawk:2544/zmd/RPC2"

...

"30 Jun 2006 11:10:31 INFO  ServiceManager       Failed to unmount 'ftp://mirrors.kernel.org/opensuse/distribution/SL-10.1/non-oss-inst-source': System.Threading.ThreadAbortException: Thread was being aborted
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Object:__icall_wrapper_mono_thread_interruption_checkpoint ()
in (wrapper managed-to-native) System.Threading.Monitor:Monitor_wait (object,int)
in <0x0003c> System.Threading.Monitor:Wait (System.Object obj)
in <0x00064> Novell.Zenworks.Zmd.Progress:WaitForStop ()
in <0x00114> Novell.Zenworks.Zmd.Packaging.RedCarpetBackend:ServiceDelete (System.String path)
in <0x0004c> Novell.Zenworks.Zmd.Packaging.RedCarpetBackend:OnServiceRemoved (Novell.Zenworks.Zmd.Service service)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_Service (Novell.Zenworks.Zmd.Service)
in <0x00060> Novell.Zenworks.Zmd.ServiceManager:Unmount (Novell.Zenworks.Zmd.Service service)"

zmd-backend.log:
"2006-06-30 11:08:51 <0> hawk(3870) [zypp::SourceManager] SourceManager.cc(sourceTableAdd):109   deleted Sources 0"

If there is any more information you want, I would be pleased to provide it.

This bug is largely fixed in the latest version of ZMD (rev 66). Zypp services no longer orphan catalogs via the xml-rpc interface. However, Yum services appear to orphan their catalogs "sometimes." These orphans don't stick around long, unless you remove all the services. When you do this, the orphan stays around until the next time you add a service. So, this isn't very critical...but is quite strange.

I looked into this a bit for my own personal interest and found that there is an error in the backend log when you remove a yum service:

2006-08-08 08:31:47 <5> raven(18866) [base] Exception.cc(log):94 zmd-backend.cc(findSource):97 CAUGHT:   SourceManager.cc(findSourceByUrl):543: Unknown source URL 'ftp://mirrors.kernel.org/opensuse/distribution/SL-10.1/non-oss-inst-source/suse'

I looked into this a bit farther and came upon a point where it appeared yum services weren't in the "_services" list that is searched in zmd-backend.cc. However, I don't know the codebase very well at all and am probably way off the mark. In any case, this bug isn't very serious or annoying anymore. Thanks guys.

I looked into this a bit farther. The issue appears to be this (and it also happens for the Mount service): when you send a service_remove request via xml-rpc and then turn right around and poll for a list of catalogs and services, things go awry. However, when you send the service_remove and then wait for 1 second, it works fine. I coded this delay into my application and am no longer seeing catalog orphans at all.

The other way to prevent this is to have service_remove return something when it completes. It could be anything, just something to inform client apps that they can safely poll for services again. For example, I attached a small patch I tested with that makes service_remove always return true. My little test app watched for the return and then polled for service data. Again, no catalog orphans. 

I am not sure what is causing all this, but thought the info might be appreciated.

Created attachment 95806 [details]
Test patch -- makes service_remove return true

Thanks for the work you've put into this. I don't really see any problems - you call zmd from multiple threads and zmd answers in multiple threads. You know your call changes available services and catalogs and you're surpised when you see an intermediate state. I also don't see why this patch is necessary. Why return a constant value? You call the method, surely you know when it returns?

I'm closing the bug as WONTFIX as the only way to prevent this behavior would be to allow 1 incoming request at any time, which is definitely worse than this.

Indeed, the patch was just to give you guys all the information (i.e. what I was testing with). I wrote it to make sure that the problem wasn't in my handling of void returns. Thanks for taking a look at this, once I realized what the problem was I figured there wasn't really anything to fix here.