Bug 1304 - 2012.1,fail to start apply kernel variables
: 2012.1,fail to start apply kernel variables
Status: RESOLVED FIXED
Product: Desktop Bugs
Classification: ROSA Desktop
Component: Main Packages
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: ROSA Linux Bugs
: ROSA Linux Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-22 21:16 MSK by philippe.roubach
Modified: 2013-03-01 13:50 MSK (History)
3 users (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description philippe.roubach 2012-12-22 21:16:13 MSK
Description of problem:


when starting the pc during boot they is this message :

fail to start apply kernel variables
Comment 1 Denis Silakov 2012-12-24 15:04:03 MSK
This means that systemd-sysctl.service failed to set some variables specified in /etc/sysctl.conf.

In case of Desktop.Fresh 2012, it is net.bridge.* set that do not correspond to real kernel variables and should be likely dropped.

However, this doesn't seem to really break anything, at least at the boot time - all other values specified in /etc/sysctl.conf are applied successfully.

In general, something is wrong with our systemd-sysctl.service - in my experiments it always returned error if /etc/sysctl.comf contains at least one variable to be set.
Comment 2 Giovanni Mariani 2012-12-25 23:39:18 MSK
(In reply to comment #1)
> This means that systemd-sysctl.service failed to set some variables
> specified in /etc/sysctl.conf.
> In case of Desktop.Fresh 2012, it is net.bridge.* set that do not correspond
> to real kernel variables and should be likely dropped.
Nope.
I commented out the above lines and tried to restart systemd-sysctl.service, but still got a failure.

> In general, something is wrong with our systemd-sysctl.service - in my
> experiments it always returned error if /etc/sysctl.comf contains at least
> one variable to be set.
Comment 3 Denis Silakov 2012-12-25 23:46:49 MSK
(In reply to comment #2)
> (In reply to comment #1)
> > This means that systemd-sysctl.service failed to set some variables
> > specified in /etc/sysctl.conf.
> > In case of Desktop.Fresh 2012, it is net.bridge.* set that do not correspond
> > to real kernel variables and should be likely dropped.
> Nope.
> I commented out the above lines and tried to restart systemd-sysctl.service,
> but still got a failure.

Well, there are two issues here - first, these net.bridge.* lines don't really make much sense in any case since there are no appropriate variables available through /proc/sys.

(To see the difference, just launch 'sysctl -p /etc/sysctl.conf' with these lines on and off).

Second, systemd-sysctl.service fails to start if /etc/sysctl.conf is not empty (not taking comments into account) - this is what I've tried to say by the sentence quoted below, sorry if it wasn't clear.
 
> > In general, something is wrong with our systemd-sysctl.service - in my
> > experiments it always returned error if /etc/sysctl.conf contains at least
> > one variable to be set.

However, the variables set in /etc/sysctl.conf *are applied* during system startup, despite of systemd-sysctl.service message and exit code (maybe they are applied in some other place? should take a look...).
Comment 4 Giovanni Mariani 2012-12-26 00:20:32 MSK
> Second, systemd-sysctl.service fails to start if /etc/sysctl.conf is not
> empty (not taking comments into account) - this is what I've tried to say by
> the sentence quoted below, sorry if it wasn't clear.
>  
Oops...
I read too fast what you wrote above:
sorry for the useless comment.
Comment 5 Alexander Burmashev 2013-02-20 16:58:32 MSK
I spent some time investigating the problem and seem to found the culprit.
If /etc/sysctl.conf is the same as /etc/sysctl/sysctl.conf, in terms of content, it makes systemd-sysctl.service sad. Files may have the same name, but content must be different.
If the same option is listed twice in both files ( which happens in our case with symlinks ) it causes systemd-sysctl.service fail.
Proposed fix:
1) Provide /etc/sysctl.conf as the default config.
2) Clean /etc/sysctl.conf of obsoleted options
3) Create an empty /etc/sysctl/sysctl.conf as the dummy file for addition options.
Comment 6 Giovanni Mariani 2013-02-20 18:50:59 MSK
(In reply to comment #5)
> I spent some time investigating the problem and seem to found the culprit.
> If /etc/sysctl.conf is the same as /etc/sysctl/sysctl.conf, in terms of
> content, it makes systemd-sysctl.service sad. Files may have the same name,
> but content must be different.
> If the same option is listed twice in both files ( which happens in our case
> with symlinks ) it causes systemd-sysctl.service fail.
> Proposed fix:
> 1) Provide /etc/sysctl.conf as the default config.
> 2) Clean /etc/sysctl.conf of obsoleted options
> 3) Create an empty /etc/sysctl/sysctl.conf as the dummy file for addition
> options.
Hmm...
In my install /etc/sysctl/sysctl.conf is simply a symlink to /etc/sysctl.conf:
I will try to leave and empty file in /etc and move the original one in /etc/sysctl and see...
Comment 7 Alexander Burmashev 2013-02-20 18:52:04 MSK
better leave the original file on it's place in etc and just remove the symlink
Comment 8 Giovanni Mariani 2013-02-20 19:56:22 MSK
(In reply to comment #7)
> better leave the original file on it's place in etc and just remove the
> symlink
Either way I can confirm it solves the issue...
Comment 9 Alexander Burmashev 2013-02-20 19:56:59 MSK
Thanks a lot for a quick response, i am going to fix it in the repo today or maybe tomorrow :)
Comment 10 Alexander Burmashev 2013-03-01 13:50:03 MSK
Fixed in http://bugs.rosalinux.ru/show_bug.cgi?id=1713
Updated package will hit the repo soon