Add autopkgtest to .deb package

25 01 2018

These are the example steps for add a very simple autopkgtest test to an existing Debian package:

  • Add to debian/control the following line:
Testsuite: autopkgtest
  • Create the folder debian/tests
  • Add the control file under debian/tests/control with the following content:
Tests: smoke
Depends: @
  • Create a simple script using the name of the test debian/tests/smoke:
  • Create the package as usual (maybe with dpkg-buildpackage -us -uc) and run the test:
autopkgtest --output-dir /tmp/output-dir1 -B my_program*.changes -- null

Note: Usefull examples in
More info:


Check SLA uptime in a linux server

13 01 2018

When a new server is up, usually from a remote provider, their reliability is covered under a Service License Agreement. In that document is reflected the garanteed uptime of the machine, a percentage value close to 100% which assure the time that the server have to be up.

There can be other clauses with the network uptime, storage uptime, what ever other service we had uptime that will aso have to be taken into account to the global uptime of our service. But now we are only going to focus exclusively on the operating system uptime. To know what is the value from our side, these are the steps:

When you have the access to the new server, as soon as posible, install the Tuptime package:

# apt-get install tuptime

Increase the sync interval. By default it save the time on disc each 5 minutes, which is ok for a normal user, but to have it as detailed proof of service, it can be done each minute. Change in “/etc/cron.d/tuptime” from:

*/5 * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi


* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi

Or more agressive, assure the sync operation to disc too:

* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x && sync > /dev/null; fi

Now it’s done, wait a few days or weeks and check how are things going.

Check the uptime for the last month. As one month (30 days) are 2592000 seconds, get the last n seconds from date:

# tuptime --tsince -2592000
System startups: 3 since 15:17:42 14/12/17
System shutdowns: 1 ok - 1 bad
System uptime: 97.3 % - 29 days, 4 hours, 35 minutes and 7 seconds
System downtime: 2.7 % - 19 hours, 24 minutes and 53 seconds
System life: 30 days, 0 hours, 0 minutes and 0 seconds

Check the uptime for the last year. As a year have 31536000 seconds:

# tuptime --tsince -31536000
System startups: 6 since 15:20:03 13/01/17
System shutdowns: 1 ok - 4 bad
System uptime: 94.39 % - 344 days, 12 hours, 33 minutes and 46 seconds
System downtime: 5.61 % - 20 days, 11 hours, 26 minutes and 14 seconds
System life: 1 year, 0 days, 0 hours, 0 minutes and 0 seconds>

The output give us a clear report of the uptime percentage. Even, it is possible to see the exact date and time if the “-t” table or “-l” option are passed to the command.

This is a good option to check the garanteed value without using any graph or pannel provided by the server provider. We have a strong view of how good or bad are service, any strange restart, even those that happen at intimely hours, will be registered and counted in the tuptime report.

If is required in the report an uptime / downtime percentage larger than two decimals, which is the default, use “–decp” option with the desired lenght.

More info:

Python script who generates threads

5 01 2018

#!/usr/bin/env python3
import time
from threading import Thread
num_threads = 100
sleep_secs= 60
def create_thread(i):
print "Sleeping "+ str(sleep_secs) +" secs - Thread %d \n" % i
for i in range(num_threads):
t = Thread(target=create_thread, args=(i,))
print "End"

View threads in top pressing “H”
View threads in ps with “-T”

Fix random hangs in Debian 9 with Nouveau Nvidia graphic module

7 12 2017

With and old Nvidia graphic card, like GeForce 6150SE nForce 430, and a new Debian with the latest Nouveau module, it is common to get hangs of the kernel produced by a bad beaviour of the graphic driver.

To mitigate it, add to the file “/etc/default/grub” the following content:


Increase filesystem without lvm in VMWare

4 12 2017

This method allow to increase a filesystem without using lvm, a simple virtual disk assigned to a virtual machine. It works if it is the root partition too. It doesn’t require reboot.

Note: Only works if the filesystem partition to grow is the last partition of the disk:

0.- Make a clone of the virtual machine for backup.

1.- Resize virtual disk in VMWare.

2.- Inside the vm, check the scsi connected devices:
# ls /sys/class/scsi_device/
0:0:0:0 2:0:0:0

3.- Force a reescan:
# echo 1 > /sys/class/scsi_device/2\:0\:0\:0/device/rescan
# echo 1 > /sys/class/scsi_device/0\:0\:0\:0/device/rescan

4.- Move the GTP backup partition table to the real end of the resized disk:
# gdisk /dev/sda
Command (? for help):
Command (? for help):
Relocating backup data structures to the end of the disk
Expert command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
Do you want to proceed? (Y/N):

5.- Notify the partition change:
# partprobe

6.- Delete the target partition and recreate it using the new extra espace. This is only to define the new end of the partition:
# gdisk /dev/sda
Command (? for help):
Partition number (1-3):
Command (? for help):
Partition number (3-128, default 3):
First sector (34-73400286, default = 2222080) or {+-}size{KMGTP}:
Last sector (2222080-73400286, default = 73400286) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
Do you want to proceed? (Y/N):

7.- Notify the partition change:
# partprobe

8.- Finally, grow the filesystem:
# resize2fs /dev/sda3

Basic go setup in Debian

30 11 2017

Install go package:
# apt-get install golang

Create dir for go workspace, so it can install packages and related stuff. Usually it goes in the home dir, but it would be ok elsewhere.
# mkdir ~/go

Set up the env variables. The GOROOT variable points to the location the Go tools are installed – if you didn’t install them to a custom location, you don’t have to set this manually:
# export GOPATH=$HOME/go
# export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
# source ~/.bashrc

Finally, install whatever you want. It would make the bin inside ~/go:
# go get

Systemd unit for Monyog

15 11 2017

Systemd unit for Monyog. Create a new file in “/etc/systemd/system/monyog.service” with the following content:

Description=Webyog MONyog Service