• Status Assigned
  • Percent Complete
    0%
  • 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 - 31.07.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...
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..

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing