|
Bugzilla – Full Text Bug Listing |
| Summary: | syslog-ng: Unit var-run.mount not found. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | temir <temir> |
| Component: | Basesystem | Assignee: | peter czanik <peter> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P4 - Low | ||
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
(In reply to temir from comment #0) > xmg-core17:/var/log/zypp # systemctl restart syslog-ng > Failed to restart syslog-ng.service: Unit var-run.mount not found. /var/run is gone since a decade or so already? syslog-ng should really be fixed to not use that anymore, but /run instead. Is it perhaps more future-proof to switch to another daemon, such as rsyslog without remote logging? syslog-ng is future proof, it is actively developed. I maintain both the official and unofficial (https://www.syslog-ng.com/community/b/blog/posts/overview-of-syslog-ng-rpm-repositories) syslog-ng packages, from SLES 12 through openSUSE Leap to Tumbleweed. I do not regularly test Tumbleweed, but now updating my local Tumbleweed installation to reproduce your report. My initial guess is, that a compatibility systemd service was removed in Tumbleweed. Hello Peter, it's great that syslog-ng is being further developed. Been using it for over 10 years. Thank you for your update. I'm looking forward to the test results. Best Regards, temir. OK. Found the change in the systemd changelog. So, as I guessed, a recent update removed a compatibility feature. It seems that I need to change parts of the syslog-ng spec file and configurations, which I have never touched before and were created by a previous maintainer. It will need some research and debugging, so I cannot promise a quick fix. ``` * Wed Aug 16 2023 Franck Bui <fbui@suse.com> - Upgrade to v254.1 (commit 208a21833b6953a2517a6c3f8f4849c6664b01be) See https://github.com/openSUSE/systemd/blob/SUSE/v254/NEWS for details. This includes the following bug fixes: - upstream commit 331aa7aa15ee5dd12b369b276f575d521435eb52 (bsc#1203141) - upstream commit 529ba8a1a3968564b67049a077f213e3a0d53070 (bsc#1209340) - upstream commit f1f331a252d22c15f37d03524cce967664358c5c (bsc#1186606) - upstream commit df1dccd25547b430258bd42ec60428fc9aff1370 (bsc#1213185) - upstream commit 000680a68dbdb07d77807868df0b4f978180e4cd (bsc#1211725) * Drop 5001-Revert-core-propagate-stop-too-if-restart-is-issued.patch. A fix for https://github.com/systemd/systemd/issues/26839 has been integrated in v254. * Drop 5002-Revert-core-service-when-resetting-PID-also-reset-kn.patch, it's part of v254. * Drop 0001-restore-var-run-and-var-lock-bind-mount-if-they-aren.patch, it's no more needed these days. * Rebase 0001-conf-parser-introduce-early-drop-ins.patch ``` quick and dirty fix: xmg-core17:/etc/systemd/system # diff -u /usr/lib/systemd/system/syslog-ng.service /etc/systemd/system/syslog-ng.service --- /usr/lib/systemd/system/syslog-ng.service 2023-09-07 23:12:02.000000000 +0200 +++ /etc/systemd/system/syslog-ng.service 2023-09-18 14:10:44.674513011 +0200 @@ -1,8 +1,9 @@ [Unit] Description=System Logging Service -Requires=var-run.mount # Requires=syslog.socket -After=var-run.mount network.target +After=network.target Conflicts=rsyslog.service syslogd.service [Service] The syslog-ng is now running ;-). Regards, temir. Yeah, I came to the same conclusion by looking at the spec file. It uses %_rundir and that points to the /run/ directory. https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#%_rundir My guess is that it was created to maintain SLES 11 compatibility (which was not yet systemd based) and even SLES 12 will keep working, but I have no way to verify it. I'll do some tests, and if it really works as expected, I'll submit the fix today or tomorrow. OK. Tested the fix in my syslog-ng git snapshot repository (https://www.syslog-ng.com/community/b/blog/posts/rpm-packages-from-syslog-ng-git-head/), and it worked without any problems both on Leap 15.4 and Tumbleweed. Next up: also fix the official package. Wow, you're a superman in terms of speed :-). Can you close the bug report when done or do I have to do it? Many thanks! Best Regars, temir. I expected it to take a lot longer, as I thought that I have to rewrite much of the configs and spec file. Luckily it was not the case. I'll close this bug as soon as the fix is accepted to Factory. The fix is now accepted to Factory. Closing. |
Hello all, since the "zypper dup" on September 14, 2023, syslog-ng no longer writes anything to /var/log/messages. xmg-core17:/var/log/zypp # systemctl status syslog ○ syslog-ng.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled; preset: disabled) Active: inactive (dead) TriggeredBy: ○ syslog.socket CPU: 0 xmg-core17:/var/log/zypp # systemctl status syslog-ng ○ syslog-ng.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled; preset: disabled) Active: inactive (dead) TriggeredBy: ○ syslog.socket CPU: 0 xmg-core17:/var/log/zypp # systemctl restart syslog-ng Failed to restart syslog-ng.service: Unit var-run.mount not found. installed: xmg-core17:/var/log/zypp # rpm -qa |grep systemd | sort coreutils-systemd-9.4-1.2.x86_64 grub2-systemd-sleep-plugin-2.12~rc1-2.1.noarch libsystemd0-254.3-1.1.x86_64 libsystemd0-32bit-254.3-1.1.x86_64 systemd-254.3-1.1.x86_64 systemd-32bit-254.3-1.1.x86_64 systemd-boot-254.3-1.1.x86_64 systemd-coredump-254.3-1.1.x86_64 systemd-default-settings-0.7-2.7.noarch systemd-default-settings-branding-openSUSE-0.7-2.7.noarch systemd-devel-254.3-1.1.x86_64 systemd-doc-254.3-1.1.x86_64 systemd-lang-254.3-1.1.noarch systemd-presets-branding-openSUSE-12.2-23.1.noarch systemd-presets-common-SUSE-15-30.1.noarch systemd-rpm-macros-24-1.3.noarch systemd-sysvcompat-254.3-1.1.x86_64 util-linux-systemd-2.39.2-1.1.x86_64 Did I oversleep something or is there a fix coming? Best Regards, temir.