FS#67545 - [syslog-ng] 3.28.1-2 is missing systemd-syslog() source – does not start

Attached to Project: Arch Linux
Opened by Bachsau (Bachsau) - Monday, 10 August 2020, 14:30 GMT
Last edited by Florian Pritz (bluewind) - Tuesday, 11 August 2020, 18:11 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Florian Pritz (bluewind)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
I have syslog-ng configured to read from systemd's socket. Now, with the latest update, it fails to start, telling me:
"systemd-syslog() source cannot be enabled and it is not functioning. Please compile your syslog-ng with --enable-systemd flag; location='/etc/syslog-ng/syslog-ng.conf:23:17'"

Please re-add the compile flag in question. I don't think there was any good reason to remove it, besides keeping people from running customized configurations. Instead, network-online.target was added to it's service file, which is definitely NOT needed.

Additional info:
* package version: 3.28.1-2
* config files etc.
   syslog-ng.conf (3.7 KiB)
   syslog-ng.service (0.3 KiB)
This task depends upon

Closed by  Florian Pritz (bluewind)
Tuesday, 11 August 2020, 18:11 GMT
Reason for closing:  Fixed
Additional comments about closing:  syslog-ng 3.28.1-3
Comment by Bachsau (Bachsau) - Monday, 10 August 2020, 16:02 GMT
  • Field changed: Percent Complete (100% → 0%)
I do not think this is a duplicate. Completely different reason – also, in my case, it's not a deadlock.
Comment by loqs (loqs) - Monday, 10 August 2020, 16:41 GMT
The --enable-systemd option was never removed from the PKGBUILD. You can verify that in the package's history.
systemd was in the base-devel group until [1]. Without it systemd detection fails but the use of the --enable-systemd does not cause configure to fail.
Adding systemd to makedepends restores systemd support.
The change to syslog-ng@.service is an upstream change [2].

[1] https://github.com/archlinux/svntogit-packages/commit/30853991d2940cfc6c169a306b76c62984ca22be
[2] https://github.com/syslog-ng/syslog-ng/commit/829391628a36947cbfaa9d81ede46bad918f7a8a
Comment by Eli Schwartz (eschwartz) - Monday, 10 August 2020, 16:46 GMT
So more fallout from  FS#66762  I guess?

Which version of syslog-ng did it stop working in, though? EDIT: 3.27.1-1 had systemd in the build chroot.
Comment by David Rosenstrauch (darose) - Monday, 10 August 2020, 18:19 GMT
Not sure if I'm having different symptoms than others, but I only noticed this broken in the most recent upgrade. (syslog-ng-3.28.1-2) After upgrading I noticed that some services' messages were no longer making it into /var/log/messages.log. (Such as those from the folding at home client.) Downgrading back to 3.28.1-1 seemed to fix the issue, though resulted in some other weirdness: I suddenly saw months worth of old (and presumably repeat) log messages getting spooled into the messages.log file again. I don't know enough about systemd & syslog to be able to speculate any further on what the issue(s) might be and/or how to fix.
Comment by Florian Pritz (bluewind) - Monday, 10 August 2020, 21:47 GMT
Please test with syslog-ng 3.28.1-3 from [testing].
Comment by Bachsau (Bachsau) - Monday, 10 August 2020, 22:50 GMT
I'm not familiar enough with Arch packaging to track this down to build-dependencies and such. I just noticed the service failed to start, so I tried to run it from a terminal window, and got the message above. As my configuration is a little different from the default, I thought this might have been intentional because someone thought it's not needed. I also read about the "--enable-systemd" flag on the upstream site and that it needs systemd libs to work, but took this for granted as Arch Linux is build completely around systemd. Now, reading  FS#66762 , this could definitely be the cause of it, and, considering the importance of systemd for Arch, I think it should be re-added to base-devel. As @eschwartz said: "we keep on finding packages that eventually end up being rebuilt in a new chroot and break.". If, as I suspect, the base-devel group is meant to define essential dependencies for any build-environment, changes to it should not be done lightly at all, as such groups are useless if people can't rely on it.

EDIT: Version 3.28.1-3 from testing works fine. Thanks. :)

EDIT#2: @darose It seems that "--enable-systemd" is not only needed for socket connections but all systemd functionality, including reading the journal. However, with the default `system()` source, it falls back to the default sysv-approach then, which just results in missing data, while with my configuration it fails to start, so that I got the chance to notice it immediately after the update.

Loading...