FS#56355 - [syslog-ng] missing /etc/default file for templated service file

Attached to Project: Arch Linux
Opened by Geert Hendrickx (ghen) - Thursday, 16 November 2017, 20:07 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 19 November 2017, 22:34 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Since 3.12.1 upgrade, an existing system with working syslog-ng will no longer work.

Because the systemd unit file is now templated, it requires two actions from the user:

1) create an /etc/default/syslog-ng@default environment file with explicit settings that used to be implicit defaults (this file should be included in the package?)
2) systemctl disable syslog-ng ; systemctl daemon-reload ; systemctl enable syslog-ng@default

The update makes no mention whatsoever and leaves users with a broken system.

See also https://bbs.archlinux.org/viewtopic.php?pid=1749617
This task depends upon

Closed by  Antonio Rojas (arojas)
Sunday, 19 November 2017, 22:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  syslog-ng 3.12.1-5
Comment by Geert Hendrickx (ghen) - Thursday, 16 November 2017, 20:11 GMT
Suggested /etc/default/syslog-ng@default file, based on the upstream template and adjusted for Arch paths:
https://github.com/balabit/syslog-ng/blob/649d1151e79033cc2b81b3353917507266814436/contrib/systemd/syslog-ng%40default

CONFIG_FILE=/etc/syslog-ng/syslog-ng.conf
PERSIST_FILE=/var/lib/syslog-ng/syslog-ng.persist
CONTROL_FILE=/run/syslog-ng.ctl
PID_FILE=/var/run/syslog-ng.pid
OTHER_OPTIONS="--enable-core"
Comment by loqs (loqs) - Thursday, 16 November 2017, 22:06 GMT
/var/run is a symlink to /run so /var/run/syslog-ng.pid can be simplified to /run/syslog-ng.pid
Comment by Eli Schwartz (eschwartz) - Friday, 17 November 2017, 03:13 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (High → Low)
  • Task assigned to Antonio Rojas (arojas)
The upstream build system really should install this file on its own, rather than requiring distros to do so manually. :(
Comment by Jeff Hodd (jghodd) - Friday, 17 November 2017, 18:33 GMT
Thank you, ghen, for opening this bug. None of the new, 3.12.1 service attributes are documented anywhere, so I'm sure there are a huge number of users wondering why their logging no longer works. It's atrocious that neither the /etc/default config file nor the instance name are documented anywhere - not in the man page, not on the archwiki page and not even in the official 3.12 documentation.

At the very least, a default /etc/default config file should be included in any packaging of this version of syslog-ng.

It would be appropriate to immediately add explanations of the /etc/default config file and instance name to the archwiki syslog-ng page.
Comment by Geert Hendrickx (ghen) - Friday, 17 November 2017, 20:19 GMT
Alternatively, we could revert to the traditional unit file, and install the new multi-instance unit just as an example for advanced users?
Comment by Jeff Hodd (jghodd) - Friday, 17 November 2017, 20:52 GMT
That would work. In fact, it does work - I tried it first, but didn't feel that a solution that would be overwritten by the next update would be the correct solution. If that's made the permanent solution, I think that would resolve the issue going forward.
Comment by Jens G (Thah) - Saturday, 18 November 2017, 10:35 GMT
I successfully used ghen's workaround from the forum post with system-ng.service nicked from v3.10.1-2 but am using the infernal template file now, because I wasn't sure all parameters would be set correctly without it. Provided using system-ng.service doesn't break functionality in the near future with upstream I'd have voted for using it and providing the template file as an option, but as the wiki was just updated going the instance way would probably be OK as well.

Additionally and even though one might differ on whether this is an upstream or a packaging issue: As 'The main functionality of the application does not work [...]' (bug reporting guidelines) I don't think 'Low' is an appropriate severity.
Comment by Jeff Hodd (jghodd) - Saturday, 18 November 2017, 17:54 GMT
Thank you for the archwiki update. That helps.
Comment by Jens G (Thah) - Saturday, 18 November 2017, 18:02 GMT
@jghodd: I'm just the messenger, credit goes to Cmorgenstern.

OP: Maybe for packaging it would work to use the old service file for upgrades from pre v3.12, leave it as it is on the system within v3.12.1 upgrades and figure out a way to move to the multiple instance configuration graciously for the next upstream release? Just a thought.
Comment by Jeff Hodd (jghodd) - Saturday, 18 November 2017, 20:15 GMT
@Thah: didn't make any assumptions - was a generic thanks to whoever did it.

I don;t mind if something changes from one package version to the next - I think everyone kinda expects it from time to time - but PLEASE document it (again, a generic shout-out).

Perhaps it would be best to leave the change as is and have the man page updated upstream. If a default template file is included in /etc/default or even just listed out on the man page, as long as it's documented, that would settle the issue, IMO.

Maybe patch a syslog-ng@default.sample file into the /etc/syslog-ng directory... that would be pretty innocuous. Just put a comment at the top of the file that says where the file should go.
Comment by Jeff Hodd (jghodd) - Saturday, 18 November 2017, 22:55 GMT
Thank you for the archwiki update. That helps.
Comment by Geert Hendrickx (ghen) - Sunday, 19 November 2017, 14:11 GMT
CONFIG_FILE=/etc/syslog-ng.conf
refers to an invalid path (on Arch), defaults file must be patched to CONFIG_FILE=/etc/syslog-ng/syslog-ng.conf prior to installation.

Also CONTROL_FILE=/run/syslog-ng.ctl for compatibility with previous default location.
Comment by Florian Pritz (bluewind) - Sunday, 19 November 2017, 14:14 GMT
Also note that /etc/default/syslog-ng@default is not in the backup array yet which may or may not be intentional.

Loading...