Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#38584 - [libalpm] UseSyslog requires LogFile be openable

Attached to Project: Pacman
Opened by Zachary Cook (Zeik) - Monday, 20 January 2014, 08:01 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 05 February 2014, 18:16 GMT
Task Type Bug Report
Category Backend/Core
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description:

The UseSyslog option in pacman.conf will only function correctly if libalpm can open the logfile specified by the LogFile option.

This prevents using just the syslog/journal for logging and also the use of syslog as a fallback for when logging to LogFile fails.

Looking at the source it seems lib/libalpm/log.c:alpm_logaction returns before sending to syslog in lib/libalpm/util.c:_alpm_logaction, if there was a problem opening handle->logfile.

Additional info:
* package version: 4.1.2-5


Steps to reproduce:
-Uncomment UseSyslog and set LogFile to an empty string: no more syslog output from pacman.
This task depends upon

Comment by Zachary Cook (Zeik) - Wednesday, 05 February 2014, 18:08 GMT
Here's a patch that fixes this behavior, can someone review it? I'm not sure whether the alpm_logaction should return -1 or set errno when the logfile is not able to be opened, but syslog is usable. This patch just avoids that error path when handle->usesyslog is true.
   0001-alpm_logaction-log-to-sy... (0.9 KiB)
Comment by Zachary Cook (Zeik) - Wednesday, 05 February 2014, 18:39 GMT
Updated patch with more explanation, signoff, better subject line.
   0001-alpm_logaction-Unopenabl... (1.1 KiB)
Comment by Zachary Cook (Zeik) - Wednesday, 05 February 2014, 18:45 GMT
Updated patch to mention it fixes this bug.
   0001-alpm_logaction-Unopenabl... (1.1 KiB)
Comment by Zachary Cook (Zeik) - Monday, 10 February 2014, 04:32 GMT
As Bluewind mentioned on irc, LogFile doesn't support an empty string, and it should be an error when LogFile cannot be opened.

I did not test with /dev/null before, and it actually seems to work fine already with UseSyslog, so syslog is supported as a standalone log destination already.

Therefore this bug is a lot less important, as it only causes secondary logging to fail when the primary logging destination fails.

If it is wanted, attached is a patch to make syslog work even with LogFile being invalid/unopenable, but it makes the code a bit more messy.
   0001-alpm_logaction-Log-to-sy... (1.2 KiB)

Loading...