Início / user-69099

dayuloli's questions

Martin Hope
dayuloli
Asked: 2024-08-25 03:06:59 +0800 CST
  • 6

Quando executo ls -l /devno meu Ubuntu, recebo uma saída como esta:

$ ls -l /dev
total 0
crw-r--r-- 1 root root     10, 235 Aug 24 16:36 autofs
drwxr-xr-x 2 root root         340 Aug 24 16:40 block
crw------- 1 root root     10, 234 Aug 24 16:36 btrfs-control
drwxr-xr-x 2 root root        2660 Aug 24 16:37 char

A 10, 235quinta coluna mostra os números maiores e menores que especificam qual driver de dispositivo é usado para gerenciar o arquivo.

Quando executo o mesmo comando no macOS, recebo esta saída:

% ls -l /dev
total 1
crw-rw-rw-  1 root       wheel     0x16000000 14 Aug 22:16 aes_0
crw-------  1 root       wheel     0x15000001 14 Aug 22:16 afsc_type5
brw-------  1 root       operator   0x2000000 24 Aug 19:39 apfs-raw-device.2.0
crw-------  1 root       wheel      0xb000001 14 Aug 22:16 auditpipe

Em vez dos números maiores/menores, recebo um único número hexadecimal. Minha pergunta é: o que esses números hexadecimais representam?

O que eu tentei/pesquisei

  1. Existem arquivos diferentes que compartilham o mesmo hexadecimal. Então não parece representar os números maiores/menores, pois, pelo que entendi, essa combinação deveria ser única?

    brw-r-----  1 root       operator   0x1000001 14 Aug 22:16 disk0s1
crw-r-----  1 root       operator   0x1000001 14 Aug 22:16 rdisk0s1

  2. ChatGPT tenta me convencer de que o número hexadecimal é um formato compactado para os números maiores e menores, mas não estava sendo muito claro sobre como interpretá-lo. Se eu dividir os 32 bits em metades e interpretar os primeiros 16 bits como maiores e os últimos 16 bits como menores, o número maior parecerá extraordinariamente grande (por exemplo, 0x1d000000dá 7424como o número maior.

  3. Instalar o coreutilspacote no meu Mac e usá- lslo me deu os familiares pares maiores/menores.

    $ /opt/homebrew/Cellar/coreutils/9.5/libexec/gnubin/ls -l /dev
total 1
crw-rw-rw- 1 root      wheel    22,    0 Aug 14 22:16 aes_0
crw------- 1 root      wheel    21,    1 Aug 14 22:16 afsc_type5
brw------- 1 root      operator  2,    0 Aug 24 21:02 apfs-raw-device.2.0
crw------- 1 root      wheel    11,    1 Aug 14 22:16 auditpipe
...
brw-r----- 1 root      operator  1,    1 Aug 14 22:16 disk0s1
...
crw-r----- 1 root      operator  1,    1 Aug 14 22:16 rdisk0s1
ls
Martin Hope
dayuloli
Asked: 2019-03-24 13:52:31 +0800 CST
  • 3

Eu entendo que systemdarmazena arquivos de unidade em locais diferentes para diferentes versões do Linux. No RHEL, está em /usr/lib/systemd/system/, enquanto em máquinas baseadas em Debian está em /lib/systemd/system/.

No entanto, na minha máquina Ubuntu 18.04, acabei de instalar o Elasticsearch usando um .debarquivo e seu systemdarquivo de unidade foi instalado em /usr/lib/systemd/system/, mas systemdainda é possível pegá-lo.

$ uname -a
Linux nucleolus 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ sudo systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
   Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: http://www.elastic.co

Observe que o caminho é /usr/lib/systemd/system/elasticsearch.service.

Então, por que um systemdarquivo de unidade em /usr/lib/systemd/system/ainda funciona para o Ubuntu? Qual é o caminho real de carregamento do arquivo unitário para sistemas Debian/Ubuntu?

debian ubuntu