[Systems] Wiki spam

[Samuel Cantero]

On Mon, Dec 7, 2015 at 2:52 PM, Samuel Cantero <scanterog at gmail.com> wrote:

> On Mon, Dec 7, 2015 at 1:27 PM, Bernie Innocenti <bernie at codewiz.org>
> wrote:
>
>> On 12/07/2015 11:13 AM, Samuel Cantero wrote:
>> >     I tried reproducing the problem in the Sandbox page, but editing
>> does
>> >     not work at all because the docker container with the node.js app
>> needed
>> >     by Parsoid is not running. Odd, the other containers are all up.
>> >
>> > Parsoid container is not running. I tried to start it, but Docker
>> > complains that is not enough disk space to build this container. Its
>> > partition has 1.3 GB available, so we should remove old and unused
>> > images. I have a meeting now and I'm leaving now, but I will fix it as
>> > soon as posible. Sorry.
>>
>
> There is something strange with our docker partition inodes.
>
> Filesystem                                      Inodes    IUsed    IFree
> IUse% Mounted on
> /dev/mapper/freedom--lvm-docker_extra_storage        0        0        0
>   - /var/lib/docker
>
> Anyone with experience about this? I was expecting an inode exhaustion. I
> will try to find out what is going on here.
>

Indeed the docker partition was full. DF is not expected to give accurate
results for btrfs. So, to get the total use I had to execute: btrfs
filesystem df /var/lib/docker. The true disk usage is the sum of all 'used'
values.


>> Also, I found three parsoid images:
>>
>> org.sugarlabs.wiki_parsoid  latest  0cf030b154df  4 months ago 298.1 MB
>> wiki.sugarlabs.org-parsoid  latest  0cf030b154df  4 months ago 298.1 MB
>> parsoid                     latest  0cf030b154df  4 months ago 298.1 MB
>>
>> SamP, could you please delete the unused images and update the
>> documentation to match reality?
>>
>>  https://wiki.sugarlabs.org/go/Service/wiki#Visual_Editor
>>
>> You can't delete images when the partition is full. Apparently, docker
creates a tmp folder inside its partition when executing remove, so it
wasn't possible. I had to remove it manually. Also, it is not possible to
use rm. You must use btrfs subvolume.

Sometimes Docker doesn't allow you to remove containers with snapshots. So,
I've written this little script to remove all the snapshots related to a
container ID.

sudo btrfs subvol list -ao /var/lib/docker | grep DOCKER_CONTAINER_ID | awk
'{ print $9 }' | sort -r | while read vol; do echo "sudo btrfs subvolume
delete $vol"; done | bash -x

After removing all the snapshots and the container disks, you can execute
docker rm -v container. It is important to delete a container using the -v
parameter. By default, docker doesn't remove the volumes associated with a
container. By executing rm with -v, all the volumes associated with the
container are also removed. If we don't do this, we are leaving a lot of
orphan disks and snapshots.

I removed some containers to put back online the parsoid container, but I
couldn't start it. I built and started it again but no success. There is an
error in the log associated with a node.js module. Sam have you done some
update? In case you didn't, I guess that the parsoid git repo (inside the
dockerfile) probably has been changed.


>
>> >     Adding Sam to the thread since he's been improving the wiki lately
>> so he
>> >     probably knows how to fix this.
>> >
>> >     For my own information, where is the list of images that should be
>> >     autostarted when the docker daemon starts?
>> >
>> > Using the sam's script container.yml every container is configured with
>> > autostart. Anyway, it would be good to write some doc about our docker
>> > infra in our wiki.
>>
>> Indeed, I'm never sure what to do when a container is down, or even
>> which containers should be running.
>>
>> It's also my fault for living under a (Google) rock for the past 4 years
>> while all the cool kids are using Docker :-)
>>
>> --
>>  _ // Bernie Innocenti
>>  \X/  http://codewiz.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/systems/attachments/20151208/a4efcbac/attachment.html>