O FreeBSD é um sistema operacional moderno para desktops, laptops, servidores e sistemas embarcados, com suporte para um grande número de plataformas.

Ele é baseado no sistema “4.4BSD-Lite” da U.C. de Berkeley, com algumas melhorias oriundas do “4.4BSD-Lite2”. Ele também se baseia indiretamente no port para i386™ feito por William Jolitz do sistema “Net/2” da U.C. Berkeley, conhecido como “386BSD”, embora muito pouco do código original do 386BSD ainda esteja presente.

O FreeBSD é usado por empresas, provedores de serviços de Internet, pesquisadores, profissionais da computação, estudantes e usuários domésticos em todo o mundo em seu trabalho, educação e recreação.

Para informações mais detalhadas sobre o FreeBSD, consulte o Manual do FreeBSD.

O objetivo do Projeto FreeBSD é fornecer um sistema operacional de propósito geral estável e rápido que possa ser usado para qualquer propósito sem restrições.

Sim. Essas restrições não controlam como o código é usado, mas como tratar o próprio projeto FreeBSD. A licença em si está disponível em licença e pode ser resumida da seguinte forma:

Muitos de nós têm um investimento significativo no projeto e certamente não nos importaríamos com uma pequena compensação financeira de vez em quando, mas nós definitivamente não insistimos nisso. Acreditamos que a nossa primeira e principal “missão” é fornecer código a todos os participantes, e para qualquer finalidade, para que o código obtenha o maior uso possível e forneça o maior benefício possível. Este, acreditamos, é um dos objetivos mais fundamentais do Software Livre e um dos que apoiamos entusiasticamente.

O código em nosso repositório de código-fonte que se enquadra na Licença Pública Geral GNU (GPL) ou na Licença Pública Geral da Biblioteca GNU (LGPL) vem com algumas restrições adicionais, ainda que sejam no sentido de forçar o acesso, em vez do habitual oposto. Devido às complexidades adicionais que podem surgir no uso comercial de um software GPL, nós nos esforçamos para substituir tais softwares por outros sob a Licença FreeBSD que é menos restritiva, sempre que possível.

Para a maioria das pessoas, sim. Mas esta questão não é assim tão simples.

A maioria das pessoas não usa um sistema operacional. Elas usam aplicativos. São os aplicativos que realmente usam o sistema operacional. O FreeBSD é projetado para fornecer um ambiente robusto e completo para aplicativos. Ele suporta uma grande variedade de navegadores da web, pacotes de escritório, leitores de e-mail, programas gráficos, ambientes de programação, servidores de rede e muito mais. A maioria destes aplicativos pode ser gerenciada através da Coleção de Ports.

Se um aplicativo estiver disponível apenas para um determinado sistema operacional, esse sistema operacional não poderá ser substituído. No entanto é provável que exista um aplicativo muito semelhante no FreeBSD. Seja como um sólido servidor corporativo, um servidor de Internet ou ainda uma confiável estação de trabalho, o FreeBSD quase certamente fará tudo o que você precisa. Muitos usuários de computador ao redor do mundo, incluindo novatos e experientes administradores UNIX®, usam o FreeBSD como seu único sistema operacional de desktop.

Os usuários que migrarem para o FreeBSD vindos de outro ambiente UNIX®-like irão achar o FreeBSD bastante similar. Os usuários de Windows® e do Mac OS® podem se interessar em usar o TrueOS, uma distribuição de desktop baseada no FreeBSD. Os usuários que não estão habituados ao uso de sistemas UNIX® devem investir algum tempo adicional aprendendo a maneira de fazer as coisas no UNIX®. Este FAQ e o Manual do FreeBSD são excelentes lugares para iniciar.

Vale ressaltar que a palavra “free” está sendo usada de duas formas aqui: uma que significa “sem custo” (grátis) e a outra que significa “faça o que quiser” (Livre). Fora uma ou duas coisas que você não pode fazer com o código do FreeBSD, por exemplo, fingir que você o escreveu, você pode realmente fazer o que quiser com ele.

O James Howard escreveu uma boa explicação da história e das diferenças entre os vários projetos BSD, chamada A árvore genealógica do BSD, a qual é uma boa forma de responder a esta pergunta. Algumas das informações estão desatualizadas, mas a parte da história em particular permanece precisa.

A maioria dos BSDs compartilha patches e códigos, até hoje. Todos os BSDs descendem dos mesmos ancestrais.

Os objetivos de design do FreeBSD estão descritos em P: 1.2, acima. Os objetivos de design dos outros BSDs mais populares podem ser resumidos da seguinte forma:

A qualquer momento no desenvolvimento do FreeBSD, podem existir vários branches paralelos. As releases 12.X são geradas a partir da branch 12-STABLE e as releases 11.X são geradas a partir do branch 11-STABLE.

Até o lançamento da versão 9.0, a série 11.X era a conhecida como -STABLE. No entanto, a partir da 13.X, a branch 11.X será designada para um status de “suporte estendido” e passará a receber apenas correções para problemas maiores, como as correções relacionadas à segurança.

A versão 12.0 é a última release da branch 12-STABLE; ela foi lançada em Dezembro de 2018. A versão 11.2 é a release mais recente da branch 11-STABLE; e foi lançada em outubro de 2017.

As releases são liberadas a cada poucos meses. Embora muitas pessoas se mantenham mais que isso por meio do código fonte do FreeBSD (veja as perguntas em FreeBSD-CURRENT e FreeBSD-STABLE ), esta periodicidade está mais para um compromisso, já que o código fonte é um alvo em movimento.

Mais informações sobre as releases do FreeBSD podem ser encontradas na página de Engenharia de Releases e em release(7).

O FreeBSD-CURRENT é a versão de desenvolvimento do sistema operacional, que no devido tempo se tornará o novo branch FreeBSD-STABLE. Como tal, ele é recomendado apenas para os desenvolvedores que trabalham no sistema e usuários amadores obstinados. Consulte a seção relevante no Handbook para detalhes sobre como executar o -CURRENT.

Usuários não familiarizados com o FreeBSD não devem usar o FreeBSD-CURRENT. Este branch às vezes evolui muito rapidamente e, devido a um erro, pode ser difícil de compilá-lo às vezes. Espera-se que as pessoas que usam o FreeBSD-CURRENT possam analisar, depurar e reportar problemas.

As snapshot releases do FreeBSD são disponibilizadas com base no estado atual das branchs -CURRENT e -STABLE. Os objetivos por trás de cada release de snapshot são:

Não temos a pretensão de que qualquer snapshot -CURRENT possa ser considerado com “qualidade de produção” para qualquer finalidade. Se você necessita de um sistema estável e totalmente testado, limite-se ao uso das releases completas.

As snapshots releases estão disponíveis em snapshot.

Os snapshots oficiais são gerados regularmente para todas as branchs ativamente desenvolvidas.

De volta quando o FreeBSD 2.0.5 foi lançado, o desenvolvimento do FreeBSD se ramificou em dois. Um ramo (branch) foi nomeado -STABLE, e o outro -CURRENT. O FreeBSD-STABLE é o branch de desenvolvimento a partir do qual os releases principais são feitos. Mudanças entram nesta branch em um ritmo mais lento e com a suposição geral de que eles foram testados primeiro no FreeBSD-CURRENT. No entanto, a qualquer momento, o código fonte para o FreeBSD-STABLE pode ou não ser adequado para uso geral, devido a descoberta de bugs e/ou outros casos específicos que ainda não foram encontrados no FreeBSD-CURRENT. Usuários que não possuem recursos para realizar testes devem, ao invés disso, executar a release mais recente do FreeBSD. O FreeBSD-CURRENT, por outro lado, tem sido uma linha ininterrupta desde que o 2.0 foi lançado, levando em direção ao 12.0-RELEASE e além. Para obter informações mais detalhadas sobre as branchs, consulte “Engenharia de Releases do FreeBSD: Criando uma Release Branch”, o status dos branches e o cronograma para releases futuros podem ser encontrados na página de informações da Engenharia de Release.

A 12.0-STABLE é a branch -STABLE desenvolvida ativamente. O último release na branch 12.0-STABLE é a 12.0-RELEASE, lançada em Dezembro de 2018.

O 12-CURRENT é a branch -CURRENT desenvolvida ativamente para a próxima geração do FreeBSD. Veja O que é o FreeBSD-CURRENT? para mais informações sobre esta branch.

A Equipe de Engenharia de Releases (Release Engineering Team) <re@FreeBSD.org> lança uma nova versão principal do FreeBSD a cada 18 meses e uma nova versão secundária a cada 8 meses, em média. As datas de lançamento são anunciadas com bastante antecedência, para que as pessoas que trabalham no sistema saibam quando seus projetos precisam ser finalizados e testados. Um período de teste precede cada lançamento, para garantir que a adição de novos recursos não comprometa a estabilidade do lançamento. Muitos usuários consideram este cuidado como uma das melhores coisas do FreeBSD, apesar de que a espera para que todas as novidades mais recentes sejam disponibilizadas no -STABLE possa ser um pouco frustrante.

Maiores informações sobre o processo de engenharia de releases (incluindo a programação das releases futuros) podem ser encontradas na página engenharia de release no site do FreeBSD.

Para aquelas pessoas que precisam ou querem um pouco mais de emoção, os snapshots binários são disponibilizados semanalmente, como discutido acima.

As principais decisões relativas ao projeto FreeBSD, tais como a direção geral do projeto e quem tem permissão para adicionar código ao repositório de código fonte, são feitas por meio de um core team de 9 pessoas. Existe uma equipe muito maior, com mais de 350 committers que estão autorizados a fazer alterações diretamente na árvore de fontes do FreeBSD.

No entanto, a maioria das alterações não-triviais é discutida com antecedência nas listas de discussão, e não há restrições sobre quem pode participar da discussão.

Todas releases importantes do FreeBSD estão disponíveis via FTP anônimo no site FTP do FreeBSD:

Informações sobre como obter o FreeBSD em CD, DVD e outras mídias podem ser encontradas no Handbook.

O banco de dados com os Relatórios de Problemas contendo todas as solicitações de mudança enviadas pelos nossos usuários pode ser consultado usando nossa interface web de consulta de PRs.

A interface web de envio de relatórios de problemas pode ser usada para enviar relatórios de problemas através de um navegador.

Antes de enviar um relatório de problema, leia Escrevendo Relatórios de Problemas do FreeBSD, um artigo sobre como escrever bons relatórios de problemas.

O projeto produz uma ampla gama de documentação, disponível on-line a partir deste link: https://www.FreeBSD.org/docs.html. Além disso, a referência bibliográfica no Handbook referencia outros livros recomendados.

Sim. A documentação está disponível em vários formatos diferentes e esquemas de compressão no site FTP do FreeBSD, no diretório /pub/FreeBSD/doc/.

A documentação é categorizada de várias maneiras diferentes. Que incluem:

Depois de escolher o formato e o mecanismo de compactação, baixe os arquivos compactados, descompacte-os e copie os documentos para um lugar apropriado.

Por exemplo, a versão split HTML do FAQ, compactada usando bzip2(1), pode ser encontrada em doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 Para baixar e descompactar esse arquivo, digite:

# fetch https://download.freebsd.org/ftp/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# tar xvf book.html-split.tar.bz2

Se o arquivo estiver compactado, o tar detectará automaticamente o formato apropriado e o descompactará corretamente, resultando em uma coleção de arquivos .html. O principal deles é chamado index.html, que conterá o sumário, o material introdutório e os links para as outras partes do documento.

Consulte as seções do Handbook sobre as listas de discussão e sobre os grupos de notícias.

Sim, a maioria das redes de IRC hospedam um canal de chat do FreeBSD:

A wiki do FreeBSD tem uma boa lista dos canais de IRC.

Cada um destes canais são distintos e não estão conectados entre si. Como os estilos de bate-papo diferem, experimente cada um deles para encontrar um adequado ao seu estilo de bate-papo.

Os fóruns oficiais do FreeBSD estão localizados em https://forums.FreeBSD.org/.

A iXsystems, Inc. , empresa controladora do FreeBSD Mall, fornece supporte comercial para o FreeBSD e TrueOS, e também soluções de desenvolvimento e customização para o FreeBSD.

A BSD Certification Group, Inc. fornece certificações de administração do sistema para o DragonFly BSD, FreeBSD, NetBSD e OpenBSD. Consulte seu site para maiores informações.

Quaisquer outras organizações que forneçam treinamento e suporte devem entrar em contato com o Projeto FreeBSD para serem listadas aqui.

amd64 é o termo que o FreeBSD usa para arquiteturas x86 compatíveis com 64 bits (também conhecidas como "x86-64" ou "x64"). Para a maioria dos computadores modernos você deve usar a opção amd64. Para hardware mais antigo você deve usar o i386. Ao instalar em uma arquitetura não compatível com x86, selecione a plataforma que melhor corresponda ao hardware.

Na página Como obter o FreeBSD, selecione [iso] ao lado da arquitetura que corresponde ao seu hardware.

Qualquer um dos itens a seguir pode ser usado:

Instruções completas sobre este procedimento e um pouco mais sobre problemas de instalação em geral podem ser encontradas na seção do Handbook sobre instalação do FreeBSD.

Isso pode ocorrer caso você não tenha baixado a imagem no modo binário ao usar o FTP.

Alguns clientes FTP padronizam seu modo de transferência para ascii e tentam alterar quaisquer caracteres de end-of-line recebidos para corresponder às convenções usadas pelo sistema do cliente. Isso quase invariavelmente corromperá a imagem de inicialização. Verifique checksum SHA-256 da imagem de inicialização baixada: se não estiverexatamente como no servidor, o processo de download pode ter corrompido o arquivo.

Ao usar um cliente FTP de linha de comando, digite binary no prompt de comando FTP depois de se conectar ao servidor e antes de iniciar o download da imagem.

As instruções para instalação podem ser encontradas na seção do Handbook sobre instalação do FreeBSD.

O FreeBSD requer um PC 486 ou melhor, 64 MB ou mais de RAM e pelo menos 1.1 GB de espaço em disco.

Uma mídia customizada de instalação do FreeBSD pode ser criada através da construção de uma release personalizada. Siga as instruções do artigo Release Engineering.

Se o Windows® for instalado primeiro, então sim. O gerenciador de boot do FreeBSD irá então inicializar o Windows® e o FreeBSD. Se o Windows® for instalado posteriormente, ela sobrescreverá o gerenciador de inicialização. Se isso acontecer, veja a próxima seção.

Isso depende do gerenciador de inicialização. O menu de seleção de inicialização do FreeBSD pode ser reinstalado usando boot0cfg(8). Por exemplo, para restaurar o menu de inicialização no disco ada0:

# boot0cfg -B ada0

O gerenciador de inicialização MBR não interativo pode ser instalado usando gpart(8):

# gpart bootcode -b /boot/mbr ada0

Para situações mais complexas, incluindo discos GPT, consulte gpart(8).

Em geral, não. Não há nada no sistema base que exija a presença do código fonte para operar. Alguns ports, como o sysutils/lsof, não serão compilados a menos que o código fonte esteja instalado. Em particular, se o port compila um módulo de kernel ou opera diretamente em estruturas de kernel, o código fonte deve ser instalado.

Geralmente não. O kernel GENERIC fornecido contém todos os drivers que um computador comum precisará. O freebsd-update(8), a ferramenta de atualização binária do FreeBSD, não pode atualizar kernels customizados, o que é uma outra razão para se manter com o kernel GENERIC sempre que possível. Para computadores com uma quantidade de memória RAM muito limitada, como sistemas embarcados, pode valer a pena compilar um kernel customizado menor contendo apenas os drivers necessários.

O FreeBSD usa SHA512 por padrão. Senhas DES ainda estão disponíveis para compatibilidade com sistemas operacionais que ainda usam um formato de senha menos seguro. O FreeBSD também suporta os formatos de senha Blowfish e MD5. O formato de senha que será usado para novas senhas é controlado pelo recurso de login passwd_format no arquivo /etc/login.conf, que recebe valores de des, blf (se estiverem disponíveis) ou md5. Veja a página de manual login.conf(5) para maiores informações sobre as capacidades de login.

Para os sistemas de arquivos FFS, o tamanho máximo é praticamente limitado pela quantidade de memória necessária para executar o fsck(8) no sistema de arquivo. O fsck(8) requer um bit por fragmento, que com o tamanho de fragmento padrão de 4 KB equivale a 32 MB de memória por TB de disco. Isso significa que nas arquiteturas que limitam os processos userland a 2 GB (por exemplo, i386™), o tamanho máximo do sistema de arquivos que o fsck(8) permite operar é de ~ 60 TB.

Se não houvesse um limite de memória para o fsck(8), o tamanho máximo do sistema de arquivos seria 2 ^ 64 (blocks) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes.

O tamanho máximo de um único arquivo FFS é de aproximadamente 2 PB com o tamanho de bloco padrão de 32 KB. Cada bloco de 32 KB pode apontar para 4096 blocos. Com blocos triplo indiretos, o cálculo é 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096 ^ 2 + 32 KB * 4096 ^ 3. Aumentar o tamanho do bloco para 64 KB aumentará o tamanho máximo do arquivo por um fator de 16.

O world (aplicativos e bicliotecas do userland)e o kernel estão fora de sincronia. Isso não é suportado. Certifique-se de usar make buildworld e make build-kernel para atualizar o kernel.

Inicialize o sistema especificando o kernel diretamente no segundo estágio, pressionando qualquer tecla quando o | aparecer antes que o utilitário de carga (loader) seja iniciado.

Sim. O bsdconfig fornece uma boa interface para configurar o FreeBSD na pós-instalação.

O motivo mais provável é a diferença entre endereços de memória física e endereços virtuais.

A convenção para a maioria dos hardwares de PC é usar a área de memória entre 3,5 GB e 4 GB para uma finalidade especial (geralmente para PCI). Este espaço de endereço é usado para acessar o hardware PCI. Como resultado real, a memória física não pode ser acessada por esse espaço de endereço.

O que acontece com a memória que deveria aparecer nesse local depende do hardware. Infelizmente, alguns hardwares não fazem nada e a capacidade de usar estes últimos 500 MB de RAM é totalmente perdida.

Felizmente, a maioria dos hardwares faz o remapeamento da memória para um local mais alto, para que ela ainda possa ser usada. No entanto, isso pode causar alguma confusão ao observar as mensagens de inicialização.

Em uma versão de 32 bits do FreeBSD, a memória parece perdida, uma vez que ela será remapeada acima de 4 GB, uma área a qual um kernel de 32 bits não consegue acessar. Neste caso, a solução é construir um kernel habilitado para PAE. Veja a seção sobre os limites de memória para mais informações.

Em uma versão de 64 bits do FreeBSD, ou quando o kernel estiver habilitado para PAE, o FreeBSD irá corretamente detectar e remapear a memória para que ela seja utilizável. Durante a inicialização, no entanto, pode parecer que o FreeBSD está detectando mais memória do que o sistema realmente possui, devido ao remapeamento descrito. Isso é normal e a memória disponível será corrigida conforme o processo de inicialização for concluído.

Os erros de sinal 11 são causados ​​quando um processo tentou acessar a memória à qual o sistema operacional não concedeu acesso. Se algo assim está acontecendo em intervalos aparentemente aleatórios, comece a investigar a causa.

Esses problemas geralmente podem ser atribuídos a:

Provavelmente não é um erro do FreeBSD se o problema ocorrer na compilação de um programa, mas sim da atividade que o compilador está realizando e que muda a cada vez.

Por exemplo, se make buildworld falhar ao tentar compilar ls.c para ls.o e, quando executado novamente, ele falhar no mesmo lugar, significa que o código está quebrado. Tente atualizar o código fonte e tente compilar novamente. Se a compilação falhar em outro lugar, é quase certo que a causa é um problema de hardware.

No primeiro caso, use um depurador como o gdb(1) para localizar o ponto no programa que está tentando acessar um endereço falso e corrija-o.

No segundo caso, verifique qual peça de hardware está com defeito.

As causas comuns disso incluem:

Leia a seção sobre o Signal 11 para obter maiores explicações e a discussão sobre como um software ou hardware de teste de memória ainda pode deixar passar uma memória defeituosa. Existe uma extensa FAQ sobre o problema do SIG11 disponível neste link.

Por fim, se nada disso ajudou, trata-se possivelmente de um bug no FreeBSD. Siga estas instruções para enviar um relatório de problemas.

Os desenvolvedores do FreeBSD estão interessados ​​nesses erros, mas precisam de mais informações do que apenas a mensagem de erro. Copie a mensagem completa da falha. Em seguida, consulte a seção FAQ em kernel panics, compile um kernel de depuração e obtenha um backtrace. Isso pode parecer difícil, mas não requer nenhuma habilidade de programação. Apenas siga as instruções.

O kernel do FreeBSD permitirá que apenas um certo número de processos exista ao mesmo tempo. O número é baseado na variável kern.maxusers do sysctl(8). O valor da variável kern.maxusers também afeta vários outros limites dentro do kernel, como por exemplo os buffers de rede. Se a máquina estiver muito carregada, aumente o kern.maxusers. Isso aumentará esses outros limites do sistema além do número máximo de processos.

Para ajustar o valor da variável kern.maxusers , consulte a seção Limites de Arquivos / Processos do Handbook. Apesar desta seção se referir a arquivos abertos, os mesmos limites se aplicam aos processos.

Se a máquina estiver levemente carregada, mas executando um número muito grande de processos, ajuste o valor do kern.maxproc definindo-o no arquivo /boot/loader.conf. O ajuste não terá efeito até que o sistema seja reinicializado. Para mais informações sobre o tuning de variáveis, consulte o manual do loader.conf(5). Se esses processos estiverem sendo executados por um único usuário, ajuste o kern.maxprocperuid para que fique menor em 1 unidade do novo valor do kern.maxproc. Ele deve ser pelo menos uma unidade menor porque o programa do sistema, init(8), deve estar sempre em execução.

A máquina remota pode estar configurando o tipo de terminal para algo diferente de xterm , que é o tipo requerido pelo console do FreeBSD. Alternativamente, o kernel pode ter valores errados para a largura e a altura do terminal.

Verifique se o valor da variável de ambiente TERM é xterm. Se a máquina remota não suportar isso, tentevt100.

Execute o stty -a para verificar o que o kernel acha que são as dimensões do terminal. Se estiverem incorretos, eles podem ser alterados executando stty rowsRRcolsCC.

Alternativamente, se a máquina do cliente tiver o x11/xterm instalado, a execução do resize consultará o terminal para as dimensões corretas e as definirá.

O sintoma: há um longo atraso entre o momento em que a conexão TCP é estabelecida e a hora em que o software cliente solicita uma senha (ou, no caso do telnet(1), quando um prompt de login aparece).

O problema: mais provável do que não, o atraso é causado pelo software do servidor tentando resolver o endereço IP do cliente em um nome de host. Muitos servidores, incluindo os servidores Telnet e SSH que vêm com o FreeBSD, fazem isso para armazenar o nome do host em um arquivo de log para referência futura pelo administrador.

A solução: se o problema ocorrer sempre, independente do servidor ao que o computador cliente se conecta, o problema está no cliente. Se o problema ocorrer apenas quando o computador cliente se conecta a um determinado servidor, o problema está no servidor.

Se o problema for com o cliente, a única solução é corrigir o DNS para que o servidor possa resolvê-lo. Se isso estiver ocorrendo em uma rede local, considere um problema no servidor e continue lendo. Se isso estiver ocorrendo na Internet, entre em contato com seu ISP.

Se o problema for com um servidor em uma rede local, configure o servidor para resolver as consultas de endereço para nome de host para o intervalo de endereços da rede local. Veja as páginas de manual para o hosts(5) e o named(8) para maiores informações. Se o problema for com um servidor na Internet, o problema pode ser que o resolver local do servidor não está funcionando corretamente. Para verificar se é isto, tente procurar outro host, como www.yahoo.com. Se isso não funcionar, este é o problema.

Após uma nova instalação do FreeBSD, também é possível que as informações do domínio e do servidor de nomes estejam faltando no /etc/resolv.conf. Isso geralmente causará um atraso no SSH, já que a opção UseDNS é definida como yes por padrão no /etc/ssh/sshd_config. Se isso estiver causando o problema, preencha as informações ausentes no arquivo /etc/resolv.conf ou configure a opção UseDNS para no no arquivo sshd_config como uma solução temporária.

Essa mensagem de erro indica que o número de file descriptors disponíveis no sistema esgotaram. Consulte a informação sobre a variável kern.maxfiles na seção Ajustando os Limites do Kernel do Handbook para uma discussão e solução.

O computador tem dois ou mais relógios e o FreeBSD escolheu usar o errado.

Execute o comando dmesg(8) e verifique as linhas que contêm a palavra Timecounter. Aquele com o maior valor de quality é o que o FreeBSD escolheu.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Confirme isso verificando o valor da variável kern.timecounter.hardware no sysctl(3).

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Pode ser um timer ACPI quebrado. A solução mais simples é desabilitar o timer ACPI no arquivo /boot/loader.conf:

debug.acpi.disabled="timer"

Ou a BIOS poderá modificar o relógio TSC - talvez para mudar a velocidade do processador quando estiver funcionando a partir de baterias, ou quando estiver entrando em modo de economia de energia, mas o FreeBSD não tem conhecimento desses ajustes e parece ganhar ou perder tempo.

Neste exemplo, o relógio i8254 também está disponível e pode ser selecionado alterando-se a variável kern.timecounter.hardware do sysctl(3).

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

O computador agora deve começar a manter seu relógio mais preciso.

Para que essa mudança seja executada automaticamente no momento da inicialização, adicione a seguinte linha ao arquivo /etc/sysctl.conf:

kern.timecounter.hardware=i8254

Isso significa que um processo está tentando armazenar em memória RAM a memória do disco (swap), e que o processo foi interrompido depois de tentar sem sucesso acessar o disco por mais de 20 segundos. Isso pode ser causado por blocos defeituosos na unidade de disco, fiação de disco defeituosa, cabos ou qualquer outro hardware relacionado a I/O de disco. Se a própria unidade estiver com problemas, erros de disco aparecerão em /var/log/messages e na saída do comando dmesg. Caso contrário, verifique os cabos e conexões.

O kernel do FreeBSD usa vários locks de recursos para arbitrar a contenção de certos recursos. Quando várias threads do kernel tentam obter vários locks de recursos, há sempre o potencial para um impasse (deadlock), em que duas threads obtiveram cada uma um dos locks e trava para sempre esperando que a outra thread libere um dos outros locks. Esse tipo de problema de locking pode ser evitado se todas as threads obtiverem os locks na mesma ordem.

Um sistema de diagnóstico lock em tempo de execução chamado witness(4), ativado no FreeBSD-CURRENT e desabilitado por padrão para a branch stable e releases, detecta o potencial para deadlocks devido a erros de locking, incluindo erros causados ​​pela obtenção de vários locks de recursos com uma ordem diferente de partes diferentes do kernel. O framework witness(4) tenta detectar esse problema quando ele ocorre e relata isso imprimindo uma mensagem no console do sistema sobre um lock order reversal (geralmente também chamado de LOR).

É possível obter falsos positivos, uma vez que o witness(4) é conservador. Um relatório positivo verdadeiro não significa que um sistema está travado; em vez disso, deve ser entendido como um aviso de que um deadlock poderia ter acontecido.

Isso significa que uma função que pode dormir foi chamada enquanto um lock mutex (ou outro unsleepable) era mantido.

A razão pela qual isso é um erro é porque os mutexes não devem ser mantidos por longos períodos de tempo; eles deveriam existir apenas para manter curtos períodos de sincronização. Este contrato de programação permite que os drivers de dispositivos usem mutexes para sincronizar com o resto do kernel durante as interrupções. As interrupções (no FreeBSD) podem não dormir. Por isso, é imperativo que nenhum subsistema bloqueie o kernel por um longo período mantendo um mutex ativo.

Para capturar tais erros, asserções podem ser adicionadas ao kernel que interage com o subsistema witness(4) para emitir um aviso ou erro fatal (dependendo a configuração do sistema) quando uma chamada potencialmente de bloqueio é feita enquanto um mutex estiver sendo mantido.

Em resumo, tais avisos não são fatais, no entanto, com um timing infeliz, podem causar efeitos indesejáveis, desde um pequeno erro na capacidade de resposta do sistema até o seu travamento completo.

Para obter informações adicionais sobre locking no FreeBSD, consulte locking(9).

Este erro não significa que o utilitário touch(1) esteja ausente. O erro é provavelmente devido às datas dos arquivos que estão sendo definidos em algum momento no futuro. Se o relógio do CMOS estiver configurado para a hora local, execute adjkerntz -i para ajustar o relógio do kernel ao inicializar no modo de usuário único.

Consulte a página de ports para informações sobre os pacotes de software portados para o FreeBSD. A lista atualmente tem 24.000 aplicativos e está crescendo diariamente, então volte sempre para conferir ou assine a lista de discussão de anúncios do FreeBSD para atualizações periódicas com as novidades.

A maioria dos ports deve funcionar em todas as versões suportadas do FreeBSD. Aqueles que não funcionam, estão especificamente sinalizados como tal. Cada vez que uma release do FreeBSD é construida, um snapshot da coleção de ports no momento da construção também é incluída no diretório ports/.

O FreeBSD suporta pacotes binários compactados para facilitar a instalação e desinstalação dos ports. Use o comando pkg(7) para controlar a instalação de pacotes.

Qualquer um dos métodos listados aqui funciona:

Sim. Consulte a página web https://www.FreeBSD.org/java/ para mais informações.

Se a versão do FreeBSD instalada estiver significativamente atrás do -CURRENT ou do -STABLE, atualize a coleção de ports usando as instruções disponíveis na seção Usando a coleção de ports. Se o sistema estiver atualizado, alguém pode ter feito uma alteração no port que funciona para -CURRENT mas que quebrou o port para o -STABLE. Envie um relatório de bug, já que a Coleção de Ports deve funcionar tanto para o branch -CURRENT e quanto o -STABLE.

Primeiro, certifique-se de que a Coleção de Ports esteja atualizada. Erros que afetam a compilação do INDEX a partir de uma cópia atualizada da coleção de ports são de alta visibilidade e, portanto, quase sempre são corrigidos imediatamente.

Existem casos raros em que o INDEX não será compilado devido a casos estranhos envolvendo a variável OPTIONS_SET sendo definida em make.conf. Se você suspeitar que este é o caso, tente fazer o INDEX com estas variáveis desativadas antes de reportar o erro para a Lista de discussão de ports do FreeBSD.

O FreeBSD não inclui uma ferramenta de atualização de ports, mas possui algumas ferramentas para facilitar o processo de atualização. Ferramentas adicionais estão disponíveis para simplificar o manuseio dos ports e são descritas na seção Atualizando Ports no Handbook do FreeBSD .

Sim! Apesar de um sistema recente ser capaz de executar os softwares compilados em uma versão mais antiga, as coisas irão falhar aleatoriamente e deixar de funcionar quando outros ports forem instalados ou atualizados.

Quando o sistema é atualizado, várias bibliotecas compartilhadas, módulos carregáveis ​​e outras partes do sistema serão substituídas por versões mais recentes. Os aplicativos vinculados às versões mais antigas podem não iniciar ou, em outros casos, não funcionar corretamente.

Para obter maiores informações, consulte a seção sobre atualizações no Handbook do FreeBSD.

Em geral, não. Os desenvolvedores do FreeBSD fazem o máximo para garantir compatibilidade binária em todos os releases com o mesmo número de versão principal. Quaisquer exceções serão documentadas nas Release Notes, e os conselhos dados lá devem ser seguidos.

Muitas pessoas precisam escrever shell scripts que serão portados para muitos sistemas. É por isso que o POSIX® especifica os comandos shell e utilitários em grande detalhe. A maioria dos scripts são escritos em Bourne shell (sh(1)) e porque várias interfaces de programação importantes (make(1), system(3), popen(3) e análogos em linguagens de script de alto nível como Perl e Tcl) são especificados para usar o Bourne shell para interpretar comandos. Como o Bourne shell é usado com tanta frequência e em larga escala, é importante que ele seja iniciado rapidamente, que seja determinístico em seu comportamento e que ocupe o menor espaço possível na memória.

A implementação existente é resultado do nosso melhor esforço para atender simultaneamente o quanto pudermos desses requisitos. Para manter o /bin/sh pequeno, não fornecemos muitos dos recursos de conveniência que os outros shells possuem. É por isso que outras shells com mais recursos, como o bash, o scsh, o tcsh(1), e o zsh estão disponíveis. Compare a utilização de memória desses shells observando as colunas “ VSZ ” e “ RSS ” em uma listagem gerada com o comando ps -u.

Para criar CDs de áudio a partir de arquivos MIDI, primeiro instale o audio/timidity++ a partir dos ports e instale manualmente os patches GUS criados por Eric A. Welsh, disponíveis em http://alleg.sourceforge.net/digmid.html. Depois que o TiMidity++ estiver corretamente instalado, os arquivos MIDI poderão ser convertidos em arquivos WAV com a seguinte linha de comando:

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

Os arquivos WAV podem ser convertidos para outros formatos ou gravados em CDs de áudio, conforme descrito no Handbook do FreeBSD.

De modo nenhum! Confira a seção configuração do kernel do Handbook.

Os kernels GENERIC enviados com o FreeBSD são compilados com o modo de depuração habilitado. Kernels compilados no modo de depuração contêm dados de depuração em arquivos separados que são usados ​​para depuração. Versões do FreeBSD anteriores a 11.0 armazenam esses arquivos de depuração no mesmo diretório que o próprio kernel, /boot/kernel/. No FreeBSD 11.0 e posterior, os arquivos de depuração são armazenados em /usr/lib/debug/boot/kernel/. Observe que haverá pouca ou nenhuma perda de desempenho ao executar um kernel com o modo de depuração habilitado, e é útil manter um por perto em caso de panic no sistema.

Quando estiver com pouco espaço em disco, existem diferentes opções para reduzir o tamanho de /boot/kernel/ e /usr/lib/debug/.

Para não instalar os arquivos de símbolos, certifique-se que a seguinte linha existe em /etc/src.conf:

WITHOUT_KERNEL_SYMBOLS=yes

Para mais informações veja src.conf(5).

Se você quiser evitar completamente a criação de arquivos de depuração, certifique-se de que ambos os itens a seguir sejam verdadeiros:

Qualquer uma das configurações acima fará com que o kernel seja construído com suporte ao modo de depuração.

Para construir e instalar somente os módulos desejados, liste-os em /etc/make.conf:

MODULES_OVERRIDE= accf_http ipfw

Substitua accf_httpd ipfw com a lista dos módulos que precisa. Apenas os módulos listados serão compilados. Isso reduz o tamanho do diretório do kernel e diminui o tempo necessário para compilar o kernel. Para mais informações, leia /usr/share/examples/etc/make.conf.

Dispositivos desnecessários podem ser removidos do kernel para reduzir ainda mais o tamanho. Veja P: 7.1 para mais informações.

Para colocar qualquer uma dessas opções em vigor, siga as instruções para compilar e instalar um novo kernel.

Para referência, o kernel amd64 do FreeBSD 11 (/boot/kernel/kernel) é de aproximadamente 25 MB.

Há várias causas possíveis para esse problema:

O nome do agendador que atualmente sendo usado está diretamente disponível como o valor da variavel kern.sched.name do sysctl:

% sysctl kern.sched.name
kern.sched.name: ULE

A variável kern.sched.quantum define o número máximo de pulsos que um processo pode executar sem ser "preempted" no scheduler 4BSD.

Veja a seção Adicionando Discos no Handbook do FreeBSD.

A melhor maneira é reinstalar o sistema operacional no novo disco e depois passar os dados do usuário. Isto é altamente recomendado ao seguir o -STABLE por mais de uma release ou ao atualizar uma release ao invés de instalar uma nova. Instale o booteasy em ambos os discos com boot0cfg(8) e use a opção de dual boot até que esteja satisfeito com a nova configuração. Pule o próximo parágrafo para descobrir como mover os dados depois de fazer isso.

Alternativamente, particione e rotule o novo disco utilizando o sade(8) ou o gpart(8). Se os discos forem formatados com MBR, o booteasy pode ser instalado em ambos os discos utilizando-se o boot0cfg(8) para que o computador possa inicializar dualmente com o antigo ou novo sistema após a conclusão da cópia.

Depois que o novo disco estiver configurado, os dados não podem ser simplesmente copiados. Em vez disso, use ferramentas que entendam device files e system flags, tais como o dump(8). Embora seja recomendado que você mova os dados com o sistema em modo single user, isto não é necessário.

Quando os discos estiverem formatados com UFS, nunca use nada além do dump(8) e do restore(8) para mover o sistema de arquivos raiz. Esses comandos também devem ser usados para mover uma única partição para uma outra partição vazia. A seqüência de etapas para usar o comando dump para mover os dados de uma partição UFS para uma nova partição é:

Por exemplo, para mover /dev/ada1s1a tendo /mnt como o ponto de montagem temporário, digite:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

Reorganizar as partições com o comando dump requer um pouco mais de trabalho. Para mesclar uma partição como /var com a partição pai, crie uma nova partição grande o suficiente para conter ambas, mova a partição pai conforme descrito acima e mova a partição filha para o diretório vazio criado pela primeira movimentação:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Para separar um diretório do seu pai, digamos colocar /var em sua própria partição quando não era antes, crie as duas partições, monte a partição filho no diretório apropriado no ponto de montagem temporário e mova a antiga partição única:

# newfs /dev/ada1s1a
# newfs /dev/ada1s1d
# mount /dev/ada1s1a /mnt
# mkdir /mnt/var
# mount /dev/ada1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

Os utilitários cpio(1) e pax(1) também estão disponíveis para mover dados do usuário. Estes comandos são conhecidos por perder as flags com as informações dos arquivo, portanto, use-os com cuidado.

Resposta curta: Soft Updates geralmente podem ser usados ​​com segurança em todas as partições.

Resposta longa: o Soft Updates possui duas características que podem ser indesejáveis ​​em determinadas partições. Primeiro, uma partição com Soft Updates tem uma pequena chance de perder dados durante uma falha do sistema. A partição não será corrompida, pois os dados serão simplesmente perdidos. Em segundo lugar, o uso de Soft Updates pode causar escassez temporária de espaço.

Ao usar o Soft Updates, o kernel pode levar até trinta segundos para gravar alterações no disco físico. Quando um arquivo grande é excluído, o arquivo ainda reside no disco até que o kernel execute a exclusão. Isso pode causar uma "race condition" muito simples. Suponha que um arquivo grande seja excluído e outro arquivo grande seja criado imediatamente. O primeiro arquivo grande ainda não foi removido do disco físico, portanto, o disco pode não ter espaço suficiente para o segundo arquivo grande. Isso produzirá um erro de que a partição não tem espaço suficiente, mesmo que um grande espaço tenha acabado de ser liberado. Alguns segundos depois, a criação do arquivo funciona conforme o esperado.

Se um sistema travar depois que o kernel tiver aceito um bloco de dados para gravar no disco, mas antes que os dados sejam realmente gravados, os dados poderão ser perdidos. Esse risco é extremamente pequeno, e geralmente gerenciável.

Esses problemas afetam todas as partições usando as Soft Updates. Então, o que isso significa para a partição raiz?

Informações vitais sobre a partição raiz mudam muito raramente. Se o sistema travar dentro da janela de 30 segundos depois de uma alteração ter sido feita, é possível que os dados possam ser perdidos. Esse risco é insignificante para a maioria dos aplicativos, mas esteja ciente de que existe. Se o seu sistema não puder tolerar este risco, não use as Soft Updates no sistema de arquivos raiz!

O / é tradicionalmente uma das menores partições. Se o /tmp estiver localizado dentro do /, pode haver problemas intermitentes de falta de espaço. A criação de um link simbólico apontando o /tmp para /var/tmp resolverá esse problema.

Por fim, o dump(8) não funciona no modo live (-L) em um sistema de arquivos, com Journaled Soft Updates (SU + J).

O FreeBSD suporta uma variedade de outros sistemas de arquivos.

O FreeBSD inclui o sistema de arquivos de rede NFS e a Coleção de Ports do FreeBSD fornece vários aplicativos FUSE para suportar muitos outros sistemas de arquivos.

As partições secundárias do DOS são encontradas depois de todas as partições primárias. Por exemplo, se E for a segunda partição DOS na segunda unidade SCSI, haverá um arquivo de dispositivo para a “slice 5” em /dev. Para montá-lo:

# mount -t msdosfs /dev/da1s5 /dos/e

Sim, o gbde(8) e o geli(8). Consulte a seção Partições de Disco com Criptografia do Handbook do FreeBSD.

Para inicializar o FreeBSD usando o GRUB, adicione o seguinte ao /boot/grub/menu.lst ou ao /boot/grub/grub.conf, dependendo de qual é usado pela sua distribuição Linux ®.

title FreeBSD 9.1
	root (hd0,a)
	kernel /boot/loader

No qual hd0,a aponta para a partição raiz no primeiro disco. Para especificar o número da slice, use algo como isto (hd0,2,a). Por padrão, se o número da slice for omitido, o GRUB pesquisará a primeira slice que tiver a partição a.

Instale o LILO no início da partição de inicialização Linux® em vez de no Master Boot Record. Você poderá então inicializar o LILO a partir do BootEasy.

Isto é recomendado ao executar o Windows® e o Linux®, pois torna mais fácil fazer o Linux® inicializar novamente se o Windows® for reinstalado.

Isso não pode ser feito com o gerenciador de inicialização padrão sem reescrevê-lo. Há vários outros gerenciadores de inicialização na categoria sysutils da coleção de ports.

Se a unidade já tiver um sistema de arquivos, use um comando como este:

# mount -t msdosfs /dev/da0s1 /mnt

Se a unidade só for usada com sistemas FreeBSD, particione-a com UFS ou ZFS. Isso fornecerá suporte a nomes longos de arquivo, melhoria no desempenho e na estabilidade. Se a unidade for usada por outros sistemas operacionais, uma escolha mais portátil, como por exemplo o msdosfs, será mais apropriada.

# dd if=/dev/zero of=/dev/da0 count=2
# gpart create -s GPT /dev/da0
# gpart add -t freebsd-ufs /dev/da0

Finalmente, crie um novo sistema de arquivos:

# newfs /dev/da0p1

e monte-o:

# mount /dev/da0s1 /mnt

É uma boa ideia adicionar uma linha ao /etc/fstab (veja fstab(5)) para que você possa digitar apenas mount /mntno futuro:

/dev/da0p1 /mnt ufs rw,noauto 0 0

O tipo de dispositivo a ser montado deve ser especificado. Isso está descrito no Handbook na seção Usando CDs de Dados.

Isso geralmente significa que não há CD na unidade ou a unidade não está visível no barramento. Consulte a seção Usando CDs de Dados do Handbook para uma discussão detalhada desta questão.

O CD provavelmente usa a extensão “Joliet” para armazenar informações sobre arquivos e diretórios. Isso é discutido na seção Usando CD-ROMs de Dados do Handbook.

Isso significa que um raw file foi gravado no CD, em vez de criar um sistema de arquivos ISO 9660. Dê uma olhada na seção Usando CDs de Dados.

Isso é discutido na seção Handbook sobre como gravar dados em um sistema de arquivos ISO . Para mais informações sobre como trabalhar com CD-ROMs, consulte a Seção Criando CDs no capítulo sobre Armazenamento do Handbook.

Tentar montar um CD de áudio produzirá um erro do tipo cd9660: /dev/cd0: Invalid argument. Isso ocorre porque o comando mount só funciona em sistemas de arquivos. CDs de áudio não possuem sistemas de arquivos; eles têm apenas dados. Em vez disso, use um programa que leia CDs de áudio, como o pacote ou port audio/xmcd.

Por padrão, o mount(8) tentará montar a última trilha de dados (sessão) de um CD. Para carregar uma sessão anterior, use o argumento de linha de comando -s. Consulte mount_cd9660(8) para exemplos específicos.

Como root, defina a variável vfs.usermount do sysctl como 1.

# sysctl vfs.usermount=1

Para tornar o ajuste permanente, adicione a linha vfs.usermount=1 ao arquivo /etc/sysctl.conf para que a variável seja redefinids no momento da inicialização do sistema.

Os usuários só podem montar dispositivos para os quais tenham permissões de leitura. Para permitir que os usuários montem um dispositivo, as permissões devem ser definidas em /etc/devfs.conf.

Por exemplo, para permitir que os usuários montem a primeira unidade USB, adicione:

# Allow all users to mount a USB drive.
	    own       /dev/da0       root:operator
	    perm      /dev/da0       0666

Todos os usuários agora podem montar dispositivos que eles podem ler em um diretório que eles possuem:

% mkdir ~/my-mount-point
% mount -t msdosfs /dev/da0 ~/my-mount-point

Desmontar o dispositivo é simples:

% umount ~/my-mount-point

Ativar a variável vfs.usermount, no entanto, tem implicações negativas de segurança. Uma maneira melhor de acessar uma mídia formatada para o MS-DOS® é usar o pacote emulators/mtools da Coleção de Ports.

Isso se deve ao modo como esses comandos realmente funcionam. O du passa pela árvore de diretórios, ele mede o tamanho de cada arquivo e apresenta os totais. O df apenas pergunta ao sistema de arquivos quanto espaço ainda resta. Eles parecem ser a mesma coisa, mas um arquivo sem uma entrada de diretório afetará df mas não du.

Quando um programa está usando um arquivo e o arquivo é excluído, o arquivo não é realmente removido do sistema de arquivos até que o programa pare de usá-lo. O arquivo é imediatamente excluído da listagem do diretório, no entanto. Como exemplo, considere um arquivo grande o suficiente para afetar a saída de du e df. Um arquivo sendo visualizado com more pode ser excluído sem causar um erro. A entrada é removida do diretório para que nenhum outro programa ou usuário possa acessá-la. No entanto, o du mostra que ele desapareceu, já que percorreu a árvore de diretórios e o arquivo não está mais listado. Já o df mostra que ele ainda está lá, pois o sistema de arquivos sabe que o comando more ainda está usando esse espaço. Quando a sessão do more terminar, o du e df apresentarão o mesmo resultado.

Essa situação é comum em servidores web. Muitas pessoas configuram um servidor web no FreeBSD e esquecem de rotacionar os arquivos de log. O log de acesso enche o /var. O administrador novato exclui o arquivo, mas o sistema ainda reclama que a partição está cheia. Parar e reiniciar o programa do servidor Web liberaria o arquivo, permitindo que o sistema liberasse o espaço em disco. Para evitar que isso aconteça, configure o newsyslog(8).

Observe que o Soft Updates pode atrasar a liberação de espaço em disco e pode levar até 30 segundos para que a alteração fique visível.

Esta seção do Handbook descreve como fazer isso.

Os fabricantes de discos calculam gigabytes como um bilhão de bytes cada, enquanto o FreeBSD os calcula como 1.073.741.824 bytes cada. Isso explica por que, por exemplo, as mensagens de boot do FreeBSD reportarão um disco que supostamente tem 80 GB como contendo 76.319 MB.

Observe também que o FreeBSD irá (por padrão) reservar cerca de 8% do espaço em disco.

Uma parte de cada partição UFS (8%, por padrão) é reservada para uso pelo sistema operacional e pelo usuário root. O df(1) não contabiliza esse espaço ao calcular a coluna Capacity, portanto, ela pode exceder 100%. Observe que a coluna Blocks é sempre maior que a soma das colunas Used e Avail, geralmente por um fator de 8%.

Para mais detalhes, procure prls opção -m em tunefs(8).

É necessário um mínimo de 4 GB de RAM para uso confortável, mas as cargas de trabalho individuais podem variar muito.

O ZIL (log de intenção do ZFS ) é um log de gravação usado para implementar semânticas de compromisso de escrita posix entre travamentos. Normalmente, as gravações são agrupadas em grupos de transações e gravadas no disco quando preenchidas (“Transaction Group Commit ”). No entanto, syscalls como fsync(2) requerem um compromisso de que os dados são gravados no armazenamento estável antes de retornar. O ZIL é necessário para gravações que foram reconhecidas como gravadas, mas que ainda não estão no disco como parte de uma transação. Os grupos de transações contam com registro de data e hora. No caso de uma falha, o último registro de data e hora válido é encontrado e os dados ausentes são mesclados a partir do ZIL.

Por padrão, o ZFS armazena o ZIL no pool com todos os demais dados. Se um aplicativo tiver uma carga de gravação pesada, o armazenamento do ZIL em um dispositivo separado e que tenha um desempenho de gravação sequencial síncrono muito rápido pode melhorar a performance do sistema de uma forma geral. Para outras cargas de trabalho, é improvável que um SSD consiga uma melhoria significativa.

O L2ARC é um cache de leitura armazenado em um dispositivo rápido, como um SSD. Esse cache não é persistente nas reinicializações. Observe que a RAM é usada como a primeira camada de cache e o L2ARC só é necessário se a quantidade de memória RAM for insuficiente.

O L2ARC precisa de espaço no ARC para indexá-lo. Então, perversamente, um conjunto de trabalho que se encaixa perfeitamente no ARC não se encaixará mais perfeitamente se um L2ARC for usado porque parte do ARC estará mantendo o índice L2ARC, empurrando parte do conjunto de trabalho para o L2ARC que é mais lento que a RAM.

De um modo geral, não.

A deduplicação ocupa uma quantidade significativa de RAM e pode tornar mais lento os tempos de acesso ao disco para leitura e gravação. A menos que um esteja armazenando dados muito duplicados, como imagens de máquinas virtuais ou backups de usuários, é possível que a deduplicação faça mais mal do que bem. Outra consideração é a incapacidade de reverter o status da deduplicação. Se os dados forem gravados quando a deduplicação estiver ativada, desabilitar a deduplicação não fará com que os blocos deduplicados sejam replicados até que sejam modificados em novamente.

A deduplicação também pode levar há algumas situações inesperadas. Em particular, a exclusão de arquivos pode se tornar muito mais lenta.

Isso pode acontecer porque o pool está 100% cheio. O ZFS requer espaço no disco para gravar metadados de transação. Para restaurar o pool para um estado utilizável, primeiro faça o truncate do arquivo que irá excluir:

% truncate -s 0 unimportant-file

O truncamento de arquivo funciona porque uma nova transação não é iniciada, novos blocos de reserva são criados.

O suporte ao ZFS TRIM foi adicionado ao FreeBSD 10-CURRENT com revisão r240868. O suporte ao ZFS TRIM foi adicionado a todas as branchs do FreeBSD-STABLE na revisão r252162 e r251419, respectivamente.

O ZFS TRIM é ativado por padrão e pode ser desativado adicionando-se esta linha ao arquivo /etc/sysctl.conf:

vfs.zfs.trim.enabled=0

O arquivo de configuração principal é o /etc/defaults/rc.conf, o qual está descrito em rc.conf(5). Os scripts de inicialização do sistema, tais como /etc/rc e /etc/rc.d, que são descritos em rc(8), incluem este arquivo. Não edite este arquivo! Em vez disso, para editar uma entrada do /etc/default/rc.conf, copie a linha para o arquivo /etc/rc.conf e altere-a lá.

Por exemplo, se para iniciar named(8), o servidor DNS incluído:

# echo 'named_enable="YES"' >> /etc/rc.conf

Para iniciar serviços locais, coloque seus shell scripts no diretório /usr/local/etc/rc.d. Estes shell scripts devem estar definidos como executáveis, o modo de arquivo padrão é 555.

Use o comando adduser ( 8 ), para as situações mais complexas utilize o comando pw ( 8 ).

Para remover o usuário, use o comando rmuser(8) ou, se necessário, o comando pw(8).

Isto normalmente é causado pela edição do crontab do sistema. Esta não é a maneira correta de fazer as coisas, pois o crontab do sistema tem um formato diferente dos crontabs por usuário. O crontab do sistema possui um campo extra, especificando qual usuário irá executar o comando. O cron(8) assume que este usuário é a primeira palavra do comando a ser executado. Como esse comando não existe, essa mensagem de erro é exibida.

Para excluir o crontab extra incorreto:

# crontab -r

Este é um recurso de segurança. Para executar su para root, ou qualquer outra conta com privilégios de superusuário, a conta do usuário deve ser um membro do grupo wheel. Se este recurso não estivesse lá, qualquer pessoa com uma conta em um sistema e que também descobrisse a senha do root seria capaz de obter acesso de nível de superusuário ao sistema.

Para permitir que alguém execute o comando su root , coloque-os no grupo wheel usando o comando pw:

# pw groupmod wheel -m lisa

O exemplo acima adicionará o usuário lisa ao grupo wheel .

Reinicie o sistema usando boot -s no prompt do loader para entrar no modo single user. Quando o sistema solicitar o caminho do shell, apenas pressione Enter e execute mount -urw / para remontar novamente o sistema de arquivos raiz no modo de leitura e gravação. Você também pode precisar executar o comando mount -a -t ufs para montar o sistema de arquivos no qual seu editor favorito é mantido. Se esse editor estiver em um sistema de arquivos de rede, configure a rede manualmente antes de montar os sistemas de arquivos de rede ou use um editor que resida em um sistema de arquivos local, tal como o ed(1).

Para usar um editor de tela inteira, tal como o vi(1) ou emacs(1), execute export TERM=xterm para que esses editores possam carregar os dados corretos do banco de dados do termcap(5).

Depois de executar estas etapas, edite o arquivo /etc/rc.conf para corrigir o erro de sintaxe. A mensagem de erro exibida imediatamente após as mensagens de inicialização do kernel deve indicar o número da linha no arquivo que está com erro.

Consulte a seção sobre impressão no Handbook do FreeBSD para dicas de soluções de problemas.

Consulte a seção usando localização do Handbook, mais especificamente a seção sobre a configuração do console .

Sim, o FreeBSD suporta o IPC no estilo do System V, incluindo memória compartilhada, mensagens e semáforos, no kernel GENERIC. Em um kernel personalizado, o suporte pode ser por meio do carregamento dos módulos de kernel sysvshm.ko, sysvsem.ko e sysvmsg.ko, ou habilitado de forma estática no kernel personalizado adicionando as seguintes linhas ao arquivo de configuração do mesmo:

options    SYSVSHM          # enable shared memory
options    SYSVSEM          # enable for semaphores
options    SYSVMSG          # enable for messaging

Recompile e instale o kernel.

O servidor Sendmail é o software de servidor de email padrão do FreeBSD, mas pode ser substituído por outro MTA instalado a partir da coleção de ports. Os ports disponíveis incluem o mail/exim, o mail/postfix e o mail/qmail. Procure informações nas listas de discussão sobre as vantagens e desvantagens dos MTAs disponíveis.

Não entre em pânico! Reinicie o sistema, digite boot -s no prompt Boot: para entrar no modo single user. Na pergunta sobre o shell a ser usado, pressione Enter, que será exibido um prompt #. Insira o comando mount -urw / para remontar o sistema de arquivos raiz no modo de leitura e gravação e, em seguida, execute o comando mount -a para remontar todos os sistemas de arquivos. Execute o comando passwd root para alterar a senha do usuário root e então execute o comando exit(1) para continuar a inicialização.

Se estiver utilizando o syscons(4) que é o driver padrão de console, compile e instale um novo kernel que contenha esta linha no arquivo de configuração:

options SC_DISABLE_REBOOT

Isto também pode ser feito definindo a variável abaixo do sysctl(8), este processo não requer uma reinicialização ou recompilação do kernel:

# sysctl hw.syscons.kbd_reboot=0

Use este comando perl(1):

% perl -i.bak -npe 's/\r\n/\n/g' file(s)

no qual files(s) trata-se de um ou mais arquivos que desejamos processar. A modificação é feita in-place, o arquivo original é preservado com uma extensão .bak.

Alternativamente, use o tr(1):

% tr -d '\r' < dos-text-file > unix-file

O dos-text-file é o arquivo que contém o texto no formato DOS, enquanto o unix-file contém a saída convertida. Esta opção pode ser um pouco mais rápida do que usar o perl.

Uma outra maneira de reformatar arquivos de texto do DOS é usar o port converters/dosunix da Coleção de Ports. Consulte a sua documentação para maiores detalhes.

Entre no modo single user e retorne ao modo multi usuário:

# shutdown now
# return
# exit

Resposta curta: é apenas um nome. RC significa “Release Candidate”. Isso significa que uma nova release é iminente. No FreeBSD, -PRERELEASE é tipicamente sinônimo do congelamento de código antes de uma release. (Para algumas versões, o rótulo -BETA foi usado da mesma forma que o -PRERELEASE.)

Resposta longa: o FreeBSD deriva suas releases de um de dois lugares. Releases principais (major) ponto-zero, como a 9.0-RELEASE são derivadas a partir do branch principal de desenvolvimento, comumente referida como -CURRENT. Releases secundárias (minor), como a 6.3-RELEASE ou a 5.2-RELEASE, foram snapshots da branch -STABLE ativa. A partir do 4.3-RELEASE, cada release também tem sua própria branch, a qual pode ser seguida por pessoas que exigem uma taxa extremamente conservadora de desenvolvimento (geralmente apenas avisos de segurança).

Quando um release está prestes a ser feito, o branch do qual ele será derivado tem que passar por um determinado processo. Parte desse processo é um congelamento de código. Quando um congelamento de código é iniciado, o nome da branch é alterado para refletir que está prestes a se tornar uma release. Por exemplo, se a ramificação costumava ser chamada de 6.2-STABLE, seu nome será alterado para 6.3-PRERELEASE para indicar o congelamento de código e indicar que testes extras de pré-release devem estar acontecendo. Correções de bugs ainda podem ser adicionadas ao repositório de código fonte para fazer parte da release. Quando o código-fonte estiver estabilizado para a release, o nome será alterado para 6.3-RC para indicar que uma release está prestes a ser feita a partir dele. Uma vez no estágio RC, somente os bugs mais críticos que forem encontrados podem ser corrigidos. Uma vez que o release (6.3-RELEASE neste exemplo) e o branch de release foram feitos, o branch será renomeado para 6.3-STABLE.

Para mais informações sobre números de versão e as várias branches do Subversion, consulte o artigo Release Engineering.

Resposta curta: o nível de segurança é maior que 0. Reinicialize diretamente para o modo de single user para instalar o kernel.

Resposta longa: O FreeBSD não permite alterar os flags do sistema em níveis de segurança superiores a 0. Para verificar o nível de segurança atual:

# sysctl kern.securelevel

O nível de segurança não pode ser diminuído no modo multiusuário, portanto, inicialize no modo single user para instalar o kernel ou altere o nível de segurança em /etc/rc.conf e reinicialize. Veja a página de manual init(8) para detalhes sobre o securelevel, e veja /etc/defaults/rc .conf e a página de manual rc.conf(5) para mais informações sobre o rc.conf .

Resposta curta: o sistema está em um nível de segurança maior que 1. Reinicialize diretamente para o modo de single user para alterar a data.

Resposta longa: O FreeBSD proíbe a alteração do tempo em mais de um segundo em níveis de segurança superiores a 1. Para verificar o nível de segurança:

# sysctl kern.securelevel

O nível de segurança não pode ser diminuído no modo multiusuário. Inicialize no modo single user para alterar a data ou altere o nível de segurança no arquivo /etc/rc.conf e reinicialize. Veja a página de manual init(8) para detalhes sobre o securelevel, e veja /etc/defaults/rc .conf e a página de manual rc.conf(5) para mais informações sobre o rc.conf .

Não, não há vazamento de memória e ele não está usando 256 MB de memória. Por conveniência, o rpc.statd mapeia uma quantidade obscena de memória em seu espaço de endereço. Não há nada terrivelmente errado com isso do ponto de vista técnico; mas isso confunde o top(1) e o ps(1).

O rpc.statd(8) mapeia seu arquivo de status (residente no /var) em seu espaço de endereçamento; para evitar se preocupar com o remapeamento do arquivo de status mais tarde quando ele precisar crescer, ele mapeia o arquivo de status com um tamanho generoso. Isso é muito evidente no código-fonte, onde é possível ver que o argumento length para o mmap(2) é 0x10000000 , ou décima sexta parte do espaço de endereço em um IA32, ou seja, exatamente 256 MB.

O sistema está sendo executado em um nível de segurança maior que 0. Reduza o nível de segurança e tente novamente. Para obter mais informações, consulte a entrada do FAQ referente ao securelevel e a página de manual do init(8).

O vnlru descarrega e libera vnodes quando o sistema atinge o limite de kern.maxvnodes. Essa thread do kernel fica ociosa na maior parte do tempo e só é ativada quando existe uma quantidade enorme de RAM e os usuários estiverem acessando dezenas de milhares de arquivos minúsculos.

As páginas geralmente são gravadas em disco (um tipo de sincronização de VM) quando elas estão no estado inativo, mas as páginas ativas também podem ser sincronizadas. Isso depende do rastreamento da CPU do bit modificado estar disponível e, em determinadas situações pode haver uma vantagem para um bloco de páginas da VM serem sincronizadas, estejam elas ativas ou inativas. Na maioria dos casos comuns, é melhor pensar na fila inativa como uma fila de páginas relativamente não usadas que podem ou não estar no processo de serem gravadas no disco. As páginas em cache já estão sincronizadas, não mapeadas, mas disponíveis para uso imediato do processo com sua associação antiga ou com uma nova associação. As páginas livres estão disponíveis no nível de interrupção, mas as páginas em cache ou livres podem ser usadas no estado do processo para reutilização. As páginas de cache não estão adequadamente bloqueadas para estarem disponíveis no nível de interrupção.

Existem alguns outros flags (por exemplo, flag de ocupado ou de contagem ocupada) que podem modificar algumas das regras descritas.

Existem alguns tipos de “memória livre”. Um tipo é a quantidade de memória imediatamente disponível sem fazer a paginação de mais nada para a VM. Isso é aproximadamente o tamanho da fila de cache + tamanho da fila livre (com um fator de redução de capacidade, dependendo do ajuste do sistema). Outro tipo de “memória livre” é a quantidade total de espaço VM. Isto pode ser complexo, mas depende da quantidade de espaço de swap e memória. Outros tipos de descrições de “memória livre” também são possíveis, mas é relativamente inútil defini-los, mas por outro lado é importante certificar-se de que a taxa de paginação está mantida baixa para evitar a falta de espaço de swap.

O /var/empty é um diretório que o programa sshd(8) utiliza ao executar a separação de privilégios. O diretório /var/empty está vazio, pertence ao usuário root e possui as flags schg definidas. Este diretório não deve ser excluído.

Para ver o que newsyslog(8) vai fazer, use o seguinte:

% newsyslog -nrvv

Use o tzsetup(8).

O sistema de janelas X (comumente chamado de X11) é o sistema de janelas mais amplamente disponível capaz de executar em Sistemas UNIX® e sistemas UNIX®-Like, incluindo o FreeBSD. A Fundação X.Org administra os padrões de protocolo X, sendo que a implementação de referência atual é a versão 11 release 7.7, então as referências são frequentemente encurtadas para X11.

Muitas implementações estão disponíveis para diferentes arquiteturas e sistemas operacionais. Uma implementação do código do lado do servidor é conhecida como um Servidor X.

Para instalar o Xorg, siga um destes procedimentos:

Use o meta-port x11/xorg, que constrói e instala todos os componentes do Xorg.

Use x11/xorg-minimal, que constrói e instala apenas os componentes Xorg necessários.

Instale o Xorg a partir de pacotes do FreeBSD:

# pkg install xorg

Após a instalação do Xorg, siga as instruções da seção Configuração X11 do Handbook do FreeBSD.

O sistema provavelmente está sendo executado em um securelevel alto. Não é possível iniciar o X em securelevel alto porque o X requer acesso de ao io(4). Para obter mais informações, consulte a página de manual do init(8).

Existem duas soluções para o problema: definir o securelevel novamente a zero ou executar xdm(1) (ou um gerenciador de exibição alternativo) no momento da inicialização antes que o securelevel seja elevado.

Veja P: 11.10 para mais informações sobre como executar o xdm(1) no momento da inicialização.

Ao usar syscons(4), o driver de console padrão, o FreeBSD pode ser configurado para suportar um ponteiro de mouse em cada tela virtual. Para evitar conflito com o X, o syscons(4) suporta um dispositivo virtual chamado /dev/sysmouse. Todos os eventos de mouse recebidos do dispositivo de mouse real são gravados no dispositivo via sysmouse(4) moused (8). Para usar o mouse em um ou mais consoles virtuais, e usar X, veja P: 4.4.1 e configure o moused(8).

Em seguida, edite o arquivo /etc/X11/xorg.conf e verifique se as seguintes linhas existem:

Section "InputDevice"
   Option          "Protocol" "SysMouse"
   Option          "Device" "/dev/sysmouse"
.....

Começando com a versão 7.4 do Xorg, as seções InputDevice no xorg.conf são ignoradas em favor dos dispositivos autodetectados. Para restaurar o comportamento antigo, adicione a seguinte linha à seção ServerLayout ou ServerFlags:

Option "AutoAddDevices" "false"

Algumas pessoas preferem usar o /dev/mouse com o X. Para fazer esse trabalho, /dev/mouse deve estar vinculado a /dev/sysmouse (veja sysmouse(4)) adicionando a seguinte linha ao /etc/devfs.conf (veja devfs.conf(5)):

link    sysmouse    mouse

Este link pode ser criado reiniciando o devfs(5) com o seguinte comando (executado como root ):

# service devfs restart

Sim, se o X estiver configurado para um mouse de 5 botões. Para fazer isso, adicione as linhas Buttons 5 e ZAxisMapping 4 5 na seção “InputDevice” do arquivo /etc/X11/xorg.conf, como visto neste exemplo:

Section "InputDevice"
   Identifier      "Mouse1"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection

O mouse pode ser habilitado no Emacs adicionando estas linhas ao ~/.emacs:

;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

Sim, depois de configurar algumas coisas para que funcione.

Para usar o driver synaptics do Xorg, primeiro remova moused_enable do rc.conf .

Para habilitar a synaptics, adicione a seguinte linha ao /boot/loader.conf :

hw.psm.synaptics_support="1"

Adicione o seguinte ao /etc/X11/xorg.conf :

Section "InputDevice"
Identifier  "Touchpad0"
Driver      "synaptics"
Option      "Protocol" "psm"
Option      "Device" "/dev/psm0"
EndSection

E não se esqueça de adicionar o seguinte na seção “ ServerLayout ”:

InputDevice    "Touchpad0" "SendCoreEvents"

Por motivos de segurança, a configuração padrão é não permitir que uma máquina abra remotamente uma janela.

Para ativar esse recurso, inicie o X com o argumento opcional -listen_tcp :

% startx -listen_tcp

Os consoles virtuais fornecem várias sessões simultâneas na mesma máquina sem fazer nada complicado, como configurar uma rede ou executar o X.

Quando o sistema iniciar, ele exibirá um prompt de login no monitor depois de exibir todas as mensagens de inicialização. Digite seu nome de login e senha para começar a trabalhar no primeiro console virtual.

Para iniciar outra sessão, talvez para examinar a documentação de um programa ou para ler mensagens enquanto aguarda a conclusão de uma transferência por FTP, pressione Alt e pressione F2. Isso exibirá o prompt de login do segundo console virtual. Para voltar à sessão original, pressione Alt+F1.

A instalação padrão do FreeBSD possui oito consoles virtuais habilitados. A combinação de teclas Alt + F1 , Alt + F2 , Alt + F3 , e assim por diante alternará entre esses consoles virtuais.

Para habilitar mais consoles virtuais, edite /etc/ttys (veja ttys(5)) e adicione entradas do ttyv8 até o ttyvc , após os comentários na seção “Virtual terminals”:

# Edit the existing entry for ttyv8 in /etc/ttys and change
# "off" to "on".
ttyv8   "/usr/libexec/getty Pc"         xterm  on secure
ttyv9   "/usr/libexec/getty Pc"         xterm  on secure
ttyva   "/usr/libexec/getty Pc"         xterm  on secure
ttyvb   "/usr/libexec/getty Pc"         xterm  on secure

Quanto mais terminais virtuais estiverem ativos, mais recursos serão usados. Isso pode ser um problema em sistemas com 8 MB de RAM ou menos. Considere mudar a opção secure para insecure.

Por exemplo, para executar o X e onze consoles virtuais, a configuração para o terminal virtual 12 deve ser:

ttyvb   "/usr/libexec/getty Pc"         xterm  off secure

A maneira mais fácil de ativar os consoles virtuais é reinicializar.

Utilize Ctrl+Alt+Fn para voltar a um console virtual. Pressione Ctrl + Alt + F1 para retornar ao primeiro console virtual.

Uma vez em um console de texto, use Alt + F n para mover-se entre eles.

Para retornar à sessão X, mude para o console virtual que está executando o X. Se o X foi iniciado a partir da linha de comando usando startx , a sessão X será anexada ao próximo console virtual não utilizado, e não ao console de texto no qual foi invocado. Para oito terminais virtuais ativos, o X será executado no nono, portanto use Alt + F9 .

Existem duas escolas de pensamento sobre como iniciar o xdm(1). Uma escola inicia o xdm a partir do /etc/ttys (veja ttys(5)) usando o exemplo fornecido, enquanto o outro executa o xdm a partir do rc.local (veja rc(8)) ou de um script X localizado em /usr/local/etc/rc.d. Ambos são igualmente válidos, e um pode funcionar em situações em que o outro não funciona. Em ambos os casos, o resultado é o mesmo: O X mostrará um prompt de login gráfico.

O método ttys(5) tem a vantagem de documentar qual vty X iniciará e passando a responsabilidade de reiniciar o servidor X no logout para o init(8). O método rc(8) facilita o kill xdm se houver um problema ao iniciar o servidor X.

Se carregado pelo rc(8), o xdm deve ser iniciado sem nenhum argumento. xdm deve iniciar após o getty(8) ser executado, ou então getty e xdm entrarão em conflito, bloqueando o console. A melhor maneira de contornar isso é fazer com que o script espere 10 segundos ou mais e, em seguida, iniciar o xdm.

Ao iniciar o xdm pelo /etc/ttys, ainda há uma chance de conflito entre xdm e getty(8). Uma maneira de evitar isso é adicionar o número vt no arquivo /usr/local/lib/X11/xdm/Xservers:

:0 local /usr/local/bin/X vt4

O exemplo acima irá direcionar o servidor X para ser executado em /dev/ttyv3. Observe que o número é compensado por um. O servidor X conta a vty a partir de 1, enquanto o kernel do FreeBSD numera a vty a partir de zero.

Quando o X é iniciado com o comando startx, as permissões em /dev/console não serão alteradas, o que resultará um comportamento errático de algumas coisas tais como o não funcionamento do xterm -C e do xconsole.

Isso ocorre devido à maneira como as permissões do console são definidas por padrão. Em um sistema multiusuário, não é necessário que qualquer usuário possa escrever no console do sistema. Para os usuários que estão logando diretamente em uma máquina com um VTY, existe o arquivo fbtab() para resolver tais problemas.

Em poucas palavras, certifique-se de que uma linha não comentada do formulário esteja no /etc/fbtab (veja fbtab(5)):

/dev/ttyv0 0600 /dev/console

Ele irá garantir que quem fizer o login em /dev/ttyv0 será o dono do console.

O mouse e o driver do mouse podem estar fora de sincronização. Em casos raros, o driver também pode relatar erroneamente erros de sincronização:

psmintr: out of sync (xxxx != yyyy)

Se isso acontecer, desative o código de verificação de sincronização definindo as flags de driver para o driver de mouse PS/2 como 0x100. Isto pode ser mais facilmente alcançado adicionando hint.psm.0.flags="0x100" ao arquivo /boot/loader.conf e reiniciando.

Digite xmodmap -e "pointer = 3 2 1". Adicione este comando ao ~/.xinitrc ou ~/.xsession para que isso aconteça automaticamente.

A resposta detalhada para essa pergunta pode ser encontrada na seção Telas de inicialização do tempo de inicialização do FreeBSD Handbook.

Sim. Use o xmodmap(1) para definir quais funções as teclas devem executar.

Supondo que todos os teclados Windows sigam um padrão, os códigos de teclas para essas três teclas são os seguintes:

Para que a tecla Windows da esquerda imprima uma vírgula, tente isto.

# xmodmap -e "keycode 115 = comma"

Para que os mapeamentos de teclas Windows sejam ativados automaticamente toda vez que X for iniciado, coloque os comandos xmodmap em ~/.xinitrc ou, preferencialmente, crie um ~/.xmodmaprc e inclua as opções xmodmap, uma por linha, e adicione a seguinte linha ao ~/.xinitrc:

xmodmap $HOME/.xmodmaprc

Por exemplo, para mapear as 3 chaves para serem F13, F14 e F15, respectivamente. Isso facilitaria mapeá-los para funções úteis em aplicativos ou no gerenciador de janelas.

Para fazer isto, coloque o seguinte em ~/.xmodmaprc.

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

Para o gerenciador da área de trabalho x11-wm/fvwm2, pode-se mapear as chaves para que F13 seja minimizada a janela em que o cursor está ou a maximize, F14 traz a janela em que o cursor está para a frente ou, se já estiver na frente, a coloca em background F15 aparece no menu principal do Workplace mesmo que o cursor não esteja a área de trabalho, o que é útil quando nenhuma parte da área de trabalho está visível.

As seguintes entradas em ~/.fvwmrc implementam a configuração acima mencionada:

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

A disponibilidade da aceleração 3D depende da versão do Xorg e do tipo de chip de vídeo. Para um chip da nVidia, use os drivers binários fornecidos para o FreeBSD instalando um dos seguintes ports:

As versões mais recentes das placas nVidia são suportadas pelo port x11/nvidia-driver .

Drivers mais antigos estão disponíveis como x11/nvidia-driver- ###

A nVidia fornece informações detalhadas sobre qual placa é suportada por qual driver em seu site: http://www.nvidia.com /object/IO_32667.html.

Para a Matrox G200/G400, verifique o port x11-drivers/xf86-video-mga.

Para a ATI Rage 128 e Radeon, consulte ati(4), r128(4) and radeon(4).

“Inicialização sem disco” significa que o sistema FreeBSD é inicializado através de uma rede e lê os arquivos necessários de um servidor ao invés de seu disco rígido. Para maiores detalhes, consulte a entrada do Handbook Inicialização sem disco.

Sim. Consulte a entrada do Manual em rede avançada, especificamente a seção sobre roteamento e gateways.

Normalmente, as pessoas que fazem essa pergunta têm dois PCs em casa, um com o FreeBSD e outro com alguma versão do Windows®, a idéia é usar o sistema FreeBSD para conectar-se à Internet e depois ser capaz de acessar a Internet a partir do sistema Windows® através do sistema FreeBSD. Este é realmente apenas um caso especial da pergunta anterior e funciona perfeitamente bem.

Usuários de rede discada devem usar -nat e definir gateway_enable para YES no arquivo /etc/rc.conf. Para obter mais informações, consulte ppp(8) ou o manual no usuário PPP.

Se a conexão com a Internet for pela Ethernet, use natd(8). Um tutorial pode ser encontrado na seção natd do manual.

Sim. O ppp(8) fornece suporte para conexões de entrada e saída.

Para obter mais informações sobre como usar isso, consulte o capítulo sobre o PPP no Handbook.

Sim. Para obter instruções sobre como usar o NAT em uma conexão PPP, consulte a seção do PPP no manual. Para usar o NAT em algum outro tipo de conexão de rede, consulte a seção natd do manual.

Se o alias estiver na mesma sub-rede que um endereço já configurado na interface, adicione netmask 0xffffffff a este comando:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Caso contrário, especifique o endereço de rede e a máscara de rede como de costume:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Mais informações podem ser encontradas Handbook do FreeBSD.

Algumas versões do código NFS do Linux® aceitam somente solicitações de montagem vindas de uma porta privilegiada; tente executar o seguinte comando:

# mount -o -P linuxbox:/blah /mnt

O problema mais freqüente é não entender o formato correto de /etc/exports. Revise exports(5) e o NFS no manual, especialmente na seção configurando o NFS.

Instale o pacote ou port net/mrouted e adicione mrouted_enable="YES" ao /etc/rc.conf para que o FreeBSD inicie este serviço no momento da inicialização.

Veja a resposta no Handbook do FreeBSD.

Se o kernel é compilado com a opção IPFIREWALL, esteja ciente de que a política padrão é negar todos os pacotes que não são explicitamente permitidos.

Se o firewall foi inadvertidamente configurado de forma errada, restaure a operacionalidade da rede digitando o seguinte comando como root:

# ipfw add 65534 allow all from any to any

Considere configurar a opção firewall_type="open" no /etc/rc.conf.

Para obter mais informações sobre como configurar seu firewall, consulte o Handbook.

Possivelmente porque você precisa utilizar a conversão de endereços de rede (NAT) em vez de apenas encaminhar os pacotes. Uma regra “fwd” apenas encaminha os pacotes, ela não altera os dados dentro do pacote. Considere esta regra:

01000 fwd 10.0.0.1 from any to foo 21

Quando um pacote com um endereço de destino foo chega à máquina com esta regra, o pacote é encaminhado para 10.0.0.1, mas ainda tem o endereço de destino foo. O endereço de destino do pacote não é alterado para 10.0.0.1. A maioria das máquinas provavelmente descartaria um pacote que recebesse com um endereço de destino que não fosse o seu. Portanto, usar uma regra “fwd” geralmente não funciona da maneira esperada pelo usuário. Esse comportamento é um recurso e não um bug.

Veja o FAQ sobre redirecionamento de serviços, o manual do natd(8), ou um dos vários utilitários de redirecionamento de porta na Coleção de Portas para uma maneira correta de fazer isso.

FTP e outras solicitações de serviço podem ser redirecionadas com o pacote ou port sysutils/socket. Substitua a entrada para o serviço em /etc/inetd.conf para chamar socket, conforme visto neste exemplo para ftpd:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

na qual ftp.example.com e ftp são o host e a porta de destino do redirecionamento, respectivamente.

Existem três ferramentas de gerenciamento de largura de banda disponíveis para o FreeBSD. dummynet(4) é integrado ao FreeBSD como parte do ipfw(4). ALTQ foi integrado ao FreeBSD como parte do pf(4). O Bandwidth Manager das Tecnologias Emergentes é um produto comercial.

O aplicativo em execução requer o Packet Filter da Berkeley (bpf(4)), mas ele foi removido de um kernel personalizado. Adicione isto ao arquivo de configuração do kernel e construa um novo kernel:

device bpf        # Berkeley Packet Filter

Use o conjunto de ferramentas SMBFS. Ele inclui um conjunto de modificações do kernel e um conjunto de programas da área de usuário. Os programas e as informações necessárias estão disponíveis como mount_smbfs(8) no sistema base.

Esta mensagem do kernel indica que alguma atividade está provocando o envio de uma grande quantidade de respostas de reset de ICMP ou TCP (RST). As respostas ICMP são frequentemente geradas como resultado de tentativas de conexão a portas UDP não utilizadas. Os resets TCP são geradas como resultado de tentativas de conexão a portas TCP não abertas. Entre outros, esses são os tipos de atividades que podem causar essas mensagens:

O primeiro número na mensagem indica quantos pacotes o kernel teria enviado se o limite não estivesse no lugar e o segundo indica o limite. Este limite é controlado usando net.inet.icmp.icmplim. Este exemplo define o limite para 300 pacotes por segundo:

# sysctl net.inet.icmp.icmplim=300

Para desativar essas mensagens sem desativar a limitação de resposta, use o net.inet.icmp.icmplim_output para desativar a saída:

# sysctl net.inet.icmp.icmplim_output=0

Finalmente, para desabilitar completamente a limitação de resposta, configure net.inet.icmp.icmplim para 0. Desabilitar a limitação de resposta é desencorajado pelos motivos listados acima.

Isso significa que algum dispositivo na Ethernet local está usando um endereço MAC em um formato que o FreeBSD não reconhece. Isso provavelmente é causado por alguém que está experimentando uma placa Ethernet em algum outro lugar da rede. Isso é mais comumente visto em redes de modem a cabo. É inofensivo e não deve afetar o desempenho do sistema FreeBSD.

Porque um pacote está vindo de fora da rede inesperadamente. Para desativá-los, defina net.link.ether.inet.log_arp_wrong_iface como 0.

Configure seu kernel com estas configurações:

include GENERIC
ident GENERIC-IPV6ONLY
makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT="
nooptions INET
nodevice gre

“Sandbox” é um termo de segurança. Isso pode significar duas coisas:

O UNIX® implementa dois sandboxes principais. Um está no nível do processo e o outro está no nível do usuário.

Todo processo UNIX® é completamente protegido contra qualquer outro processo UNIX®. Um processo não pode modificar o espaço de endereço de outro.

Um processo UNIX® é de propriedade de um determinado ID de usuário. Se o ID de usuário não for o usuário root, ele servirá para proteger o processo contra processos pertencentes a outros usuários. O ID do usuário também é usado para proteger os dados no disco.

securelevel é um mecanismo de segurança implementado no kernel. Quando o nível de segurança é positivo, o kernel restringe certas tarefas; nem mesmo o superusuário (root) pode executá-los. O mecanismo de securelevel limita a capacidade de:

Para verificar o status do securelevel em um sistema em execução:

# sysctl -n kern.securelevel

A saída contém o valor atual do nível de segurança. Se for maior que 0, pelo menos algumas das proteções do securelevel são ativadas.

O securelevel de um sistema em execução não pode ser reduzido, pois isso invalidaria seu propósito. Se uma tarefa exigir que o securelevel seja não-positivo, altere as variáveis ​​kern_securelevel e kern_securelevel_enable em /etc/rc.conf e reinicialize.

Para obter mais informações sobre o securelevel e as coisas específicas que todos os níveis fazem, consulte init(8).

O BIND usa uma porta aleatória de numeração alta para consultas de saída. Versões recentes dele escolhem uma nova porta UDP aleatória para cada consulta. Isso pode causar problemas para algumas configurações de rede, especialmente se um firewall bloquear pacotes UDP de entrada em portas específicas. Para passar por esse firewall, tente as opções avoid-v4-udp-ports e avoid-v6-udp-ports para evitar a seleção de números de porta aleatórios dentro de um intervalo bloqueado.

Parabéns, a propósito. É uma boa prática ler a saída sockstat(1) e observar coisas estranhas!

Versões recentes do Sendmail suportam um recurso de envio de mensagens que é executado pela porta 587. Isso ainda não é amplamente suportado, mas está crescendo em popularidade.

Não se preocupe. toor é uma conta de superusuário “alternativa”, onde toor é root soletrada para ao contrário. Ele deve ser usado com um shell não padrão, portanto, o shell padrão para root não precisa ser alterado. Isto é importante porque os shells que não fazem parte da distribuição base, mas que são instalados a partir de ports ou packages, são instalados em /usr/local/bin que, por padrão, reside em um sistema de arquivos diferente . Se o shell do root estiver localizado em /usr/local/bin e o sistema de arquivos contendo /usr/local/bin) não está montado, root não poderá efetuar login para corrigir um problema e terá que reinicializar no modo de usuário único para inserir o caminho para um shell.

Algumas pessoas usam toor para tarefas do dia-a-dia do root com um shell não padrão, deixando o root, com um shell padrão, para o modo de usuário único ou emergências. Por padrão, um usuário não pode logar usando toor porque ele não tem uma senha, então efetue login como root e defina um senha para toor antes de usá-lo para efetuar login.

Primeiro, leia o ppp(8) e o seção sobre PPP do Handbook. Para ajudar na solução de problemas, ative os logs com o seguinte comando:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando pode ser digitado no prompt de comando ppp(8) ou pode ser inserido no início da seção default do arquivo /etc/ppp/ppp.conf. Certifique-se de que o arquivo /etc/syslog.conf contenha as linhas abaixo e de que o arquivo /var/log/ppp.log exista:

!ppp
*.*        /var/log/ppp.log

Muito sobre o que está acontecendo pode ser aprendido no arquivo de log. Não se preocupe se isso não faz sentido, pois pode fazer sentido para outra pessoa.

Geralmente, isso ocorre porque o nome do host não será resolvido. A melhor maneira de corrigir isso é certificar-se de que /etc/hosts seja lido primeiro, garantindo que a linha hosts seja listada primeiro em /etc/host.conf. Em seguida, insira uma entrada em /etc/hosts para a máquina local. Se não houver nenhuma rede local, altere a linha localhost:

127.0.0.1        foo.example.com foo localhost

Caso contrário, adicione outra entrada para o host. Consulte as páginas de manual relevantes para mais detalhes.

Quando terminar, verifique se este comando foi bem sucedido: ping -c1 `hostname`.

Primeiro, verifique se existe uma rota padrão. Este comando deve exibir duas entradas:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Se uma rota padrão não estiver listada, certifique-se de que a linha HISADDR foi adicionada ao /etc/ppp/ppp.conf.

Outro motivo para a falta da linha de rota padrão é que uma rota padrão foi adicionada ao /etc/rc.conf e esta linha está faltando no arquivo /etc/ppp/ppp.conf:

delete ALL

Se esse for o caso, volte para seção Configuração final do sistema no Handbook.

Este erro geralmente ocorre porque a seguinte seção está faltando no arquivo /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Isso é necessário apenas para um endereço IP dinâmico ou quando o endereço do gateway padrão é desconhecido. Ao usar o modo interativo, o seguinte pode ser digitado depois de entrar no modo de pacote. O modo de pacote é indicado pelo PPP em letras maiúsculas no prompt:

delete ALL
add 0 0 HISADDR

Consulte a seção Endereços IP dinâmicos e PPP do manual para mais detalhes.

O tempo limite padrão do PPP é de 3 minutos. Isso pode ser ajustado com a seguinte linha:

set timeout NNN

onde NNN é o número de segundos de inatividade antes que a conexão seja fechada. Se NNN for zero, a conexão nunca será fechada devido a um tempo limite. É possível colocar este comando em ppp.conf, ou digitá-lo no prompt no modo interativo. Também é possível ajustá-lo rapidamente enquanto a linha está ativa conectando-se ao socket de servidor do ppp usando telnet(1) ou pppctl(8). Consulte a página do manual ppp(8) para obter mais detalhes.

Se o relatório de qualidade de link (LQR) estiver configurado, é possível que muitos pacotes LQR sejam perdidos entre o sistema FreeBSD e o peer. ppp(8) deduz que a linha deve ser ruim e desconectada. O LQR vem desativado por padrão e pode ser ativado com a seguinte linha:

enable lqr

Às vezes, em uma linha telefônica barulhenta ou mesmo em uma linha com a chamada em espera ativada, o modem pode desligar porque acha incorretamente que perdeu conexão com a operadora.

Há uma configuração na maioria dos modems para determinar quão tolerante deve ser a perda temporária de conexão com portadora. Consulte o manual do modem para detalhes.

Muitas pessoas experimentam conexões pendentes sem explicação aparente. A primeira coisa a estabelecer é de que lado do link está pendurado.

Ao usar um modem externo, tente usar ping(8) para ver se a luz de TD está piscando quando os dados são transmitidos . Se piscar, mas a luz de RD não, o problema é com a extremidade remota. Se TD não piscar, o problema é local. Com um modem interno, use o comando set server em ppp.conf. Quando o problema ocorrer, conecte-se ao ppp(8) usando pppctl(8). Se a conexão de rede reviver repentinamente devido à atividade no socket de diagnóstico ou se não se conectar, mas o comando set socket for bem-sucedido na inicialização, o problema é local. Se ele puder se conectar, mas as coisas ainda estiverem travadas, ative o log local com set log local async e use ping(8) de outra janela ou terminal para fazer uso do link. O registro assíncrono mostrará os dados sendo transmitidos e recebidos no link. Se os dados estão saindo e não voltando, o problema é remoto.

Tendo estabelecido se o problema é local ou remoto, existem agora duas possibilidades:

Há muito pouco que pode ser feito sobre isso. Muitos ISPs recusam-se a ajudar usuários que não estejam executando um SO da Microsoft®. Adicione enable lqr ao /etc/ppp/ppp.conf, permitindo ppp(8) para detectar a falha remota e desligar. Essa detecção é relativamente lenta e, portanto, não é tão útil.

Primeiro, tente desativar toda a compactação local adicionando o seguinte à configuração:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Em seguida, reconecte para garantir que isso não faz diferença. Se as coisas melhorarem ou se o problema for resolvido completamente, determine qual configuração faz a diferença através de tentativa e erro. Esta é uma boa informação para o ISP, embora possa tornar aparente que não é um sistema Microsoft®.

Antes de entrar em contato com o ISP, ative o registro assíncrono localmente e aguarde até que a conexão seja interrompida novamente. Isso pode usar um pouco de espaço em disco. Os últimos dados lidos da porta podem ser de interesse. Geralmente são dados ASCII e podem até descrever o problema (Memory fault, Core dumped).

Se o ISP for útil, eles devem ser capazes de habilitar o log em sua finalização, então quando o próximo link falhar, eles poderão dizer por que seu lado está tendo um problema.

Nesse caso, reconstrua o ppp(8) com informações de depuração e, em seguida, use gdb(1) para pegar um rastrear uma pilha do processo ppp que está travado. Para reconstruir o utilitário ppp com informações de depuração, digite:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Em seguida, reinicie o ppp e espere até que ele seja interrompido novamente. Quando a compilação de depuração do ppp é interrompida, inicie o gdb no processo travado digitando:

# gdb ppp `pgrep ppp`

No prompt gdb, use os comandos bt ou where para obter um rastreamento de pilha. Salve a saída da sessão gdb e “ desconecte ” do processo em execução, digitando quit .

Ocasionalmente, logo após a conexão, pode haver mensagens no log que digam que Magic é o mesmo. Às vezes, essas mensagens são inofensivas e, às vezes, um lado ou outro termina. A maioria das implementações do PPP não pode sobreviver a esse problema, e mesmo se o link aparecer, haverá solicitações de configuração repetidas e configuração de reconhecimentos no arquivo de log até que o ppp(8) eventualmente desiste e fecha a conexão.

Isso normalmente acontece em máquinas servidor com discos lentos que estão gerando um getty(8) na porta e executando ppp(8) a partir de um script de login ou programa após o login. Houve relatos de que isso acontecia de forma consistente ao usar slirp. A razão é que no tempo entre getty(8) terminar e o ppp(8) iniciar, o cliente ppp(8) inicia o envio de pacotes do protocolo de controle de linha (LCP). Como o ECHO ainda está ligado à porta do servidor, o cliente ppp(8) vê esses pacotes sendo “ refletidos ” de volta.

Uma parte da negociação do LCP é estabelecer um número mágico para cada lado do link para que as “reflexões” possam ser detectadas. O protocolo diz que quando o parceiro tenta negociar o mesmo número mágico, um NAK deve ser enviado e um novo número mágico deve ser escolhido. Durante o período em que a porta do servidor tem o ECHO ligado, o cliente ppp(8) envia pacotes LCP, vê o mesmo numero mágica no pacote refletido e reflete o NAK. Ele também vê a reflexão NAK (que também significa que o ppp(8) deve mudar seu numero magico). Isso produz um número potencialmente enorme de mudanças no número mágico, todas as quais estão se acumulando alegremente no buffer tty do servidor. Assim que ppp(8) é iniciado no servidor, ele é inundado com alterações de numeros mágicos e quase imediatamente decide que tentou o suficiente para negociar LCP e desiste. Enquanto isso, o cliente, que não vê mais as reflexões, fica feliz a tempo de ver um desligamento do servidor.

Isto pode ser evitado permitindo que o par comece a negociar com a seguinte linha em ppp.conf:

set openmode passive

Isto diz ao ppp(8) para esperar que o servidor inicie as negociações do LCP. Alguns servidores, no entanto, nunca podem iniciar negociações. Nesse caso, tente algo como:

set openmode active 3

Isso informa ao ppp(8) para ser passivo por 3 segundos e, em seguida, para iniciar o envio de solicitações de LCP. Se o peer começar a enviar pedidos durante este período, ppp(8) responderá imediatamente, em vez de esperar pelo período completo de 3 segundos.

Há atualmente uma implementação incorreta no ppp(8) onde ele não associa LCP, CCP & Respostas IPCP com seus pedidos originais. Como resultado, se uma implementação de PPP for mais de 6 segundos mais lenta do que o outro lado, o outro lado enviará duas solicitações adicionais de configuração de LCP. Isso é fatal.

Considere duas implementações, A e B. A começa a enviar solicitações LCP imediatamente após a conexão e B leva 7 segundos para iniciar. Quando B é iniciado, A enviou 3 LCP REQs. Estamos supondo que a linha esteja com ECHO desligado, caso contrário, veríamos problemas com números mágicos conforme descrito na seção anterior. B envia um REQ e, em seguida, um ACK para o primeiro dos REQs de A. Isso resulta em A inserindo o estado OPENED e enviando e ACK (o primeiro) de volta para B. Enquanto isso, B envia de volta mais dois ACKs em resposta aos dois REQs adicionais enviados por A antes de B ser iniciado. B recebe o primeiro ACK de A e entra no estado OPENED. A recebe o segundo ACK de B e retorna ao estado de REQ-SENT, enviando outro (adiante) REQ de acordo com o RFC. Em seguida, recebe o terceiro ACK e entra no estado OPENED. Enquanto isso, B recebe o quarto REQ de A, resultando na sua reversão para o estado ACK-SENT e enviando outro (segundo) REQ e (adiante) ACK de acordo com o RFC. A obtém o REQ, entra em REQ-SENT e envia outro REQ. Ele recebe imediatamente o seguinte ACK e insere OPENED.

Isso continua até que um lado conclui que eles estão chegando a lugar nenhum e desiste.

A melhor maneira de evitar isso é configurar um lado para ser passivo - isto é, fazer um lado esperar que o outro comece a negociar. Isso pode ser feito com o seguinte comando:

set openmode passive

Deve ser tomado cuidado com esta opção. Este comando também pode ser usado para limitar a quantidade de tempo que o ppp(8) aguarda que o par inicie as negociações:

set stopped N

Alternativamente, o seguinte comando (onde N é o número de segundos a aguardar antes de iniciar as negociações) pode ser usado:

set openmode active N

Verifique a página de manual para detalhes.

Ao usar shell ou !, ppp(8) executa um shell ou os argumentos passados. O programa ppp aguardará a conclusão do comando antes de continuar. Qualquer tentativa de usar o link PPP durante a execução do comando aparecerá como um link congelado. Isso ocorre porque ppp(8) está aguardando a conclusão do comando.

Para executar comandos como este, use !bg. Isso executará o comando fornecido em segundo plano e ppp(8) pode continuar a fornecer o link.

Não há nenhuma maneira do ppp(8) determinar automaticamente que uma conexão direta foi eliminada. Isso se deve às linhas usadas em um cabo serial de modem nulo. Ao usar esse tipo de conexão, o LQR deve estar sempre ativado com a seguinte linha:

enable lqr

O LQR é aceito por padrão se negociado pelo par.

Se o ppp(8) estiver discando inesperadamente, determine a causa e configure os filtros de discagem para evitar que isso ocorra.

Para determinar a causa, use a seguinte linha:

set log +tcp/ip

Isso registrará todo o tráfego através da conexão. Na próxima vez que a linha conectar inesperadamente, o motivo será registrado e terá um carimbo conveniente com a data e hora ao lado dele.

Em seguida, desative a discagem nessas circunstâncias. Geralmente, esse tipo de problema surge devido a pesquisas de DNS. Para impedir que as pesquisas de DNS estabeleçam uma conexão (isso não impedirá que o ppp(8) passe os pacotes através de um diretório estabelecido) conexão), use o seguinte:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Isso nem sempre é adequado, já que efetivamente quebra os recursos de discagem por demanda. A maioria dos programas precisará de uma pesquisa de DNS antes de fazer qualquer outra coisa relacionada à rede.

No caso do DNS, tente determinar o que realmente está tentando resolver um nome de host. A maior parte do tempo, o Sendmail é o culpado. Certifique-se de configurar o Sendmail para não fazer nenhuma pesquisa de DNS em seu arquivo de configuração. Veja a seção sobre usando e-mail com uma conexão discada no manual do FreeBSD para detalhes. Você também pode adicionar a seguinte linha ao .mc:

define(`confDELIVERY_MODE', `d')dnl

Isso fará com que o Sendmail enfileire tudo até que a fila seja executada, normalmente, a cada 30 minutos, ou até que um sendmail -q seja feito, talvez do /etc/ppp/ppp.linkup.

Eu continuo vendo os seguintes erros no meu arquivo de log:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Isso ocorre porque o ppp(8) está tentando negociar a compactação Predictor1, mas o par não deseja negociar nenhuma compactação. As mensagens são inofensivas, mas podem ser silenciadas desativando a compactação:

disable pred1

Para registrar todas as linhas da conversação do modem, ative o seguinte:

set log +connect

Isso fará com que o ppp(8) registre tudo até a última string “expect” seja solicitada.

Para ver a velocidade de conexão ao usar o PAP ou o CHAP, certifique-se de configurar ppp(8) para esperar toda a linha CONNECT, usando algo assim:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Isso obtém o CONNECT, não envia nada, então espera um avanço de linha, forçando o ppp(8) a ler toda a resposta CONNECT.

O utilitário ppp analisa cada linha em seus arquivos de configuração para que ela possa interpretar corretamente seqüências de caracteres como set phone "123 456 789" e perceber que o número é realmente apenas um argumento . Para especificar um caractere ", escape-o usando uma barra invertida (\).

Quando o interpretador de conversas analisa cada argumento, ele reinterpreta o argumento para encontrar qualquer sequência especiais escapadas, como \P ou \T. Como resultado dessa análise dupla, lembre-se de usar o número correto de escapes.

Para realmente enviar um caractere \ , faça algo como:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Isso resultará na seguinte seqüência:

ATZ
OK
AT\X
OK

Ou:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Isso resultará na seguinte seqüência:

ATZ
OK
ATDT1234567

FCS significa Sequência de Verificação de Quadro. Cada pacote PPP tem uma soma de verificação anexada para garantir que os dados sendo recebidos sejam os dados que estão sendo enviados. Se o FCS de um pacote de entrada estiver incorreto, o pacote será descartado e a contagem HDLC FCS será aumentada. Os valores de erro HDLC podem ser exibidos usando o comando show hdlc.

Se o link for ruim ou se o driver serial estiver descartando pacotes, ele produzirá o erro ocasional de FCS. Isso geralmente não vale a pena se preocupar, embora deixe substancialmente lento os protocolos de compactação.

Se o link congelar assim que se conectar e produzir um grande número de erros de FCS, verifique se o modem não está usando o controle de fluxo de software (XON/XOFF). Se o link precisar usar o controle de fluxo de software, use set accmap 0x000a0000 para informar o ppp(8) para escapar o ^Q e caracteres ^S.

Outra razão para muitos erros de FCS, pode ser que o terminal remoto parou de falar com PPP. Nesse caso, ative o log do async para determinar se os dados recebidos são realmente um login ou prompt de shell. Se for um prompt de shell no final remoto, é possível terminar o ppp(8) sem eliminar a linha usando close lcp seguido de term) para reconectar ao shell na máquina remota.

Se nada no arquivo de log indicar por que o link foi encerrado, pergunte ao administrador remoto ou ISP por que a sessão foi encerrada.

Se tudo mais falhar, envie os detalhes do erro, os arquivos de configuração, como ppp(8) está sendo iniciado, as partes relevantes no arquivo de log , e a saída de netstat -rn, antes e depois de conectar, para a Lista de discussão de questões gerais do FreeBSD.

Há uma lista destas no capítulo Comunicações Seriais do Handbook.

A maioria das placas PCI multi-portas baseadas em 16550 ou nos seus clones são suportadas sem esforço extra.

Alguns cartões clone não-nomeados também são conhecidos por funcionar, especialmente aqueles que afirmam ser compatíveis com AST.

Verifique uart(4) e sio(4) para obter mais informações sobre como configurar esses cartões.

Veja esta seção do Handbook.

Quando o kernel do FreeBSD for inicializado, ele irá sondar as portas seriais para as quais o kernel está configurado. Observe atentamente as mensagens de inicialização ou execute este comando após o sistema estar ativo e em execução:

% grep -E '^(sio|uart)[0-9]' < /var/run/dmesg.boot
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

Este exemplo mostra duas portas seriais. O primeiro está no IRQ4, endereço de porta 0x3f8, e possui um chip UART tipo 16550A. O segundo usa o mesmo tipo de chip, mas está no IRQ3 e está no endereço de porta 0x2f8. As placas de modem internas são tratadas como portas seriais, exceto pelo fato de sempre terem um modem conectado à porta.

O kernel GENERIC inclui suporte para duas portas seriais usando as mesmas configurações de IRQ e endereço de porta no exemplo acima. Se estas configurações não forem adequadas para o sistema, ou se houver mais placas de modem ou portas seriais do que o kernel está configurado, reconfigure usando as instruções em construindo um kernel para mais detalhes.

A terceira porta serial, sio2, ou COM3, está em /dev/cuad2 para dispositivos dial-out e em /dev/ttyd2 para dispositivos dial-in. Qual é a diferença entre essas duas classes de dispositivos?

Ao abrir /dev/ttydX no modo de bloqueio, um processo aguardará o dispositivo cuadX correspondente ficar inativo e, em seguida, aguardar a ativação da linha de detecção. Quando o dispositivo cuadX é aberto, ele garante que a porta serial não esteja em uso pelo dispositivo ttydX. Se a porta estiver disponível, ela a rouba do dispositivo ttydX. Além disso, o dispositivo cuadX não se importa com a detecção da portadora. Com este esquema e um modem de resposta automática, os usuários remotos podem efetuar login e os usuários locais ainda podem discar com o mesmo modem e o sistema cuidará de todos os conflitos.

A seção sobre configuração do kernel fornece informações sobre como configurar o kernel. Para uma placa serial com várias portas, coloque uma linha sio(4) para cada porta serial na placa no device.hints(5). Mas coloque os especificadores de IRQ em apenas uma das entradas. Todas as portas no cartão devem compartilhar um IRQ. Para consistência, use a última porta serial para especificar o IRQ. Além disso, especifique a seguinte opção no arquivo de configuração do kernel:

options COM_MULTIPORT

O exemplo a seguir /boot/device.hints é para uma placa serial AST de 4 portas no IRQ 12:

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

Os flags indicam que a porta principal possui um número menor 7 ( 0x700 ) e todas as portas compartilham um IRQ ( 0x001 ).

Veja a seção Comunicações Seriais no Handbook do FreeBSD .

Consulte a seção sobre Serviços de Discagem no Handbook do FreeBSD.

Esta informação está na seção Terminais do Handbook do FreeBSD.

Os utilitários tip(1) and cu(1) só podem acessar o diretório /var/spool/lock via usuário uucp e grupo dialer . Use o grupo dialer para controlar quem tem acesso ao modem ou sistemas remotos adicionando contas de usuário ao dialer.

Como alternativa, todos podem ser configurados para executar tip(1) e cu(1) digitando:

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip

O FreeBSD irá proativamente mover páginas ociosas e não usadas da memória principal para swap, a fim de disponibilizar mais memória principal para uso ativo. Esse uso pesado de swap é balanceado usando a memória extra livre para armazenamento em cache.

Note que enquanto o FreeBSD é proativo a esse respeito, ele não decide arbitrariamente trocar páginas quando o sistema está realmente inativo. Assim, o sistema não será todo paginado depois de deixá-lo ocioso durante a noite.

A resposta simples é que a memória livre é uma memória desperdiçada. Qualquer memória que os programas não aloquem ativamente é usada pelo kernel do FreeBSD como cache de disco. Os valores mostrados por top(1) rotulados como Inactivo e Laundry são todos os dados armazenados em cache em diferentes níveis de envelhecimento. Esses dados em cache significam que o sistema não precisa acessar um disco lento novamente para os dados que acessou recentemente, aumentando assim o desempenho geral. Em geral, um valor baixo mostrado para a memória Free no top(1) é considerado bom, desde que não seja muito baixo.

Os links simbólicos não têm permissões e, por padrão, chmod(1) seguirá links simbólicos para alterar as permissões no arquivo de origem, se possível. Para o arquivo, foo com um link simbólico chamado bar, este comando será sempre bem-sucedido.

% chmod g-w bar

No entanto, as permissões no arquivo bar não serão alteradas.

Ao alterar os modos das hierarquias de arquivos do usuario root em vez dos próprios arquivos, use -H ou -L junto com -R para este trabalho. Veja chmod(1) e symlink(7) para mais em formação.

% chmod 555 foo/

Sim. Um programa de emulação DOS, emulators/doscmd, está disponível na Coleção de Ports do FreeBSD.

Se o doscmd não for suficiente, o emulators/pcemu emulará um 8088 e serviços de BIOS suficientes para executar muitos aplicativos em modo texto do DOS. Requer o sistema de janelas X.

A coleção de ports também tem o emulators/dosbox. O foco principal deste aplicativo é emular antigos jogos do DOS usando o sistema de arquivos local para os arquivos.

Veja a FAQ de traduções na Documentação do Primer Project do FreeBSD.

O sistema de mensagens do FreeBSD.org implementa algumas verificações do Postfix nos e-mails recebidos e rejeita e-mails que são de retransmissões mal configurados ou que parecem ser spam. Alguns dos requisitos específicos são:

Outros conselhos para ajudar suas mensagens a chegar ao seu destino incluem:

Se você ainda tiver problemas com a infra-estrutura de e-mail no FreeBSD.org, envie uma observação com os detalhes para <postmaster@freebsd.org>; Inclua um intervalo de data/hora para que os registros possam ser revisados ​​-- e observe que apenas mantemos uma semana de registros de e-mail. (Certifique-se de especificar o fuso horário ou o deslocamento de UTC.)

Embora o FreeBSD não forneça acesso aberto a nenhum de seus servidores, outros fornecem sistemas UNIX® de acesso aberto. A taxa varia e serviços limitados podem estar disponíveis.

A Arbornet, Inc , também conhecida como M-Net , oferece acesso livre a sistemas UNIX® desde 1983. Começando num Altos rodando o System III, o site mudou para o BSD/OS em 1991. Em junho de 2000, o site mudou novamente para o FreeBSD. M-Net pode ser acessado via telnet e SSH e fornece acesso básico a todo o pacote de software FreeBSD. No entanto, o acesso à rede é limitado a membros e usuários que doam para o sistema, que é executado como uma organização sem fins lucrativos. O M-Net também oferece um sistema de quadro de avisos e um bate-papo interativo.

Ele não tem um, e é chamado apenas de “o daemon BSD”. Se você insistir em usar um nome, chame-o de “beastie”. Note que “beastie” é pronunciado “BSD”.

Mais informações sobre o daemon BSD estão disponíveis em sua home page.

Possivelmente. O daemon BSD tem copyright de Marshall Kirk McKusick. Verifique sua Declaração sobre o Uso da Figura do Daemon do BSD para termos de uso detalhados.

Em resumo, a imagem pode ser usada com bom gosto, para uso pessoal, desde que seja dado o crédito apropriado. Antes de usar o logotipo comercialmente, entre em contato com Kirk McKusick <mckusick@FreeBSD.org> para obter permissão. Mais detalhes estão disponíveis na Home page do BSD Daemon.

Desenhos Xfig e eps estão disponíveis em /usr/share/examples/BSD_daemon/.

Consulte o Glossário do FreeBSD.

A resposta realmente curta é que você não deveria. A resposta um pouco mais longa é que só porque você é capaz de construir um bikeshed não significa que você deve impedir os outros de construir um só porque você não gosta da cor na qual eles planejam pintá-lo. Esta é uma metáfora indicando que você não precisa discutir sobre cada pequena característica apenas porque você sabe o suficiente para fazê-lo. Algumas pessoas comentaram que a quantidade de ruído gerada por uma mudança é inversamente proporcional à complexidade da mudança.

A resposta mais longa e completa é que depois de uma longa discussão sobre se sleep(1) deve receber argumentos secundários fracionários, Poul-Henning Kamp <phk@FreeBSD.org> publicou uma longa mensagem intitulada “ Um galpão de bicicleta (qualquer cor serve) na grama mais verde... ”As partes apropriadas dessa mensagem são citadas abaixo.

Q. Alguém fez algum teste de temperatura durante a execução do FreeBSD? Eu sei que o Linux® é mais legal que o DOS, mas nunca vi uma menção ao FreeBSD. Parece ser muito rápido.

R. Não, mas fizemos numerosos testes de gostos em voluntários vendados que também receberam 250 microgramas de LSD-25 administrados antecipadamente. 35% dos voluntários disseram que o FreeBSD tinha um gosto de um tipo de laranja, enquanto o Linux® tinha gosto de névoa roxa. Nenhum dos grupos mencionou variações significativas na temperatura. Eventualmente nós tivemos que lançar os resultados desta pesquisa completamente de qualquer maneira quando descobrimos que muitos voluntários estavam vagando fora da sala durante os testes, assim distorcendo os resultados. Nós achamos que a maioria dos voluntários está na Apple agora, trabalhando em sua nova GUI “risca e arrisca”. É um negócio antigo e engraçado em que estamos!

Sério, o FreeBSD usa a instrução HLT (halt) quando o sistema está ocioso, reduzindo assim seu consumo de energia e, portanto, o calor gerado. Além disso, se você tiver ACPI (Configuração Avançada e Interface de Energia) configurado, então o FreeBSD também pode colocar a CPU em um modo de baixa energia.

Q. Existe alguma coisa “estranha” que o FreeBSD faz ao compilar o kernel que faria com que a memória fizesse um som de algo coçando? Ao compilar (e por um breve momento depois de reconhecer o drive de disquete na inicialização também), um estranho som de algo coçando emana do que parecem ser os bancos de memória.

Sim! Você verá referências freqüentes a “daemons” na documentação do BSD, e o que a maioria das pessoas não sabe é que isso se refere a entidades genuínas e não corporais que agora possuem seu computador. O som áspero vindo de sua memória é, na verdade, um sussurro agudo entre os daemons, pois eles decidem como lidar com várias tarefas de administração do sistema.

Se o ruído chegar até você, um bom fdisk/mbr do DOS irá se livrar deles, mas não fique surpreso se eles reagirem negativamente e tentarem pará-lo. Na verdade, se em algum momento durante o exercício você ouvir a voz satânica de Bill Gates vindo do alto-falante embutido, saia correndo e não olhe para trás! Livres da influência contrabalançadora dos daemons BSD, os demônios gêmeos do DOS e Windows® são frequentemente capazes de reafirmar o controle total sobre sua máquina para a danação eterna de sua alma. Agora que você sabe, dada uma escolha, você provavelmente preferiria se acostumar com os ruídos ásperos, não?

Mil, cento e sessenta e nove:

Vinte e três para reclamar com -CURRENT sobre as luzes estarem apagadas;

Quatro para afirmar que trata-se de um problema de configuração e que tais questões realmente pertencem a -questions;

Três para enviar PRs sobre o assunto, uma das quais está arquivada sob doc e consiste apenas da declaração “está escuro”;

Um para cometer uma lâmpada não testada que quebra o buildworld, e depois retorna cinco minutos depois;

Oito para chamar os remetentes de RP por não incluir patches em seus PRs;

Cinco para reclamar sobre o buildworld sendo quebrado;

Trinta e um para responder que funciona para eles, e eles devem ter atualizado em um momento ruim;

Um para postar um patch para uma nova luz para -hackers;

Um para reclamar que ele tinha patches para isso há três anos, mas quando ele os enviou para -CURRENT eles foram ignorados, e ele teve más experiências com o sistema de PRs; além disso, a nova luz proposta não é reflexiva;

Trinta e sete para gritar que essa luz não pertencem ao sistema básico, que os committers não têm o direito de fazer coisas assim sem consultar a Comunidade, e O QUE O -CORE ESTÁ FAZENDO SOBRE ISSO!?

Duzentos para reclamar da cor do bicicletário;

Três para salientar que o patch quebra o style(9);

Dezessete para reclamar que a nova luz proposta está sob a GPL;

Quinhentos e oitenta e seis para iniciar uma guerra contra as vantagens comparativas da GPL, da licença da BSD, da licença do MIT, da NPL e da higiene pessoal dos fundadores da FSF, que não são nomeados;

Sete para mover várias partes do segmento para -chat e -vocacy;

Um para comitar a luz sugerida, mesmo que ela seja mais escura que a antiga;

Dois para recuar com uma chama furiosa de uma mensagem de commit, argumentando que o FreeBSD está melhor no escuro do que com uma lâmpada fraca;

Quarenta e seis para argumentar veementemente sobre o apoio da luz fraca e exigir uma declaração do alto desempenho;

Onze para solicitar uma lâmpada menor para que ela caiba em seu Tamagotchi se decidirmos portar o FreeBSD para essa plataforma;

Setenta e três para reclamar sobre o SNR em -chackers e -chat e cancelar a inscrição em protesto;

Treze para postar “cancelar a inscrição”, “ Como posso cancelar a inscrição? ”, ou “Por favor, remova-me da lista”, seguido do rodapé habitual;

Um para comitar uma lâmpada de trabalho enquanto todos estão ocupados demais chamando a atenção de todos os outros para esse commit;

Trinta e um para salientar que a nova lâmpada iria brilhar 0,364% a mais se compilada com TenDRA (embora tenha que ser reformulada em um cubo), e que o FreeBSD deve, portanto, mudar para TenDRA ao invés de GCC;

Um para reclamar que a nova lâmpada não tem carenagem;

Nove (incluindo os criadores de PRs) para perguntar “o que é o MFC?”;

Cinquenta e sete para se queixar das luzes apagadas duas semanas depois de a lâmpada ter sido trocada.

Nik Clayton< nik@FreeBSD.org > acrescenta:

Eu estava rindo bastante disso.

E então eu pensei, “ Espere, não deveria haver '1 para documentar isso.' nessa lista em algum lugar? ”

E então eu fui iluminado :-)

Thomas Abthorpe < tabthorpe@FreeBSD.org > diz: “ Nenhum, um hacker real do FreeBSD não têm medo do escuro! ”

Ele entra em um coletor de dados especial na CPU, onde é convertido em calor que é ventilado através do conjunto do dissipador de calor / ventilador. É por isso que o resfriamento da CPU é cada vez mais importante; À medida que as pessoas se acostumam com processadores mais rápidos, elas se tornam descuidadas com seus dados e mais e mais delas acabam no /dev/null, superaquecendo suas CPUs. Se você apagar /dev/null (o que efetivamente desativa o dissipador de dados da CPU) sua CPU pode ficar mais fria, mas seu sistema rapidamente ficará constipado com todos esses dados em excesso e começará a se comportar de maneira irregular. Se você tem uma conexão de rede rápida, pode resfriar sua CPU lendo dados de /dev/random e enviá-los para algum lugar; No entanto, você corre o risco de superaquecer sua conexão de rede e / ou irritar seu ISP, pois a maioria dos dados acabará sendo convertida em calor pelo equipamento, mas eles geralmente têm um bom resfriamento, então se você não exagere você deve estar bem.

Paul Robinson acrescenta:

Existem outros métodos. Como todo bom administrador de sistemas sabe, é parte da prática padrão enviar dados para a tela de variedade interessante para manter todos os pixies que compõem sua imagem felizes. Os duendes de tela (comumente com erros de digitação ou renomeados como “pixels”) são categorizados pelo tipo de chapéu que usam (vermelho, verde ou azul) e serão ocultados ou exibidos (mostrando a cor do chapéu ) sempre que recebem um pequeno pedaço de comida. Placas de vídeo transformam dados em comida de duende, e então os enviam para os duendes - quanto mais cara a carta, melhor a comida, então é melhor que os pixies se comportem melhor. Eles também precisam de estímulo constante - é por isso que existem proteções de tela.

Para levar suas sugestões adiante, você poderia simplesmente jogar os dados aleatórios no console, permitindo que os duendes os consumam. Isso faz com que nenhum calor seja produzido, mantém os pixies felizes e se livra de seus dados rapidamente, mesmo que isso faça as coisas parecerem um pouco confusas na sua tela.

Incidentalmente, como um ex-administrador de um grande ISP que teve muitos problemas ao tentar manter uma temperatura estável em uma sala de servidores, eu desencorajaria fortemente as pessoas que enviam os dados que não querem para a rede. As fadas que fazem a troca e o encaminhamento de pacotes também se irritam com isso.

Instale o games/sl e espere ela digitar sl para ls.

Veja o Handbook de Arquitetura do FreeBSD .

Além disso, muito do conhecimento geral sobre o UNIX® é diretamente aplicável ao FreeBSD.

Nós aceitamos todos os tipos de contribuições: documentação, código e até mesmo arte. Veja o artigo Contribuindo com o FreeBSD para obter maiores informações sobre como fazer isso.

E obrigado por considerar nos ajudar!

Atualmente existem 2 branchs ativas/semi-ativas no Repositório de Subversion do FreeBSD. (Os branchs anteriores são alterados apenas muito raramente, e é por isso que existem apenas 2 ramificações ativas de desenvolvimento):

HEAD não é uma tag de branch real. É uma constante simbólica para o fluxo de desenvolvimento atual, não ramificado, conhecido como -CURRENT.

No momento, o -CURRENT é o fluxo de desenvolvimento 13.X; o branch 12-STABLE, stable/12/, derivou do -CURRENT em Dezembro de 2018 e o branch ​​11-STABLE,stable/11/, derivou do -CURRENT em Outubro de 2016.

Aqui está um panic típico do kernel:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Esta mensagem não é suficiente. Embora o valor do ponteiro de instrução seja importante, ele também depende da configuração, pois varia dependendo da imagem do kernel. Se for uma imagem de kernel GENERIC de um dos snapshots, é possível que alguém rastreie a função problemática, mas para um kernel personalizado, somente você pode nos dizer onde a falha ocorreu.

Para prosseguir:

No entanto, a melhor maneira de rastrear a causa de um panic é capturar um despejo de memória e usar o kgdb(1) para gerar um rastreamento de pilha no despejo de memória.

Em qualquer caso, o método é este:

O processo make(1) terá compilado dois kernels. O /usr/obj/usr/src/sys/MYKERNEL/kernel e o /usr/obj/usr/src/sys/MYKERNEL/kernel.debug . O kernel foi instalado como /boot/kernel/kernel, enquanto o kernel.debug pode ser usado como fonte de símbolos de depuração para o kgdb(1).

Para capturar um despejo de memória, edite o /etc/rc.conf e defina o dumpdev para apontar para a partição de swap ou para AUTO. Isso fará com que os scripts rc(8) usem o comando dumpon(8) para ativar os despejos de memória. Este comando também pode ser executado manualmente. Após um panic, o despejo de memória pode ser recuperado usando o savecore(8); se o dumpdev estiver configurado em /etc/rc.conf, os scripts rc(8) executarão o savecore(8) automaticamente e colocarão o despejo de memória em /var/crash.

Depois que o despejo de memória for recuperado, obtenha um rastreamento de pilha da seguinte maneira:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Note que pode haver várias telas de informação valiosa. Idealmente, use script(1) para capturar todas elas. Usar a imagem do kernel unstripped com todos os símbolos de depuração deve mostrar a linha exata do código fonte do kernel onde o panic ocorreu. O rastreamento de pilha geralmente é lido de baixo para cima para rastrear a sequência exata de eventos que levam à falha. O kgdb(1) também pode ser usado para imprimir o conteúdo de várias variáveis ​​ou estruturas para examinar o estado do sistema no momento da falha.

A toolchain ELF não faz, por padrão, os símbolos definidos em um executável visíveis para o vinculador dinâmico. Consequentemente, a busca da função dlsym() por identificadores obtidos de chamadas para dlopen(NULL, flags) não conseguirá encontrar tais símbolos.

Para pesquisar, usando a função dlsym(), os símbolos presentes no executável principal de um processo, vincule o executável usando a opção - export-dynamic ao vinculador ELF (ld(1)).

Por padrão, o espaço de endereço do kernel é de 1 GB (2 GB para PAE) para a arquitetura i386. Se você estiver executando um servidor com uso intensivo de rede ou utilizando o ZFS, isso provavelmente não será suficiente.

Adicione a seguinte linha ao arquivo de configuração do kernel para aumentar o espaço disponível e recompile o kernel:

options KVA_PAGES=N

Para encontrar o valor correto de N, divida o tamanho do espaço de endereço desejado (em megabytes) por quatro. (Por exemplo, é 512 para 2 GB.)