M5 upgrade discrepancies

[jiml8]

Today, after allowing some updates to go into place, my graphical desktop screwed up exactly as it had done before, when I first upgraded to M5. Upon investigation, I found that my symlinks /var/run -> /run and /var/lock -> /run/lock had changed back to /var/run -> ../run and /var/lock -> ../run/lock.

Some grepping turns up that this was done to me by /lib/dracut/modules.d/30convertfs/convertfs.sh .

I have altered that script to generate the symlinks the way I need to have them generated. However, I have every reason to expect that this mod will not stick through future updates. How would I change this function so that the mods DO persist?

edit. Actually, I would think the system scripts would be symlinking to an absolute path, as I am doing it, and not to a relative path, as they are doing it. So I am going to call this a bug.

[jiml8]

I have just discovered that rsyslog has been down since I did the upgrade.

It seems that the version of rsyslog provided with Mageia 5 accepts different options than that of the previous Mageia distros, and this means the options set in the file /etc/sysconfig/rsyslog are wrong, but are not corrected by the Mageia 5 installer.

I did not discover this until now because I did the upgrade, then shortly after that left town for several days. I just got back onto this computer (except for remote logins) today.

[jiml8]

A week ago I posted a message describing my experience upgrading to Mageia 5. It got rolled into this viewtopic.php?f=7&t=9890&p=58686#p58686 thread which is a general "experiences" thread.

Subsequently, I have posted a couple of discrepancies I discovered. I do not believe those posts have been noticed because they are in that thread. So I am pointing them out here.

[doktor5000]

Today, after allowing some updates to go into place, my graphical desktop screwed up exactly as it had done before, when I first upgraded to M5. Upon investigation, I found that my symlinks /var/run -> /run and /var/lock -> /run/lock had changed back to /var/run -> ../run and /var/lock -> ../run/lock.

Some grepping turns up that this was done to me by /lib/dracut/modules.d/30convertfs/convertfs.sh .

I have altered that script to generate the symlinks the way I need to have them generated. However, I have every reason to expect that this mod will not stick through future updates. How would I change this function so that the mods DO persist?

edit. Actually, I would think the system scripts would be symlinking to an absolute path, as I am doing it, and not to a relative path, as they are doing it. So I am going to call this a bug.

Shall I split this out into a separate thread? As I had merged your feedback for the upgrade into the general mga5 feedback collection thread,
and this is not really suitable for support-type questions IMHO.

[doktor5000]

A week ago I posted a message describing my experience upgrading to Mageia 5. It got rolled into this viewtopic.php?f=7&t=9890&p=58686#p58686 thread which is a general "experiences" thread.

Subsequently, I have posted a couple of discrepancies I discovered. I do not believe those posts have been noticed because they are in that thread. So I am pointing them out here.

Sorry for the inconveniences, was my fault - and I replied in the other topic before I came to this browser tab ...

[doktor5000]

Today, after allowing some updates to go into place, my graphical desktop screwed up exactly as it had done before, when I first upgraded to M5. Upon investigation, I found that my symlinks /var/run -> /run and /var/lock -> /run/lock had changed back to /var/run -> ../run and /var/lock -> ../run/lock.

Some grepping turns up that this was done to me by /lib/dracut/modules.d/30convertfs/convertfs.sh .

I have altered that script to generate the symlinks the way I need to have them generated. However, I have every reason to expect that this mod will not stick through future updates. How would I change this function so that the mods DO persist?

edit. Actually, I would think the system scripts would be symlinking to an absolute path, as I am doing it, and not to a relative path, as they are doing it. So I am going to call this a bug.

No, it's actually a feature™
https://wiki.mageia.org/en/System_Servi ... .2Flock.29


For the questions about /etc/sysconfig/rsyslog that is pretty simple, it is marked as %config(noreplace) - like nearly all other config files.
This means, that if you made changes to the config, on updates which would bring a different config, your config will not be overwritten but you should have a /etc/sysconfig/rsyslog.rpmnew
Details of this mechanism explained well in http://www-uxsup.csx.cam.ac.uk/~jw35/do ... onfig.html

[jiml8]

No, it's actually a feature™
https://wiki.mageia.org/en/System_Servi ... .2Flock.29

What I am calling a bug is the use of relative paths in the symlinks, rather than absolute paths. Absolute paths actually are what provide the desired behavior. Relative paths make (possibly unwarranted) implicit assumptions about the structure of the directory tree.

For the questions about /etc/sysconfig/rsyslog that is pretty simple, it is marked as %config(noreplace) - like nearly all other config files.
This means, that if you made changes to the config, on updates which would bring a different config, your config will not be overwritten but you should have a /etc/sysconfig/rsyslog.rpmnew
Details of this mechanism explained well in http://www-uxsup.csx.cam.ac.uk/~jw35/do ... onfig.html

I am, of course, familiar with the mechanism because I have seen it working for years now.

However, I do not recall that I ever modified the rsyslog.conf file. Even if I had, there was no recent .rpmnew file present in the directory. There was an .rpmnew from Sept 2014 there, but that was all.

[jiml8]

Problems with rsyslog persist.

I was forced to reboot this system a couple of days ago after akonadi (or baloo...not sure) went berserk and I could not successfully clean things up.

After reboot, I checked explicitly and the rsyslogd was running.

I noticed this morning that, although rsyslogd was running, nothing was getting written into the logs...and I noticed this because some of my security was impaired and attackers on SSH were not being firewalled off after 6 failed attempts to log in. This is done by a script called blockhosts, which depends on information in auth.log for its work.

Some fiddling around showed that if I stopped rsyslog, then stopped syslog.socket, then restarted syslog.socket, then restarted rsyslog. everything worked again.

This is actually a pretty serious issue for me.

Also, calibre no longer works in 64 bit. It requires some qt5 packages that are not available in the repos for 64 bit, although they are available for 32 bit. Notably, although libQt5WebKitWidgets.so.5 is available, libQt5WebKit.so.5 is not available. I believe there are other Qt5 dependencies also missing, though I don't have a complete list of those.

[doktor5000]

For the rsyslog issue, I believe that is somehow related to your symlink issue, but best open a bugreport for rsyslog not running anymore.

For calibre, it works fine here on x86_64. Also the library you mentioned exists for both x86_64 and i586:

Code: Select all

┌─[doktor5000@Mageia5]─[09:32:52]─[~]                                                                                                     
└──╼ urpmf libQt5WebKit.so.5
lib64qt5webkit5:/usr/lib64/libQt5WebKit.so.5
lib64qt5webkit5:/usr/lib64/libQt5WebKit.so.5.4
lib64qt5webkit5:/usr/lib64/libQt5WebKit.so.5.4.0
libqt5webkit5:/usr/lib/libQt5WebKit.so.5
libqt5webkit5:/usr/lib/libQt5WebKit.so.5.4
libqt5webkit5:/usr/lib/libQt5WebKit.so.5.4.0

[jiml8]

I did find the Qt5 libs when I searched for lib64Qt5...

Previously, I had searched for libQt5...

What can I say? It was late, and I was both tired and annoyed when Calibre did not start.

In any case, Calibre was present on my system in M4 but when the system updated, it did not update the required Qt5 libs.

I will post the rsyslog thing as a bug, but I am more interested in how to solve it; I CANNOT permit this problem to persist, even if I must roll back to stop it. I have no clue what syslog.socket is about, and sorting out the sequence of start events in systemd is non-trivial and seems to involve a lot of searching through individual systemd files (and there are MANY of these). I have symlinked /lib/systemd/system/syslog.socket into /etc/systemd/system/sockets.target.wants but I have no idea if this will help.

I also pulled in the rsyslog.service file from M4, and it is very different than the current one. I tested with it, then removed it. Perhaps I should put it back...

[jiml8]

...and now, after installing an update and rebooting (I had to replace a fan also), I cannot get rsyslog running at all.

Oh, it starts. It runs. It just doesn't log anything.

And documentation of how rsyslog integrates with that stinking pile of crap systemd???? Ain't no documentation that I can find. There is supposed to be an integration text...someplace. But where? I don't know.

Shortly, I'll be rolling back to Mageia 4 if I can't sort this out.

[doktor5000]

And documentation of how rsyslog integrates with that stinking pile of crap systemd???? Ain't no documentation that I can find. There is supposed to be an integration text...someplace. But where? I don't know.

Main part is done by the postinstall scriptlets of the rpm.

Code: Select all

rpm -q --scripts rsyslog

will show you.
And if it doesn't work properly it would be better to at least report that as a bug. Otherwise probably nobody will look at it.

[jiml8]

I have reported it as a bug. Did that a week or two ago; have heard nothing in response.

I did get it to start logging. I attached gdb to it, and started trying to look at it...and suddenly it started logging.

However, there is changed behavior in it, compared to how it worked in Mageia 4.

In Mageia 4, all the messages would appear in the journal (and I tail the journal continually into a konsole window so I can track the system status at all times), while messages appropriate to specific log files in /var/log would appear in those files. Thus, many messages appeared at least twice; once in the journal and once in the specific log file.

That behavior is now changed. When rsyslogd is running but mysteriously not logging anything, all messages appear in the journal. When rsyslogd mysteriously decides to start working correctly, the messages that are destined for one of the log files do NOT show up in the journal.

I consider this behavior to be seriously undesirable. Clearly, something in systemd has changed. Again.

The world should leave Redhat to this mess they have made, and dump that stinking pile of excrement. SysV scripts at least had the advantage of reliability and consistency.

[doktor5000]

FWIW, can you check if you have rsyslog-journald installed?
And that that you don't have storage=none in /etc/systemd/journald.conf ? Also, what do you have there for FowardToSyslog= ?

See more details in https://bugs.mageia.org/show_bug.cgi?id=16263

[jiml8]

ForwardToSyslog and Storage are both commented out, which means they should default. The commented out values should give the defaults, and they are ForwardToSyslog=yes and Storage=auto.

rsyslog-journald is not installed, and the description of what it does seems to indicate that installing it is undesirable.

[doktor5000]

Well, I have also installed rsyslog and I have ForwardToSyslog=yes - you should at least try to make sure that is set explicitly.

And rsyslog-journald is nowadays required and desirable, as you can read from the bugreport.

> rsyslog-journald did the first trick - was it changed since mga4? shouldn't
> rsyslog have a dependecy on that package?

It probably should IMO. I didn't do the rsyslog packaging so I'd be tempted to suggest it should just be merged into the main package and always included. If you install rsyslog, you pretty much want this.

It did change yeah.
In systemd 216 (from the NEWS file FYI):

* journald will no longer forward all local data to another
running syslog daemon. This change has been made because
rsyslog (which appears to be the most commonly used syslog
implementation these days) no longer makes use of this, and
instead pulls the data out of the journal on its own. Since
forwarding the messages to a non-existent syslog server is
more expensive than we assumed we have now turned this
off. If you run a syslog server that is not a recent rsyslog
version, you have to turn this option on again
(ForwardToSyslog= in journald.conf).

Although I just checked, and it seems even without that package journald happily forwards all messages to rsyslog, when ForwardToSyslog=yes is set.

[jiml8]

I was forced to reboot my system yet again last night, when the system froze as I tried to suspend a virtual machine.

I was cursing mightily as I anticipated another exciting time trying to get rsyslogd working properly. However, when the system restarted, rsyslogd did immediately work properly, and the journal also is working properly, with all system messages displayed.

The one change I made was to uncomment the ForwardToSyslog=yes line.

Is the problem solved? I don't know. To this point, I have found the behavior of journal to syslog to be very erratic. Perhaps the problem is fixed, and maybe this time I got lucky.

[doktor5000]

FWIW, please keep this under observation, in case it breaks again I'd be interested in feedback.