• Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages
  • Assigned To
    Erich Eckner
  • Operating System pentium4
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Arch Linux 32
Opened by Peter Tirsek - 24.07.2020
Last edited by Erich Eckner - 27.08.2020

FS#110 - [syslog-ng] is built without systemd support

The packages for syslog-ng since version 3.27.1-1.0 appears to have been built without systemd support. Although their PKGBUILD runs configure with –enable-systemd, running syslog-ng –version shows Enable-Systemd: off. The official Arch x86_64 package (at version 3.28.1-1) doesn’t exhibit this problem.

I tried building the package locally on i686 using the official Arch PKGBUILD and could not reproduce the problem. My locally built version correctly finds libsystemd during configure, and gets built with systemd support. This leads me to believe the problem happens somewhere in the Archlinux32 build process.


The practical upshot of the problem is that the systemd unit file supplied with syslog-ng lists it as a Type=notify service, but when it fails to notify systemd after startup, systemd eventually kills it and restarts it repeatedly:

Jul 24 07:32:31 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
Jul 24 07:32:32 wolfie syslog-ng[18977]: syslog-ng starting up; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: start operation timed out. Terminating.
Jul 24 07:34:01 wolfie syslog-ng[18977]: syslog-ng shutting down; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: Failed with result 'timeout'.
Jul 24 07:34:01 wolfie systemd[1]: Failed to start System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: syslog-ng@default.service: Scheduled restart job, restart counter is at 1.
Jul 24 07:34:02 wolfie systemd[1]: Stopped System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
Closed by  Erich Eckner
27.08.2020 05:49
Reason for closing:  Fixed
Admin
Erich Eckner commented on 31.07.2020 15:46

I confirm, that building with `makepkg` on pentium4 detects libsystemd, also `staging-i686-build` on pentium4 does. Trying `staging-i686-build` on x86_64 host, now.

Admin
Erich Eckner commented on 31.07.2020 15:55

`staging-i686-build` on x86_64 seems to detect libsystemd correctly, too.
Now on to looking, how the PKGBUILD gets modified in the build-scripts …

Admin
Erich Eckner commented on 31.07.2020 16:07

The usual build seems to detect libsystemd, too. Either it's fixed in the meantime or it's an i686-vs-pentium4 thing.

Admin
Erich Eckner commented on 31.07.2020 16:23

the build scripts for pentium4 on x86_64 say:
`checking for libsystemd… yes`
This looks good. Strange.

Admin
Erich Eckner commented on 31.07.2020 18:22

ok, if I run the build-script in a terminal, it works. Probably some interference, when run as a systemd-unit. Version 3.18.1-1.3 for pentium4 is built that way.

Admin
Erich Eckner commented on 31.07.2020 18:25

explanation for outsiders:
Most (all?) build slaves run a systemd unit which runs a shell-script "build-packages" which runs the build command from devtools32 (e.g. staging-pentium4-build). This uses setarch and systemd-nspawn to encapsulate makepkg in a chroot.

Removing the outermost systemd layer fixed the build. Unfortunately, this is not something, we can implement "in production". I think, the real fix would be to repair (or short-circuit) the libsystemd-detection.

Admin
Andreas Baumann commented on 06.08.2020 16:13

unbound shows similar behaviour, failing already in configure:

checking for SYSTEMD... no
checking for SYSTEMD_DAEMON... no
configure: error: systemd enabled but libsystemd not found

This also happens on 64bit indicating a general problem here..

Peter Tirsek commented on 25.08.2020 16:09

I just did a sysupgrade and pacman installed syslog-ng-3.28.1-3.0-i686. This version appears to be built correctly. I'm not sure if you've changed anything with the build system, or if the problem simply went away…

(Speaking of -i686 … I think maybe I ended up selecting pentium4 on this bug, but that was not intentional. I'm on a pentium 3 system, so "plain" i686. I doubt it makes much difference though).

Admin
Andreas Baumann commented on 25.08.2020 19:25

Mmh. Interesting. No, I didn't change anything on the syslog-ng package. So
either there was a change upstream or a change in the build environment
(for instance something systemd-ish) which made it work again?

Peter Tirsek commented on 25.08.2020 21:30

This is the best kind of problems … the one you can ignore for long enough until it just goes away on its own! :-)

Admin
Erich Eckner commented on 27.08.2020 05:49

actually, I don't really like problems, that solve themself but don't make the solution obvious - you can never be sure, whether it resurfaces.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing