Nem só de morte vive o kill.
Suponha que você tem um processo chamado program e quer congelar seu funcionamento. Para congela-lo sem mata-lo você pode mandar um sinal SIGSTOP com:
kill -s stop `pidof program`
Para ressuscitar o mesmo processo:
kill -s cont `pidof program`
I thought about these two problems my entire life.
Graphical arts have a significant role in everything I do. I always expressed my feelings thorough graphical drawings. First on paper, so notebooks, then walls and others surfaces like the computer screen. But the possibility of transform my body, my own skin in a art canvas always fascinated me. This was a natural step.
But the tattoo is an art that raises a tricky philosophical question, it’s something that you can not undo it. Once you did it, it’s done. You can change or add the meaning with others tattoos but you can not remove meaning of a draw in a negative way by erasing it like other forms of arts. Of course there’s some kinds of treatments with different approaches and variant results but I see no point on think about tattoos looking on how remove them. It seems obvious that doesn’t matter how cool and incredible something could appear or how sure I am about it, I could always change my mind and repent. This puzzle was around my mind for a long time until finally I saw way out.
The key is that the life you live itself is also a tattoo. You say words that cannot be unsaid. You see things that you can not unseen.You feel such strong emotions that you can not heal your scars. Every moment it’s also a tattoo in the thin skin of the time and there’s nothing you can do about that because the time flows only in one direction. Of course you don’t paint all your life with ink in your own skin but at least, you can choose some parts of it to express as a beautiful tattoo.
The second problem is witch draw do. There are hundred of drawings that I love and besides I also enjoy old school tattoo drawings, I choose a piece of programming code. More specifically the Jaromil most elegant forkbomb code ever written:
This small piece of code fork itself twice in parallel creating more processes that will be forked again and again until stop the entire system. You can read a more detailed explanation on its operation, history and variations on Wikipedia’s Fork bomb article.
It has several meanings to me, from the aesthetics from the computer science field to the shape and possibilities the draw allow. The exponential grow of the number of forked process it’s also another beautiful aspect of this code. From the viewer perspective, even a casual one, it has a beautiful as a puzzle to be decipher or a totem pole of different emoticons.
Blood and ink.
I tried for months several different fonts and styles to use on it, from mono space to stylized draws. In the end I choose the Bitstream Vera Sans by Jim Lyles. A free (as in freedom) font very common on GNU/Linux systems. I also did small change in the draw by reducing almost entirely the spacing between the braces. This made it look better when looking it by side creating a stronger emoticon illusion.
Blood stain in the paper towel after dry the finished tattoo.
The process almost doesn’t involve pain and hurt, in contrast with what I thought. It’s like a little cat scratch in your arm for almost 2 hours of painting. I did in the Freedom of Tattoo studio, from the well-known here tattoo artist Dereka, with Thiago, a very skilled artist.
My thanks to the studio, to Dereka, to Thiago and to my friend Silvio who took the pictures and accompanied me. There’s a photo album with all tattoo photos. I’m very happy with the final work.
I created some illustrative and simple implementations of common Unix commands. For those who are familiar with Unix-like systems them make easier to understand Java. For those who are familiar with Java them make easier to understand Unix-like systems. 🙂
1. PWD
The first one is pwd that show the current working directory.
public class Jpwd {
public static void main(String[] args) {
String pwd = System.getProperty("user.dir");
System.out.println(pwd);
}
}
Running this at /home/silveira directory gives us as output:
$ java Jpwd
/home/silveira
1. CAT
The command cat is usually utilized for displaying files.
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
public class Jcat {
public static void main(String[] args) {
if(args.length==1){
try {
FileReader fileReader = new FileReader(args[0]);
BufferedReader in = new BufferedReader(fileReader);
String line;
while((line = in.readLine())!= null){
System.out.println(line);
}
} catch (FileNotFoundException ex) {
System.out.println(args[0]+", file not found.");
}
catch (IOException ex) {
System.out.println(args[0]+", input/output error.");
}
}
}
}
$ java Jcat /etc/timezone
America/Fortaleza
3. LS
The command ls is to list files. The File API (java.io.File) is very flexible and portable, but in this example I want just list files and directories of the current directory.
import java.io.File;
public class Jls {
public static void main(String[] args) {
File dir = new File(System.getProperty("user.dir"));
String childs[] = dir.list();
for(String child: childs){
System.out.println(child);
}
}
}
Usage:
$ java Jpwd
/home/silveira/example
$ java Jls
directoryA
fileA
.somefile
4. CD
The cd command changes the current working directory.
import java.io.File;
public class Jcd {
public static void main(String[] args) {
if(args.length==1){
File dir = new File(args[0]);
if(dir.isDirectory()==true) {
System.setProperty("user.dir", dir.getAbsolutePath());
} else {
System.out.println(args[0] + "is not a directory.");
}
}
}
}
Usage:
$ java Jpwd
/home/silveira
$ java Jcd /tmp
$ java Jpwd
/tmp
Ilustrative image 😛
This is the first of a serie of posts I’d like to write while I’m studying more about OpenSolaris. The idea is to create simple posts showing a specific feature through practical examples that you can reproduce in your computer.
One of the most interesting feature on OpenSolaris is the 128-bit filesystem ZFS.
For those who are starting with ZFS, the main diference is the abstraction used for volumes. Unlike traditional file systems, which reside on single devices and thus require a volume manager to use more than one device, ZFS filesystems are built on top of virtual storage pools called zpools. One zpool is constructed of virtual devices (vdevs), which are themselves constructed of block devices: files, hard drive partitions, or entire drives (the recommended usage).
In this first experiment we will construct a mirrored zpool (RAID-1) and so try to corrupt its data and see what happens. In a mirrored pool the data is replicated into many disks and that eliminates the critical point, ie if one disks stops the data is not corrupted. You’ll can create a mirror with two or more disks and inside a pool you can have many mirrors. By example, one pool of 100Gb made by two mirrors, each one with 50Gb and each mirror made by volumes of 25Gb. You’ll scale your pool according your needs and capabilities.
This part of corrupt data make this experiment a little dangerous. You have these options:
- Install OpenSolaris in your disk and have at least two more disks to make a mirrored zpool. I don’t recommend this option because if you don’t know exactly what you are doing you can lose important data if you use the wrong volumes.
- Install OpenSolaris in a virtual machine and create fake volumes for this experiment. If you make some mistake nothing too bad will happen. That’s the option I’m using. Here I’m using VirtualBox with OpenSolaris 2008.5. VirtualBox is a free virtual machine, easy to use and works well with OpenSolaris.
Although there is already a graphical tool for manage ZFS, this is not available at OpenSolaris 2008.5. Also for who are studying ZFS a little bit deeper, know how to manage it by command line tools is interesting.
With your OpenSolaris booted, open a terminal and log yourself as root. Consult your available devices with echo|format.
If you are familiar with Linux, OpenSolaris nomenclature for devices may sound strange. I recommend you to take a look at this document.
To create a pool with the devices c4d1 (80G) and c5d1 (60GB) just type zpool create ourpool mirror c4d1 c5d1.
Explaining this command word by word:
Diagram of ourpool. Icons from Everaldo Coelho.
If your command works, it’ll works silently e will returns nothing. For check pool’s status do a zpool status ourpool.
This output shows that a pool called ourpool is ONLINE and is made of one only mirror, that is made of two devices c4d1 e c5d1.
We can list all pools with zpool list.
Ourpool has approximately 60Gb size which 900kb is already used for store metadata. As we did a mirror using volume of 60Gb and 80Gb, the mirror size is determined by the smaller volume. The another pool, rpool is a pool that OpenSolaris creates by defaul to place the system.
Now we’ll populate the pool with data. These data could be real important data like data base files, your photo collection or personal documents. For illustrative effect I’m using a 100Mb empty file called data. mkfile 100m data.
While the file creation I did a zpool iostat -v ourpool too see the IO traffic in the pool. Note that there’s traffic on both disks as they form a mirror.
We will create and save a file of md5 checksum of date to be able to check its integrity later, md5sum data > data.md5. Too see if a checksum matches we do a md5sum –check data.md5.
Now comes the critical part of this simulation. We will simulate a physical defect on the disc. Storage devices will fail at some point, but we don’t know when. When it happens it can corrupt your data or stop important applications.
Let’s get 20Mb of garbage from /dev/urandom e throw them in the disk c4d1, dd if=/dev/urandom of=/dev/dsk/c4d1 bs=1024 count=20480. There’s more fun (and expensive) ways to case physical defects in a disk, take a look into this video where they use ZFS and hammers. 🙂
Ready, the damage was done. Let’s look the pool status, zpool status ourpool.
We see no error but the ZFS uses strongly memory cache. Let’s force clean this cache by disabling and enabling the pool. First cd / to assure we are not into the pool, so zpool export ourpool followed by zpool import ourpool.
Checking it’s status again, zpool status ourpool.
Pool remains ONLINE but ZFS noticed that something is wrong.
Let see the data integrity, md5sum –check data.md5.
This is one of the characteristic of self healing in ZFS. The corruption that occurred in one volume was silently repaired. In a traditional volume manager you would not only lost our data but not event know that a corruption has occurred.
In this point the system administrator should be warmed to take some action on the defective disk. Here some advices:
I also did a screencast the resumes the entire process:
This post is a english translation for this post.
Imagem meramente ilustrativa 😛
Esse é o primeira de uma série de posts que eu pretendo escrever ao mesmo tempo que eu estudo mais sobre OpenSolaris. A idéia é criar artigos simples mostrando funcionalidades bem especÃficas através de experimentos práticos que você pode replicar em seu computador.
Uma das funcionalidades mais interessantes do OpenSolaris é o sistema de arquivo de 128-bits ZFS. Para quem está começando a principal diferença é a abstração utilizadas para os volumes. Ao contrário dos sistemas de arquivos tradicionais, onde cada um reside em um único dispositivo e requerem um gerente de volumes para usar mais de um dispositivo, o sistema de arquivo ZFS é construÃdo sob pools de armazenamento virtuais chamados zpools. Um zpool é construÃdo de dispositivos virtuais (vdevs) quem são constituÃdos de volumes de bloco (arquivos, partições de um disco ou discos inteiros, o que é o recomendado).
Esse primeiro experimento vai ser construir zpool espelhado (RAID-1) e depois tentar corromper os dados dele e ver o que acontece. Em um pool espelhado, os dados são replicados para vários discos e isso elimina o ponto crÃtico, ou seja, se um disco parar de funcionar, os dados não são corrompidos. Você pode criar um espelho com dois ou mais discos e dentro de um mesmo pool você pode ter vários espelhos. Por exemplo, um pool de 100Gb formado por dois espelhos, cada um com 50GB e cada espelho formado por discos rÃgidos de 25Gb cada um. Você vai dimensionar seu pool de acordo com suas necessidades e capacidades.
Essa parte de corromper os dados faz experimento ser um pouco perigoso. Eu te aconselho a fazer uma dessas sugestões:
- Instalar o OpenSolaris no seu disco e pelo menos outros dois discos rÃgidos para fazer um zpool espelhado. Eu não recomendo essa opção porque se você não souber muito bem o que está fazendo você pode corromper dados acidentalmente.
- Instalar o OpenSolaris em uma máquina virtual e criar discos rÃgidos falsos para utilizar no experimento. Assim mesmo que você cometa algum erro nada de muito ruim vai acontecer. Essa é a opção que eu escolhi e aqui eu estou usando o VirtualBox com o OpenSolaris 2008.5. É uma máquina virtual livre, muito fácil de usar e o OpenSolaris se dá muito bem com ele.
Embora já exista uma interface gráfica para controle para ZFS, está não está incluÃda no OpenSolaris 2008.5. Além disso para quem quer estudar o ZFS um pouco mais a fundo, acho que conhecer seu controle via linha de comando é interessante.
Com o OpenSolaris já bootado, abra um terminal, logue-se como root e consulte os seus dispositivos com echo|format.
Se você esta bem familiarizado com Linux você deve estranhar a nomenclatura dos dispositivos no OpenSolaris, eu recomendo voce dar uma olhada nesse documento.
Parar criar um pool com os dispositivos c4d1 (80G) e o c5d1 (60GB) basta simplesmente um zpool create ourpool mirror c4d1 c5d1.
Explicando esse comando palavra a palavra:
Diagrama do pool que criamos. Ãcones do Everaldo Coelho.
Se o comando funcionou, ele agira silenciosamente e nao retornar nada. Para checar o estatus do pool fazemos um zpool status ourpool.
Essa saÃda nos diz que o pool chamado ourpool está com o status ONLINE e que o pool é composto de um único mirror que por sua vez é composto dos dispositivos c4d1 e c5d1.
Podemos listar todos pools com zpool list.
O ourpool tem aproximadamente 60GB de tamanho dos quais 900kb já foram usados para guardar metadados. Como nós usamos um espelho de discos de 60GB e de 80GB, o tamanho do pool foi determinado pelo tamanho do menor disco. O outro pool, rpool é o pool que o OpenSolaris cria por default para abrigar o sistema inteiro.
Agora vamos povoar o pool com dados. Estes dados poderiam ser dados reais importantes como os arquivos de um banco de dados, sua coleção de fotos ou seu arquivo de documentos. Para efeitos ilustrativos eu vou usar aqui um arquivo vazio de 100Mb chamado data. mkfile 100m data.
Durante a criação do arquivo eu dei um zpool iostat -v ourpool para ver o tráfego na entrada/saÃda do pool. Note que há tráfego em ambos os discos já que eles formam um espelho.
Vamos criar e guardar um checksum md5 do arquivo data para podermos checar sua integridade mais tarde, md5sum data > data.md5. Para checarmos se esse checksum bate com o checksum do arquivo fazemos um md5sum –check data.md5.
Agora vem a parte crÃtica dessa simulação. Vamos simular um defeito fÃsico no disco. Dispositivos de armazenamento vão falhar em algum momento, só não sabemos quando, e quando acontecer ele poderá corromper seus dados ou parar aplicações importantes.
Vamos pegar 20 Mb de lixo retirado do /dev/urandom e joga-los no disco c4d1, dd if=/dev/urandom of=/dev/dsk/c4d1 bs=1024 count=20480. Existem formas mais divertidas (e caras) de provocar defeitos fÃsicos, dê uma olhada nesse vÃdeo onde eles usam ZFS e martelos. 🙂
Pronto, o estrago foi feito. Olhamos o status do pool, zpool status ourpool.
Não vemos nenhum erro até porque o ZFS é baseado em cache na memória. Vamos forçar ele a limpar esse cache derrubando e subindo o pool. Primeiro cd / para termos certeza que não estamos dentro do pool, depois um zpool export ourpool seguido de um zpool import ourpool.
Olhamos o status novamente, zpool status ourpool.
O pool continua ONLINE mas o ZFS sabe que alguma coisa está errada.
Vamos checar a integridade dos dados checando nosso checksum md5, md5sum –check data.md5.
Os dados estão intactos.
Essa é uma das caracterÃsticas de self-healing do ZFS. A corrupção de dados que ocorreu em um dos volumes espelhados foi reparada silenciosamente. Em um gerenciador de volumes tradicional você não só teria perdido seus dados como nem sequer saberia que houve corrupção.
Mas nesse ponto o administrador do sistema deve ser avisado para tomar alguma atitude em relação ao disco defeituoso. Estas são algumas sugestões:
Pra resumir tudo, eu fiz esse screencast:
Documentação complementar:
Há uma tradução para inglês desse post.