Na última edição da newsletter do site Netcraft, vi uma estatística sobre o uso do Apache webserver que me deu um frio na barriga. Assim como o clássico americano "o último dos moicanos", parece que estamos vivendo tempos de extinção também de projetos open sources.
Não, o projeto Apache não está acabando.
De acordo com as estatísticas de servidores web no ar, coletada mensalmente pela Netcraft desde quando eu soube o que era Internet (na verdade desde que eu soube o que era Linux), mostra que o uso do Apache nunca esteve num patamar tão baixo de uso. Os dados se comparam com os de 1995! Ou seja, depois de quase 20 anos reinando como o melhor webserver de todos, desbancando até os servidores proprietários da época como o da NCSA (era o Netscape?) e da própria Sun, agora o Apache vê seu rival IIS pronto pra tirar seu pódio e se tornar o mais usado servidor web.
Parte da culpa disso, é claro, vem da adoção do cloud da Microsoft, o Azure. Tem também a parcela de crescimento do "new kid on the block" do pedaço, o nginx. Mas parece ser inevitável uma mudança no comportamento de uso dos servidores web, trocando o open source pelo proprietário.
As consequências podem ser as piores possíveis, indo da diminuição de contribuições ao projeto Apache, o que talvez leve a um total abandono de seu uso, até o risco da Microsoft enfiar algum serviço proprietário web, como um protocolo fechado, que só funcione em servidores IIS/Azure com browser Internet Explorer (vide protocolo do Exchange Server com o Outlook, o MAPI). Esse risco sempre existe quando se trata de Microsoft, que não pensa duas vezes em criar barreiras de uso pra aprisionar ainda mais seus usuários.
Por outro lado mostra também que a grande maioria dos desenvolvedores estão migrando pra web. E infelizmente trazendo as péssimas práticas que aprenderam nas escolas, aquelas que têm todo um parque de ferramentas e máquinas doados pela Microsoft.
É triste de ver...
Quem passou por aqui nesses últimos dias com certeza notou que o site tava uma zona. Tava sem formatação, sem logo, às vezes sem nada. Como se diz "em casa de ferreiro, o espeto é de pau", por aqui não é diferente e resolvi aplicar uma atualização no Joomla sem fazer backup. Metodologia #XGH está no sangue, não dá pra evitar. O upgrade simplesmente acabou com o funcionamento do template que estava o site. Fiquei essa semana toda tentando arrumar o template, e ao mesmo tempo experimentando alguns outros. Mas buscar "template free joomla" na Internet é quase uma busca pelo santo Graal. Quase tudo é pago, feito de "windows users" para "windows users" e pouco coisa sai da forma que se deseja. A menos que pague por um serviço de consultoria.
Mas sou brasileiro, no exterior é verdade, então não desisto nunca. Achei um template legal e fui acertando, arrumando os pontos, as posições e agora está com uma cara aceitável. Pelo trabalhão que deu, espero não precisar ter de fazer isso novamente tão cedo.
Ou talvez aprender mais como fazer um design bonitinho de site pra não ter de depender de outros. Afinal não uso mesmo tanta coisa assim.
Nada como começar 2014 com um post sobre nvidia. Não que 2014 tenha começado agora, mas não tive muito assunto pra escrever até o momento (na verdade tive, mas a inércia de 2013 foi mais forte).
Estou trabalhando num ambiente que usa pesadamente linux containers, os lxc, que é uma forma de virtualização. Pra minha triste surpresa, muitas funcionalidades não ficam ativas no lxc com o kernel-pf. Então resolvi voltar pro bom e velho kernel Linux padrão, baixado diretamente de https://www.kernel.org
Compilação feita, com parâmetros pra funcionamento dos linux containers (é preciso ativar cgroups em toda sua funcionalidade) e, antes do boot, aparece um upgrade dos drivers da nvidia. Já que ia fazer um reboot, resolvi fazer tudo de uma vez.
O boot do kernel linux-3.13.0-helio.3 (3ª versão, as outras duas ou eu esqueci algo, ou falhou em algum parâmetro que deixei fora) foi tranquilo mas o Xorg... esse subiu com noveau, bem inferior ao drive da nvidia. Ao tentar carregar o módulo da nvidia manualmente, pra descobrir qual o problema, surgiu a seguinte mensagem:
[ 89.005614] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
[ 386.837191] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
Procurando pela Internet, descobri que justamente o pacote novo da nvidia, nvidia-331 (ou nvidia-331_331.38-0ubuntu0.0.1~xedgers~precise2_amd64.deb), tem esse erro com kernels 3.13, pois a função EXPORT_SYMBOL(acpi_os_wait_events_complete) foi removida do mesmo.
A correção não é muito complexa. Basta aplicar a seguinte correção dentro de "/usr/src/nvidia-331-331.38", que foi criado durante a instalação do pacote:
--- nvidia-331-331.38/nv-acpi.c.orig 2014-01-21 11:44:59.485055493 +0100
+++ nvidia-331-331.38/nv-acpi.c 2014-01-21 11:44:22.664056579 +0100
@@ -301,13 +301,13 @@
"NVRM: nv_acpi_remove: failed to disable display switch events (%d)!\n", status);
}
- if (pNvAcpiObject->notify_handler_installed)
+ /* if (pNvAcpiObject->notify_handler_installed)
{
NV_ACPI_OS_WAIT_EVENTS_COMPLETE();
// remove event notifier
status = acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY, nv_acpi_event);
- }
+ }*/
if (pNvAcpiObject->notify_handler_installed &&
ACPI_FAILURE(status))
É um comentário em toda a parte de código que usa a função problemática. Uma vez que a chamada de kernel não existe mais, não deve causar grandes impactos. Então basta atualizar o dkms, que no meu caso fiz com o kernel de nome linux-3.13.0.helio-3.
dkms remove -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms build -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms install -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
Com isso o módulo novo, com o patch acima, é construído. Então basta rebootar pra ter o kernel novo rodando e correr pro abraço :-)
Software livre me faz lembrar pizza em vários aspectos: gosto de pizza como de software livre, é prática de fazer e comer, poucas pessoas não gostam (só as que não experimentaram na verdade), todos sabem como fazer (quais os ingredientes usados) e posso conseguir de vários lugares diferentes, as pizzarias, experimentando uma pizza de um sabor novo em cada lugar. Além de que cada região tem uma personalidade própria em sua pizza.
Quando se tem uma empresa de software livre, em certos aspectos de negócios não se difere muito de uma pizzaria. Em geral pizza não é um segredo e suas receitas são abertas (conhecidas). Qualquer pessoa pode iniciar uma pizzaria. Mas no mundo dos negócios, seja em pizzas ou seja em software livre, as coisas nem sempre vão bem. É possível notar pela quantidade de pizzarias que abrem e fecham logo em seguida. O mesmo com empresas e profissionais de software livre.
Se pizzas são gostosas e todos comem, e não se paga nada por suas receitas (o código fonte), então por qual motivo as pizzarias não dão todas certo?
Com certeza não são as pessoas, os usuários de pizza (soa meio como tráfico de drogas, mas vamos deixar assim por enquanto), os culpados. O que realmente atrapalha as pizzarias são... elas próprias e as outras pizzarias.
Essa disputa entre pizzarias pelo gosto dos usuários é chamado de competição no mundo dos negócios. Como se pode notar pelas pizzas, nem sempre uma pizzaria é ganhadora do gosto de todos o tempo todos. Todo mundo experimenta pizzas de vários lugares e nem sempre isso significa a falência das outras pizzarias. Então a competição nos negócios não é o extermínio dos outros competidores, mas a alternância desses para ganhar a decisão do cliente. O problema é quando nossa empresa nunca acaba sendo escolhida por nenhum cliente e por muito tempo.
Um dos fatores que leva tanto as pizzarias quanto as empresas de software livre a sair do mercado é a falta de clareza em como elas se estabelecem pra competir pelo gosto do usuário. Quando digo aqui empresas, digo também profissionais, afinal não é pequena a quantidade de pessoas que começam a trabalhar com software livre mas em certo ponto de suas carreiras profissionais abandonam tudo pra usarem Windows e outros softwares proprietários. De acordo com um dos papas na área de gestão estratégica de empresas, Michael Porter, um professor de Harvard, existem 2 formas de competição: por diferenciação ou por custos. O melhor é escolher uma dessas estratégias de competição e atuar somente nela, não misturado com a outra. Não que isso seja impossível, mas é preciso ter muito cuidado pra não misturar ambas e acabar por arruinar seu negócio.
Red Hat Inc., um dos maiores nomes no mundo de software livre, responsável pela distribuição empresarial de mesmo nome e mantenedora do projeto Fedora, fechou o ano fiscal de 2012 com vendas no valor de 1,33 bilhões de dólares. Lucro líquido de 209 milhões de dólares. Essa é uma empresa que demonstra como participa de sua competição utilizando a estratégia da diferenciação.
Red Hat Inc. vende um Linux como outro qualquer: baseado em código aberto. Tanto que a distribuição CentOS nada mais é que a compilação dos fontes do produto Red Hat Enterprise Linux, a versão empresarial de Linux da Red Hat. Então como uma empresa que vende algo gratuito e aberto consegue tanto dinheiro? Pelo seu diferencial de serviço. A Red Hat Inc. agrega um serviço preferencial de suporte. Empresas compram o Red Hat Enterprise Linux não somente por se tratar de Linux, mas por vir com a gama de serviços que a Red Hat presta, como atendimento 24x7, suporte on-site, atendimento telefônico, etc.
Entre tantas empresas de Linux, e mesmo distribuições, a Red Hat Inc. soube mostrar um diferencial a mais para cativar o público corporativo. E de uma forma bem lucrativa, mas sempre mantendo o espírito do software livre.
Quase todos que mexem alguma coisa com software livre conhecem o sistema de hospedagem da Amazon. E conhecem por ser... barato! A Amazon Inc. utiliza uma estratégia de baixo custo pra competir na área de cloud computing. Isso significa que muitos mais usuários utilizarão a plataforma e, a cada novo usuário, ela conseguirá baixar ainda mais seus preços. Essa é a competição por custos: mantendo o menor custo possível de operação e com o maior número de clientes possível.
Com esses dois modelos de competição em mente, já é possível entender o motivo pelo qual nem toda pizzaria se mantém aberta. É difícil ter uma pizzaria com área de recreação, som ambiente, manobrista na porta e cobrar um preço baixo pela pizza. Opta-se por um ou pelo outro para se ter sucesso.
Em software livre, eu acredito que deveria ser o mesmo. Em geral eu visualizo que a maioria dos empreendimentos de software livre utilizam a estratégia da diferenciação, por entregar um "algo a mais". Mas e quando alguém faz o mesmo?
Sim, estratégia é uma parte, importante, mas só uma parte.
Desde que o twitter liberou o histórico dos tweets antigos em formato CSV, procurei uma ferramenta para poder um tagcloud das minha palavras. Como o arquivo era muito grande (mais de 3 MB), as ferramentas online simplesmente travavam.
Procurando por alternativas, encontrei o pouco citado pytagcloud.
Então fiz o seguinte programa pra gerar o tagcloud dos meus tweets:
#! /usr/bin/pyhon
# -*- coding: utf-8 -*-
import re, csv
from pytagcloud import create_tag_image, make_tags
from pytagcloud.lang.counter import get_tag_counts
TWEETS = "tweets.csv"
buffer = ""
tws = csv.reader(open(TWEETS), delimiter=',', quotechar='"')
for rows in tws:
buffer += rows[5] + "\n"
output = "clound_large.png"
tags = make_tags(get_tag_counts(buffer), maxsize=120)
create_tag_image(tags,
output,
size=(800, 600),
fontname='Lobster')
Foi exatamente a cópia do programa documentado pelo próprio pytagcloud. Pra minha supresa, não funciona e sai o seguinte erro:
Traceback (most recent call last): File "generate_cloud.py", line 53, in File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 344, in create_tag_image File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 275, in _draw_cloud File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 62, in __init__ IOError: unable to read font filename Error in sys.excepthook: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in apport_excepthook ImportError: No module named fileutils Original exception was: Traceback (most recent call last): File "generate_cloud.py", line 53, in File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 344, in create_tag_image File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 275, in _draw_cloud File "/usr/local/lib/python2.7/dist-packages/pytagcloud/__init__.py", line 62, in __init__ IOError: unable to read font filename
Após muito mexer, pois o código exemplo, com texto menor, funciona perfeitamente, descobri que esse erro é gerado pela quantidade de palavras no arquivo de tweets. Consegui corrigir isso colocando um limite no tamanho dos tags, que é um array.
E foi-se a Python Brasil 9, em Brasília. Evento muito legal e que reuniu a comunidade de desenvolvedores python tupiniquins.
Eu participei falando um pouco do meu trabalho em telecomunicações. Minha apresentação foi essa abaixo, "python in telecommunications", que contou um pouco da história do nono dígito. Claro que não dá pra entender muito, uma vez que tem mais imagens que informação, mas mostra bem como python ajudou a ter uma solução mais robusta e limpa em relação a anterior, que rodava em shell script.
Quais são a 4 liberdades do software livre, segundo o próprio Stallman?
As mesmas foram copiadas da página do projeto GNU, em "a definição do software livre". Ainda no mesmo é possível ler:
"Um programa é software livre se os usuários possuem todas essas liberdades. Portanto, você deve ser livre para redistribuir cópias, modificadas ou não, gratuitamente ou cobrando uma taxa pela distribuição, a qualquer um, em qualquer lugar. Ser livre para fazer tudo isso significa (entre outras coisas) que você não deve ter que pedir ou pagar pela permissão para fazê-lo."
Apesar da relutância de algumas pessoas, software livre não significa exatamente software gratuito. Quando alguém adota um licença livre, permite entre outras coisas que seu software seja vendido e outra pessoa ganhe com isso.
Sempre é fácil exaltar os benefícios do software livre, como compartilhamento e conhecimento. De ter uma comunidade em volta da mesma. Mas quando o assunto chega no bolso, na parte financeira, parece que dói na vaidade de algumas pessoas aceitar isso.
Observando outro dado importante sobre software livre, mais precisamente o kernel Linux (fonte: arstechnica):
Das contribuições ao kernel entre 2012 e setembro de 2013,somando os sem qualquer vínculo com os desconhecidos, os consultores e o acadêmicos, tem-se 19.5% de código gerado por eles contra 52,5% gerado por empresas, isso olhando apenas essa lista e não todas as contribuições. Ou seja, empresas que têm uma visão de negócios investem fortemente em software livre e são no momento a maioria do commits de código no kernel Linux.
O que estou tentando mostra aqui é que existe um interesse financeiro pra tal investimento das empresas. Existe um modelo de negócios com software livre, apesar de negado com todas as forças por muitas pessoas.
Quando se fala em software livre, todos lembram de usar um licença de acordo, seja GPL2, GPL3, BSD, Mozilla, Artistic ou qualquer outra livre, mas nunca pensa num ponto importante: como ganhar dinheiro com esse software? E isso não deveria ser combatido, mas fomentado, pois como apresentei no início, em momento algum Richard Stallman fala para não se fazer um modelo de negócios com software livre e que lucrar com isso seja errado.
Eu poderia então pegar uma distro como Debian, colocar numa embalagem bonita, adicionar manuais impressos, criar caixas com um logo novo, chamar de HeliOSTM, e vender ao preço de R$ 500,00 a caixa. Eu só precisaria incluir o código fonte disponível, até no site e separado das mídias, e incluir no manual dizendo que o sistema é baseado em Debian. Claro que isso por si só não bastaria. Seria preciso verificar quem seria meu mercado consumidor e iniciar uma campanha de marketing direcionada para comprovar como o HeliOSTM é um dos melhor sistemas para se usar num computador. E em nenhum momento eu estaria indo contra os 4 princípios do software livre. E nem precisaria realmente fazer o software: poderia continuar copiando do Debian.
Isso é apenas um exemplo pra ilustrar como é possível fazer negócios com software livre, gostando os desenvolvedores e comunidade ou não. E sempre é preciso pensar nisso: em qual parte da cadeia gostaria de estar? Em quem faz o negócio com o software livre, ou quem gera software pra outros comercializarem. O software livre permite que todos estejam do outro lado, que sejam seus próprios patrões. Mas pra isso é preciso estar preparado e não ter uma visão ingênua do software livre, de comunidade, mas um foco em como ter sua vida baseada nele.
Tentarei manter um ritmo de posts sobre o assunto e descrever como fazer o primeiro milhão de software livre (para quem ainda não o fez).
Eu me sinto bastante solidário com as pessoas que investiram no TelexFree e acho muito injusto que saiam com tal prejuízo financeiro. Como fizeram um investimento em tecnologia sem o conhecimento necessário sobre a mesma, ou até sobre o retorno do investimento, acho que vale a pena sugerir alguns negócios melhores que TelexFree.
Com certeza que são tecnologias que abrirão muitas portas para todo esse pessoal esquecido do norte do país, principalmente do estado do Acre.
Se não investiu em TelexFree e mesmo assim quiser experimentar os serviços abaixo, garanto que não se decepcionará. São todos GRÁTIS! Totalmente grátis! Fácil assim. Apenas criar uma conta e usar. Não há investimento melhor.
Depois não digam que não ajudei.
Recentemente participei de um opencast do Ivan, Ubunterobr, sobre Debian.
O objetivo era explicar um pouco sobre o Debian, sua história, suas versões e, principalmente, como experimentar. E também um pouco sobre comunidade, que é a parte mais importante pra nós usuários comuns.
Maiores informações de Debian:
Depois de uma longa batalha pra atualizar meu PC, consegui deixar tudo redondo pra jogar L4D2 (Left for Dead 2) com o pessoal. E sobre o Ubuntu.
Um dos empecilhos era em relação às configurações de controle do jogo, que por padrão usa o mouse e o teclado. Eu até tentei usar no início, mas estou acostumado com os consoles, xbox360 e ps3, e com seus respectivos controles. Então era um sofrimento jogar.
Tentei utilizar os controles dos dois no Linux, mas vi na Internet que o melhor controle é o do xbox, mas não o wireless, o cabeado. Sem problemas. Sai caçando um e comprei na loja xing-ling de origem questionável mais próxima (na av. Paulista).
Quando fui jogar, nova decepção: não mapeava corretamente os movimentos. Mas uma alma caridosa conseguiu fazer o mapeamento usando um driver através do programa xboxdrv (tem pra Ubuntu).
Criei então os seguinte script pra mapear o controle e jogar com os amigos:
#! /bin/sh
# Name: xbox360controler_setup.sh
# Source http://ubuntuforums.org/showthread.php?t=2002622
case `whoami` in
root) echo "Running as root";;
*) echo "You must run it as root. Using sudo for that."
sudo $0
exit 0
esac
rmmod xpad
modprobe uinput
modprobe joydev
rmmod xpad
xboxdrv \
-s \
--type xbox360 \
--deadzone 9000 \
--dpad-as-button \
--trigger-as-button \
--ui-axismap "x2=REL_X:10,y2=REL_Y:10,x1=KEY_A:KEY_D,y1=KEY_W:KEY_S" \
--ui-buttonmap "tl=KEY_LEFTSHIFT,tr=KEY_LEFTCTRL" \
--ui-buttonmap "a=KEY_SPACE,b=KEY_C,x=KEY_1,y=KEY_R" \
--ui-buttonmap "lb=KEY_Q,rb=KEY_E" \
--ui-buttonmap "lt=BTN_RIGHT,rt=BTN_LEFT" \
--ui-buttonmap "dl=KEY_LEFT,dr=KEY_RIGHT,du=KEY_UP,dd=KEY_DOWN" \
--ui-buttonmap "back=KEY_ESC,start=KEY_ENTER"
Boa jogatina e lembre-se: se for jogar, pode me chamar. Não garanto lá um desempenho muito bom, mas a diversão é garantida.
Dia desses eu redescobri as imagens da minha webcam. Tirei vários screenshots usando o aplicativo cheese, desde que minha mais nova nasceu. E nem lembrava disso.
Consegui criar uma videozinho com elas, o que foi bem legal, mostrando o crescimento dela (e minha barba ficando cada vez mais branca).
A idéia inicial era gerar um gif animado, mas o mesmo ficou em 85 MB de tamanho. E sem som.
Então resolvi fazer 2 coisas:
A captura do screenshot, eu consegui fazer utilizando pygame. O módulo já inclui vários binding pra realizar ações como capturar da webcam e salvar a imagem. O script ficou assim:
#! /usr/bin/python -u
"""
Not only Obamas _is_ watching you...
Based in: http://stackoverflow.com/questions/15870619/python-webcam-http-streaming-and-image-capture
"""
SAVEDIR = "/home/helio/Pictures/Webcam"
import pygame, sys
import pygame.camera
import time, random
pygame.init()
pygame.camera.init()
cam = pygame.camera.Camera("/dev/video0", (640,480))
while True:
print "Taking a shot:",
cam.start()
image = cam.get_image()
cam.stop()
timestamp = time.strftime("%Y-%m-%d_%H%M%S", time.localtime())
filename = "%s/%s.jpg" % (SAVEDIR, timestamp)
print "saving into %s" % filename
pygame.image.save(image, filename)
time.sleep(random.randrange(10) * 60)
Chamei de obamawatch.py em homenagem à espionagem da NSA nas nossas vidas, e que o presidente Obama não fez esforço nenhum pra diminuir ou mesmo evitar. É um script super intrusivo, pois tira fotos de tempos em tempos, podendo pegar situações que... humm... não o faça se sentir muito orgulhoso. Então é bom rodar de vez em quando.
Pra juntar as imagens JPEG geradas em um GIF animado, usei o imagemagick com o mogrify. Com o mogrify, na verdade, eu diminui as imagens pra 320x240 pixels, pra diminuir o tamanho. Então usei o imagemagick pra gera o GIF.
mogrify -resize 320x240 *jpg
gm convert -delay 20 2013-09-07_1* animated-2013-09-07.gif
Com isso consegui o resultado abaixo. Bem divertido.
Às vezes eu escrevo programas. Entre esse programas, alguns são daemons.
Além da confusão com demônios, o que são daemons?
Daemons são os programas que rodam em background no sistema, não precisando de um terminal (console) anexado. E qualquer tipo de programa pode ser um daemon, pra qualquer finalidade.
Em geral daemons seguem as seguintes regras pra se tornarem daemons:
O segundo fork() é feito para garantir que o programa, através do segundo processo filho, seja "herdado" pelo processo init do sistema.
Em Python, sempre incluo uma função como essa:
def Daemonize(self):
"""
Fork to became a daemon.
"""
if not self.isDaemon:
try:
self.run()
except KeyboardInterrupt:
sys.exit(0)
return
os.chdir("/")
pid = os.fork()
if (pid > 0):
sys.exit(os.EX_OK)
else:
pid = os.fork()
if (pid > 0):
sys.exit(os.EX_OK)
else:
self.run()
Esse é parte de um método, mas poderia ser uma função. A idéia é usar o getopt() para verificar as opções passadas e entrar no modo de daemon ou não, dependendo da opção passada, que modifica a variável booleana self.isDaemon.
Mas um dos meus programs começou a apresentar o seguinte erro:
helio@goosfraba:~$ connect_TSP.py ccn
IP already setup... skipping root access
Running as daemon
daemonized...
close failed in file object destructor:
IOError: [Errno 10] No child processes
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in apport_excepthook
from apport.fileutils import likely_packaged, get_recent_crashes
RuntimeError: sys.meta_path must be a list of import hooks
Original exception was:
IOError: [Errno 10] No child processes
Inicialmente achei que era problema no "apport" com meu programa, que usa python-expect. Mesmo com tal erro, o programa funcionava perfeitamente em background, como daemon. Várias fontes na Internet, principalmente no Launchpad, o sistema de bug report do Ubuntu, várias pessoas reclamavam de tal erro como sendo problema do apport.
Após muito buscar a origem do problema, não no Ubuntu, mas no python, descobri que alguns file descriptors estavam causando esse erro, por continuarem abertos quando ocorria o fork(). Corrigi da seguinte forma:
def Daemonize(self):
"""
Fork to became a daemon.
"""
if not self.isDaemon:
try:
self.run()
except KeyboardInterrupt:
sys.exit(0)
return
os.chdir("/")
pid = os.fork()
if (pid > 0):
os.close(sys.stdin.fileno())
os.close(sys.stout.fileno())
os.close(sys.stderr.fileno())
sys.exit(os.EX_OK)
else:
pid = os.fork()
if (pid > 0):
os.close(sys.stdin.fileno())
os.close(sys.stdout.fileno())
os.close(sys.stderr.fileno())
sys.exit(os.EX_OK)
else:
self.run()
então bastou fechar os descritores de arquivo do STDIN, STDOU e STDERR pra ter certeza que o daemon não sairia com o erro acima.
Happy hacking :-)
Acaba de ser publicada a edição número 52 da revista Espírito Livre. Uma edição totalmente dedicada ao FISL 14 e... com um artigo meu!!!
Nada muito estravagante, apenas uma descrição de como foi o FISL para mim. E com as fotos que tirei durante todo o evento.
Infelizmente o servidor da revista Espírito Livre parece estar sofrendo o tráfego intenso, então está bastante difícil acessar a revista e baixar. Mas aos que conseguirem (e com certeza uma hora ou outra conseguirão), espero que gostem.
Page 19 of 35
