web-dev-qa-db-fra.com

enregistrement d'erreur faible sur le disque /var/log/cups/error.log

J'ai installé Lubuntu 16.10 sur mon disque monté en tant que /.

Le problème est que le fichier journal de CUPS (/var/log/cups/error.log) grossit tout le temps jusqu'à ce que je ne dispose plus d'espace libre sur le disque ...

Donc, quand je supprime ce fichier, l'espace sur le disque libéré à nouveau

J'ai déjà essayé:

  • fsck
  • analyseur d'utilisation du disque
  • chaque apt-nettoyage/autocleaning, et la réparation des dépendances.

Comment dois-je procéder?

du -sxh:

9,0G    .

Model: ATA ST3160815AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      32,3kB  50,3GB  50,3GB  primary   ext4            boot
 2      50,3GB  160GB   110GB   extended
 5      50,3GB  158GB   108GB   logical   ext4
 6      158GB   160GB   2136MB  logical   linux-swap(v1)

parted --list && Sudo df -h:

Model: ATA ST3160815AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32,3kB  50,3GB  50,3GB  primary  ext4         boot
 2      50,3GB  160GB   110GB   primary  ext4


Filesystem      Size  Used Avail Use% Mounted on
udev            985M     0  985M   0% /dev
tmpfs           201M  6,3M  195M   4% /run
/dev/sda1        46G   43G  709M  99% /
tmpfs          1003M  188K 1003M   1% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs          1003M     0 1003M   0% /sys/fs/cgroup
tmpfs           201M   36K  201M   1% /run/user/1000
/dev/sda2       101G   60M   96G   1% /media/aram/
disk-usagecups-lpd
5
Aram Martirosyan

J'ai eu le même problème. Les fichiers journaux grandissent très rapidement et après quelques heures, ils occupent tout l’espace disponible dans /. À ce stade, les choses commencent à aller très mal. De plus, le traitement des gobelets encapsule le processeur (100% dans un seul noyau - ce qui explique les 50% que vous voyez dans un traitement double).

Supprimer le fichier à ce stade ne semble pas aider immédiatement. J'imagine que le fichier est toujours utilisé par le processus cups et qu'il ne libère pas l'espace disque ... mais après un redémarrage, j'ai un peu d'espace disque disponible et j'ai eu le temps d'étudier /var/log/cups/error_log.

Voici ce que j'ai trouvé dans les premières lignes

E [16/Oct/2016:09:48:02 +0300] MFCJ625DW: File \"/usr/lib/cups/filter/brother_lpdwrapper_mfcj625dw\" has insecure permissions (0100775/uid=0/gid=0).
E [16/Oct/2016:09:48:02 +0300] MFCJ625DW: Directory \"/usr/lib/cups/filter\" has insecure permissions (040775/uid=0/gid=0).
E [16/Oct/2016:09:48:02 +0300] MFCJ625DW: File \"/usr/lib/cups/filter/brother_lpdwrapper_mfcj625dw\" has insecure permissions (0100775/uid=0/gid=0).
E [16/Oct/2016:09:48:02 +0300] MFCJ625DW: Directory \"/usr/lib/cups/filter\" has insecure permissions (040775/uid=0/gid=0).
E [16/Oct/2016:09:48:03 +0300] Directory \"/usr/lib/cups/notifier\" has insecure permissions (040775/uid=0/gid=0).
W [16/Oct/2016:09:48:03 +0300] Notifier for subscription 1879 (dbus://) went away, retrying!
E [16/Oct/2016:09:48:03 +0300] Directory \"/usr/lib/cups/notifier\" has insecure permissions (040775/uid=0/gid=0).
W [16/Oct/2016:09:48:03 +0300] Notifier for subscription 1879 (dbus://) went away, retrying!
W [16/Oct/2016:09:48:03 +0300] Notifier for subscription 1879 (dbus://) went away, retrying!

Et puis le dernier avertissement est répété encore et encore ... plus de 45 000 fois par seconde! (Pas étonnant que le disque soit rempli après un court laps de temps)

En supposant que vous ayez un problème similaire, notez que le problème auquel les tasses se plaignent est très simple à résoudre:

Directory \"/usr/lib/cups/notifier\" has insecure permissions (040775/uid=0/gid=0).

Une fois que vous avez modifié les autorisations avec Sudo chmod 755 /usr/lib/cups/notifier, le fichier doit cesser de croître. (pendant que vous y êtes, corrigez les autres fichiers dont il se plaint).

3
laugh

Cette commande ne m'aide pas

    Sudo chmod 755 /usr/lib/cups/notifier

parce que je n'ai pas eu de problème de permission comme

    Directory \"/usr/lib/cups/notifier\" has insecure permissions (040775/uid=0/gid=0)

Mon error_log était rempli de lignes comme

    D [21/Aug/2019:15:23:48 +0300] [Client 2249] Read: status=100
    D [21/Aug/2019:15:23:48 +0300] [Client 1232] Read: status=100
    D [21/Aug/2019:15:23:48 +0300] [Client 2249] Read: status=100
    D [21/Aug/2019:15:23:48 +0300] [Client 1232] Read: status=100

Donc, un simple redémarrage a fait l'affaire

    Sudo service cups restart
0
Kira Kondratyeva