Aptly API serve is locking DB and not allowing me to also use local aptly commands

[Zane]

Hi All,

I have started up

ps aux | grep aptly
root 63912 0.0 0.0 111040 5484 ? Ssl 21:00 0:00 /usr/bin/aptly api serve -listen=:8080

Via an upstart:

description "Stat HTTP server with aptly REST API"
start on filesystem or runlevel [2345]
stop on runlevel [!2345]

respawn
umask 022
chdir /
setuid root
setgid root
console log # log stdout/stderr to /var/log/upstart/


exec /usr/bin/aptly api serve -listen=:8080


What I am seeing is that the aptly api serve starts up and runs fine. I can also run local aptly commands fine, without error.

But after a few hours I run some local aptly commands and I start getting back:

Example commands:
~# aptly repo list
ERROR: can't open database: resource temporarily unavailable

or

~# aptly snapshot list
ERROR: can't open database: resource temporarily unavailable


How should I go about debugging this?

-Zane

[zwill...@machinezone.com]

I performed:

aptly db cleanup

Let's see if that helped out.

[zwill...@machinezone.com]

Ok, that didn't seem to help.

I am now back into the state where commands return that the DB is locked.

aptly repo list
ERROR: can't open database: resource temporarily unavailable

I am running aptly-0.9.1 on Ubuntu 12.04 LTS

[Andrey Smirnov]

Hi Zane!

aptly api serve would lock database while it's running, it would actually open DB on the first API call. (The same applies to all aptly commands). So it's not possible to use API service and CLI commands at the same time.

--
You received this message because you are subscribed to the Google Groups "aptly-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aptly-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zane Williamson]

Thank you for the update! Makes sense to me.

Ok, I just started working on a Ruby aptly-cli gem (Not usable just yet, writing tests first).  Ill move over to using that against the API locally then.

https://github.com/sepulworld/aptly_cli

-Zane

[Zane]

> To unsubscribe from this group and stop receiving emails from it, send an email to aptly-discus...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

I am curious.

It might be useful (once API commands match up completely with aptly commands) to have a configuration option in aptly.conf to allow aptly commands to use the API if the aptly api service is running.

What do you think? Or is it best to always keep them separate?

[Andrey Smirnov]

I was thinking about that - to reimplement CLI commands as API calls, but I don't have enough time for that just now...

> To unsubscribe from this group and stop receiving emails from it, send an email to aptly-discuss+unsubscribe@googlegroups.com.

[mar...@nilsson.tv]

How hard would it be to close the db after each served request?

[Andrey Smirnov]

It's not a big deal, but opening database (and retrying if it fails due to locking) could be tricky.

cmd/mirror_update.go does almost the same while downloading package files.

and cacheFlusher in api/api.go could be used as good place to close database.  Probably it won't work, as you need to be sure that there are no requests in progress.

On Thu, Mar 26, 2015 at 8:09 PM <mar...@nilsson.tv> wrote:

How hard would it be to close the db after each served request?