Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am getting an error "FeedsLockException: Cannot acquire lock for source" when importing feeds from an XML-feed. I cannot figure out what the warning is about, and thus how to solve it.
Any suggestions?
Svend
Comment | File | Size | Author |
---|---|---|---|
#42 | 1535368-42.patch | 4.5 KB | lathan |
#38 | 1535368.patch | 4.39 KB | Pol |
#33 | feeds-unlock-1535368-33.patch | 4.28 KB | kamkejj |
| |||
#18 | feeds-unlock-1535368-18.patch | 4.27 KB | twistor |
Comments
Comment #1
hassan2 CreditAttribution: hassan2 commentedI am having the same issue when trying to import small number of feed items. But if i try to import it again it will import the second time. May be it is something to do with cache somewhere.
Comment #2
hassan2 CreditAttribution: hassan2 commentedI have done some further research and found this error in my Apache error log -> Unsupported operand types in /home/public_html/sites/all/modules/feeds/includes/FeedsConfigurable.inc on line 149. Now, page 149
has this statement>
/**
* Implements getConfig().
*
* Return configuration array, ensure that all default values are present.
*/
147 public function getConfig() {
148 $defaults = $this->configDefaults();
149 return $this->config + $defaults;
}
Any idea?
Comment #3
hassan2 CreditAttribution: hassan2 commentedRunning cron every minute solved my problem. I don,t know if that is sustainable in the long run but it is working for now. Therefore, i think it is something to do with timing.
Comment #4
hassan2 CreditAttribution: hassan2 commentedAlso if you enabled the internal cron job disable it and use external cron.
Comment #5
mamanerd CreditAttribution: mamanerd commentedThis happened to me a few times and I fixed it by deleting the semaphore row associated with the importer.
Comment #6
camilohollanda CreditAttribution: camilohollanda commentedPatch worked for me!
Comment #7
AlfTheCat CreditAttribution: AlfTheCat commentedNumber 5 seems to help, I can now at least start import jobs that would refuse to work because of the "cannot acquire lock" error.
However, when these jobs run they fail quickly and I have to manually unlock and restart them over and over. Again throwing the "cannot acquire lock" message.
Comment #8
AlfTheCat CreditAttribution: AlfTheCat commentedScratch my comment in #7, it turned out that was a server issue on my end.
Patch #5 worked like a charm.
Comment #9
twistor CreditAttribution: twistor commentedThis is not a bad idea, but we should just load the source and call FeedsSource::releaseLock().
Comment #10
michiellucas CreditAttribution: michiellucas commentedAlfTheCat, what server issue did you have because i can't reproduce it on my local machine and it is happening on development server.
Comment #11
AlfTheCat CreditAttribution: AlfTheCat commented@michiellucas,
It could be a hardware issue. Is there a big difference in specs between your dev and production site? Or perhaps php.ini resource variables?
Comment #12
pal4life CreditAttribution: pal4life commentedHello,
I am still seeing this issue even after applying the patch. I am also noticing a pattern that it does 3 or 4 row imports before giving this error.
Attaching snapshot here
http://i.imgur.com/NAVnLkj.png
Any other clues or places I should look at? Also there is nothing added to the site log. I have disabled the site cron as well.
Anything we can do at the database level as well?
Thanks.
Comment #13
pal4life CreditAttribution: pal4life commentedHi,
Attaching the file here supporting the comment I made above in #12
Comment #14
twistor CreditAttribution: twistor commentedComment #15
twistor CreditAttribution: twistor commentedComment #16
twistor CreditAttribution: twistor commentedComment #17
twistor CreditAttribution: twistor commentedComment #18
twistor CreditAttribution: twistor commentedOpps, ignore previous patch.
Comment #19
bwood CreditAttribution: bwood as a volunteer commentedWith #18 applied, I can still produce the error.
My situation might be unique. The error occurs sporadically when loading a page that calls this code:
When the error occurs I immediately query semaphore and the table is empty.
Comment #20
bwood CreditAttribution: bwood as a volunteer commentedI think I fixed my problem by using $source->startImport() and not bypassing the batch api with that while loop. import() invokes releaseLock().
Comment #21
markabur CreditAttribution: markabur commentedPatch worked for me, though there are two places where "Ulock" needs to be "Unlock"
Comment #22
MegaChriz CreditAttribution: MegaChriz as a volunteer commentedClosed #2417433: background process - import finishes and starts again - Cannot acquire lock error and #2659194: "Cannot acquire lock for source" when starting XML feed import as duplicates.
Comment #23
fujishooter CreditAttribution: fujishooter commentedMy small web team just lost it's Drupal developer, so I'm on my own trying to work with this issue. I have a lot of front-end Drupal work and have built a number of sites, but I'm not a coder. From reading this page, some form of this problem goes back four years. Is there an update planned for the Feeds module to correct this or is this something taking a back seat to Drupal 8 development? Hacking the code is not something I have the expertise to do.
Thanks.
Comment #24
MegaChriz CreditAttribution: MegaChriz as a volunteer commented@fujishooter
This issue is not on my list of fixing this for D7. You could try the patch from #18 and report back if that fixes the problem for you. According to #21 the patch would only need spelling corrections.
An automated test that would demonstrate the issue would help with getting this in.
Comment #25
kamkejj CreditAttribution: kamkejj as a volunteer commentedFixed the spelling from #18 and uploading corrected patch.
Comment #27
kamkejj CreditAttribution: kamkejj as a volunteer commentedTrying the patch again after failing from #25.
Comment #28
kamkejj CreditAttribution: kamkejj as a volunteer commentedSetting to Needs review
Comment #30
kamkejj CreditAttribution: kamkejj as a volunteer commentedRe-created the patch with PHPStorm from #18 with the spelling corrected as indicated in #21.
Comment #31
kamkejj CreditAttribution: kamkejj as a volunteer commentedTrying patch testing again.
Comment #33
kamkejj CreditAttribution: kamkejj as a volunteer commentedRe-created the patch from #18 with the spelling corrected as indicated in #21.
Comment #34
kamkejj CreditAttribution: kamkejj as a volunteer commentedSwitching to needs review.
Comment #35
WidgetsBurritos CreditAttribution: WidgetsBurritos commentedPatch #33 works for me.
Comment #36
chegor CreditAttribution: chegor as a volunteer commentedCan we commit this?
Comment #37
MegaChriz CreditAttribution: MegaChriz at WebCoo commented@chegor
If you (or someone else) can provide the steps to reproduce this issue or - even better - write an automated test that demonstrates the issue, I will give this issue more priority.
Comment #38
PolHi,
This patch is also working for us.
I've updated the patch to get it working with the latest dev version.
Thanks.
Comment #39
WillGFP CreditAttribution: WillGFP commentedI ran into this problem recently after updating cURL and Feeds, and it seems like there's different issues here that people are running into. The patch fixes the problem with using Unlock in the Feeds UI, but it doesn't fix what's causing the lock in the first place.
I assume it's a variety of different issues causing locks,
but for me the fix seems to be disabling cURL altogether in the feeds_http_request function within the includes/http_request.inc file.I should also mention it only seem to happen for certain domains, most work fine.
Update: Seems to be an issue with Apache and cURL and not an issue with Drupal.
Comment #40
TokiI am having the same issue (cannot acquire lock for source) but with a feed importer and SQL parser (using Feeds SQL). It seems like the code is looking for the table semaphore in my external database and not inside the drupal database. Now my automatic import is broken and even manually I can't get my data. Any idea here? Should I open a new issue? Thanks in advance.
Error Message (partially) after launching manually the import : An AJAX HTTP Error occurred. [...] Base table or view not found: 1146 Table 'my_external_database.semaphore' doesn't exist in ...
Comment #41
TokiIt was an error in a Rule fired during the Feeds import. The import stopped but the active database was always the external one. I guess this explains why the module tried to access a Drupal table in my external database. As soon as I modified the Rule, the import worked well until the end and I got no more semaphore error message.
Comment #42
lathanrerolled patch
Comment #44
MegaChriz CreditAttribution: MegaChriz at WebCoo commentedI'm still wondering what the patches in this issue are trying to solve. It's clear that it's about a locked feed, possibly caused by a crashed import. I don't understand however why the existing unlock functionality isn't working. Has it something to do with the semaphore table? Can someone show what's in their semaphore table when this issue occurs?
I don't understand why the import/clear progress need to be checked for the complete status. Can somebody explain?
This repeats a lot of complexer looking code. I think it's better to have an
isLocked()
method in the FeedsSource class with this code.This line is too long. Insert a new line after "array(" and format like elsewhere in the code where a new line is followed after "array(".
Please follow the same formatting as elsewhere in the code: only a new line after "array(" and the two closing brackets also on anew line.
Comment #45
Freddy RodriguezI dont know if this can help: This problem happen to me in a multisite installation, same codebase and different databases.
The import exists in each site, is called in the same way and possibly have the same ID. If I fire the import in the site A, and try to fire the same in the site B, the problem appears. I cant execute the same feed in the other sites mean while one of the sites is doing the process. After have been finished, the lock gets undone.
This is the validation:
In this case, there is a way of instanciate the feeds_source_@id dependant to site variables?
Comment #46
MegaChriz CreditAttribution: MegaChriz as a volunteer and at WebCoo commented@Freddy Rodriguez
Do you have shared tables between these two sites? Because the information about whether or not a feed is locked is stored in the database table ‘semaphore’.
See lock_acquire().