Viable approach could be to omit this for M4 if it's not a simple/quick fix, and then either reimplement for M5 or ship it as an update - or drop it completely.

Target Milestone: --- => Mageia 4
Whiteboard: (none) => MGA3TOO
CC: (none) => doktor5000

Ping?

Was it wrong to directly assign this to tv?

Assignee: thierry.vignaud => bugsquad

FWIW http://gitweb.mageia.org/software/adminpanel/tree/ a module logviewer has been developed and use a journalctl command wrapper, it should be reviewed though to avoid a big amount of data from a query could have impact on system resources.

CC: (none) => anaselli

Currently (with 5alpha2) a warning comes up that syslog-daemon must be installed (or words to that effect - from memory; can't access riseup pad ATM).

So please fix mcc / logdrake to work with journalctl or kindly remove the option to videw the logs.
Alternatively, please show a usage note how journalctl may be called from a console or terminal window.

Whiteboard: MGA3TOO => MGA3TOO; MGA4TOO; 5alpha2
CC: (none) => dvgevers
Target Milestone: Mageia 4 => Mageia 5

@Florian, have tried by any chance manalog? it is not completed yet, the log size is not considered and that could have memory problems, moreover the backend is based on command line wrapping, but you should be able to use journalctl now.

*** Bug 14073 has been marked as a duplicate of this bug. ***

CC: (none) => bjarne.thomsen

(In reply to Angelo Naselli from comment #5)
> @Florian, have tried by any chance manalog? it is not completed yet, the log
> size is not considered and that could have memory problems, moreover the
> backend is based on command line wrapping, but you should be able to use
> journalctl now.

Sorry for the late reply. Thierry changed the subject in between. This bug is _NOT_ about logdrake, but about the log functionality in drakxtools via option menu, which is not working since at least the switch to systemd/journalctl.

Summary: logdrake not working any more - probably since switch to journald => draktools log function not working any more - probably since switch to journald

@doktor5000 in #c7:

Where you say: ...functionality in drakxtools via option menu...
I guess you mean: ... in drakconf via...

Whiteboard: MGA3TOO; MGA4TOO; 5alpha2 => MGA3TOO; MGA4TOO; 5beta1
Source RPM: drakxtools => drakxtools; drakconf

The log function works for me in the MCC. My system is alpha2 updatet to the current state of cauldron.

Apologies for not testing in cauldron.

I still get "while opening "/var/log/explanations" log file: No such file or directory " error. Also the handling of required "syslog-daemon" is partly broken. When selected first, and when it cannot install the package, it will still enable logs in menu. Also it will not recheck if syslog-daemon is installed when "display logs" is enabled.
One needs to disable it, then re-run drakconf to get syslog-daemon installed automatically. Even then, it will show "failed to install syslog-daemon" when installation was successful.

Apart from that, this bug was reported against mga4, Dick changed it to mga5 as milestone.

@Bjarne: Did you install rsyslog or syslog-ng?

rpm -q rsyslog
rsyslog-8.4.2-5.mga5

1) I did not have logging.
2) selected that checkmark in MCC
3) it then asked if i wanted to install rsyslog or syslog-ng, i chose rsyslog
4) it installed, but then said it failed.
5) again in MCC menu I checkmarked logging, and then the log window appeared, saying /var/log/explanations" does not exist.

urpme rsyslog
restoring original journal configuration from /etc/systemd/journald.conf.rsyslog
urpme --auto-orphans
Then I re-installed
urpmi rsyslog
To satisfy dependencies, the following packages are going to be installed:
libestr0
liblogging0
rsyslog
switching on syslog forwarding in: /etc/systemd/journald.conf
and now it works again.
It seems to me that there was some confligt with another package the first time
I tried to install rsyslog. But this was some time ago, and I am not sure.

I have made fresh install of beta1 (i586 and x86_64).
I installed rsyslog from the MCC.
A message told me that the installation failed.
This is actually misleading. The packages were installed correctly.
The problem is that systemd must be restarted for the logging to work.
Note: /etc/systemd/journald.conf has been modified.
This can be done by rebooting the system.

(In reply to Bjarne Thomsen from comment #14)
> I have made fresh install of beta1 (i586 and x86_64).
> I installed rsyslog from the MCC.
> A message told me that the installation failed.
> This is actually misleading. The packages were installed correctly.
> The problem is that systemd must be restarted for the logging to work.
> Note: /etc/systemd/journald.conf has been modified.
> This can be done by rebooting the system.

In the %post scriplet in rsyslogd when it changes the systemd-journald configuration to enable forwarding to rsyslog, it does in fact do "systemctl try-restart systemd-journald" so rebooting should not be necessary.

What is the current status of this bug?  If there is some kind of failure, please post exact output/logs.

CC: (none) => cjw, dirteat

The bug is still present (updated to latest cauldron).
However, the problem is NOT systemd-journald.
It was restarted and running after the installation of rsyslog.
The rsyslog.service was dead, but enabled.
systemctl start rsyslog.service
fixed the problem, but shouldn't the install script restart rsyslog?

Colin, what would you advice for retrieving explanations from journalctl command instead of relying on having rsyslog installed for /var/log/explanations?

(In reply to David Walser from comment #15)
> (In reply to Bjarne Thomsen from comment #14)
> > I have made fresh install of beta1 (i586 and x86_64).
> > I installed rsyslog from the MCC.
> > A message told me that the installation failed.
> > This is actually misleading. The packages were installed correctly.
> > The problem is that systemd must be restarted for the logging to work.
> > Note: /etc/systemd/journald.conf has been modified.
> > This can be done by rebooting the system.
> 
> In the %post scriplet in rsyslogd when it changes the systemd-journald
> configuration to enable forwarding to rsyslog, it does in fact do "systemctl
> try-restart systemd-journald" so rebooting should not be necessary.

FWIW, restarting journald is generally not a good idea. As journal is an integral part of service management, it maintains a list of fds of stdout/err from various services (to capture all output and log it). Restarting journald loses these fds and thus log data.

In newer systemd versions, this is solved by adding an "fd store" facility to PID1 that allows journald to push the fds back to systemd and thus reclaim them on reload. We don't yet have this in our package and IIRC Martin Pitt found an issue with the support for this anyway (not looked to see if it's been resolved now tho' - been a bit busy of late!).

So I'd recomment NOT restarting journal and just suggesting a reboot. Neither are good options, but I'd say a reboot is the least bad.





(In reply to Thierry Vignaud from comment #17)
> Colin, what would you advice for retrieving explanations from journalctl
> command instead of relying on having rsyslog installed for
> /var/log/explanations?


I'm not 100% sure how explanation logging works, but I know mgaapplet logs to it, so I did "journalctl -v /usr/bin/mgaapplet" and got (among others) this message:

Wed 2015-03-18 08:38:43.598101 GMT [s=120eea4762044ad89042ecce515b333d;i=bef2;b=7c3d5ca409584b9bacb51761b6494f15;m=2162c0dbd9;t=5118c02cc71e8;x=cace4a921561459c]
    PRIORITY=6
    _UID=603
    _GID=603
    _CAP_EFFECTIVE=0
    _SYSTEMD_CGROUP=/user.slice/user-603.slice/session-c2.scope
    _SYSTEMD_SESSION=c2
    _SYSTEMD_OWNER_UID=603
    _SYSTEMD_UNIT=session-c2.scope
    _SYSTEMD_SLICE=user-603.slice
    _BOOT_ID=7c3d5ca409584b9bacb51761b6494f15
    _MACHINE_ID=6cb2a4b2bd6df042e57da8a4000001d4
    _HOSTNAME=jimmy
    _TRANSPORT=syslog
    _EXE=/usr/bin/perl5.20.1
    SYSLOG_FACILITY=17
    SYSLOG_IDENTIFIER=mgaapplet
    SYSLOG_PID=5228
    _PID=5228
    _COMM=mgaapplet
    _CMDLINE=/usr/bin/perl /usr/bin/mgaapplet
    MESSAGE=running: MageiaUpdate --no-media-update --no-confirmation --no-splash
    _SOURCE_REALTIME_TIMESTAMP=1426667923598101


I think the key bit here is SYSLOG_FACILITY=17


Running "journalctl SYSLOG_FACILITY=17" gave what looks like good results. Does that look good to you?

(In reply to Colin Guthrie from comment #18)
> (In reply to Thierry Vignaud from comment #17)
> > Colin, what would you advice for retrieving explanations from journalctl
> > command instead of relying on having rsyslog installed for
> > /var/log/explanations?
> 
> I'm not 100% sure how explanation logging works, but I know mgaapplet logs
> to it, so I did "journalctl -v /usr/bin/mgaapplet" and got (among others)
> this message:
[...]
> 
> Running "journalctl SYSLOG_FACILITY=17" gave what looks like good results.
> Does that look good to you?

WDYT about this Thierry? Do you think it will be possible to fix this one for Mageia 5, or should we fix it via an update later on?

CC: (none) => remi

Yes, I'll try to fix it before release.
Though we would need similar commands for regular (standalone) logdrake for auth/messages/... or we could just grep the whole journalctl output

Summary: draktools log function not working any more - probably since switch to journald => drakxtools log function not working any more - probably since switch to journald

(In reply to Thierry Vignaud from comment #20)
> Though we would need similar commands for regular (standalone) logdrake for
> auth/messages/... or we could just grep the whole journalctl output

I'll try to come up with some filters for standalone logdrake, but I think that should go in a separate bug, OK?

(In reply to Thierry Vignaud from comment #20)
> Yes, I'll try to fix it before release.

Did you manage to fix it eventually?

*** Bug 14601 has been marked as a duplicate of this bug. ***

CC: (none) => loginov_alex

In a network install two weeks before mga5 final 64 bit KDE, the log function did not work initially (log window said " /var/log/explanations does not exist", but is working after reboot.

(In reply to Morgan Leijström from comment #24)
> In a network install two weeks before mga5 final 64 bit KDE, the log
> function did not work initially (log window said " /var/log/explanations
> does not exist", but is working after reboot.

Thanks for the test. Looks like it's fixed then.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Hah, it worked 14 months ago yes... 
but it is broken again since some months :/
Both on cauldron fresh installed, and when updated from mga5.

Does it work for you?
I do not even get any output in the terminal from where mcc was started.

Dont we have another bug report on this...?

If we do not, i think we better start a fresh bug than reopening this old one...

Reopening and we'll let maintainers decide if a newer bug report is needed.

Status: RESOLVED => REOPENED
Assignee: bugsquad => mageiatools
Priority: Normal => High
Resolution: FIXED => (none)

Shouldn't the "Options > Show log" menu be entirely removed? I hardly see how this feature is useful.

(In reply to Frédéric Buclin from comment #28)
> Shouldn't the "Options > Show log" menu be entirely removed? I hardly see
> how this feature is useful.

That was the other alternative I mentioned when creating this report. If it was intended to only show the explanations logs from current boot, please change it to show the output of "journalctl -ab-1 SYSLOG_FACILITY=17 --no-pager" or please remove this functionality as it seems obsolete.

Hi,
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.

Test on Mageia 8 RC Live xfce i586 persistence + updates

Enabling it and letting it install packages needed, log function did not work initially (log window said " /var/log/explanations does not exist", but is working after reboot.

(the usefulness of it may be debated... such as it logs it open rpm database but not closing it and not what it do with it.)

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED