OpenRC support thread, 2d Edition

[d2_racing]

You should try this :

Code: Select all

rc_plug_services="!net.wlan0" 

[pilla]

You should try this :

Code: Select all

rc_plug_services="!net.wlan0" 

No, it didn't work.

[d2_racing]

Then, you should ask Roy directly.

[ppurka]

/etc/rc.conf:

Code: Select all

rc_hotplug="YES"
rc_coldplug="NO"
rc_plug_services=""
EDITOR="/usr/bin/vim"

You seem to have an old config? In my 0.6.0 config, I see neither rc_coldplug nor rc_plug_services nor EDITOR. And I have disabled hotplugging of network by the following:

Code: Select all

rc_hotplug="!net.*"

[d2_racing]

Maybe dispatch-conf didn't handle that migration.

By the way, the rc.conf is part of baselayout 2.x or OpenRc. Maybe it's not related at all with OpenRc.

[haarp]

I'm getting exactly this bug on OpenRC 0.6.1-r1:
http://bugs.gentoo.org/show_bug.cgi?id=239922

except that the bug is fixed, so there's something else preventing the remount. If I do a Magic SysRq just at the right moment, / still gets remounted ro. Why can't OpenRC do just that as the last stage before powering down, as a safety measure?
How can I find out what is preventing the remount? Why not print WHICH process is preventing it?

[peyguin]

I've found the following issue with openRC:

lets assume there is a service called foo and we start the service:

Code: Select all

/etc/init.d/foo start

if the service gets kill be some reason the runscript will report it as crashed

Code: Select all

/etc/init.d/foo status 
foo     | * status: crashed

The "problem" is that if you try to start the service again you will get a Warning that the service is already running.

Code: Select all

/etc/init.d/foo start
foo     | * WARNING: foo has already been started

[VinzC]

The "problem" is that if you try to start the service again you will get a Warning that the service is already running.

Try the "restart" command or, if it fails, the "zap" command then the "start" command.

[DeepBass909]

Last weekend I updated my system to openRC-0.6.1 and Baselayout-2.0.1. Everything is running great, even my network (wink), but there is one thing that annoys me...
Since the update, I can't switch to a text-console anymore (ctrl-alt-F1 for instance)... The only thing I see, are the kernel-messages, the last thing before OpenRC starts... OpenRC runs on console #7 (the same one as the X-system) in what seems to be a framebuffer, and as soon X starts, the console becomes unreachable...

Is there a way to get the old-style text-console back?

The way it now runs gives me some trouble, especially because I'm updating the X-system and the only way I can test and configure everything is by using my laptop and a ssh-connection...

[VoVaN]

Openrc seems to not handle well shutdown/restart when a service fails to go down. Case in point, I can turn off the wicd service normally (it takes a few seconds) from the shell, but during shutdown/reboot it always fails to be brought down. And as a result the whole shutdown process goes crazy.

When I don't use parallel startup, another service is picked to be shutdown, but then openrc says it can't go down because wicd is still up, so it "waits" (waiting 50 secs, waiting 45 sec, etc, etc). Yet, every now and then (around every minute) it retries to bring down wicd again, and again it fails. This loop goes on forever and it doesn't ever gets to reboot.

When a service fails to go down, shouldn't it either abort the halt sequence or just "zap" it and continue rebooting/halting? The current behaviour leaves me with a machine I can't use at all (unless I use the Magic SysReq to force a reboot/halt of the system).

The behaviour is even more chaotic when parallel startup is enabled. In this case, it appears that all services that CAN go down are unnoticed, because I get messages that go like: "waiting for wicd...." and after that expires,then I start getting messages like "waiting for localmount..." or any other service that shouldn't have problems going down on their own (unless they are tagged as forever stalled because they were waiting for wicd?)

Sorry I can't provide better logs of what's happening as the console is non-operational already while rebooting/halting (so I can't copy/paste anything). I THINK this should be easy to reproduce by simply editing any rc script to always fail on halt (and probably adding a second or two sleep within, too).

OpenRC 0.6.0-r1
Baselayout 2.0.1

Hi,

I'm experiencing the same behavior, but I thought it's because I use Gentoo with network boot and aufs. I've tried already to understand what's going on, but apparently it's very complicated. So as a dirty workaround I've placed in stop section of /etc/conf.d/local:

Code: Select all

    # Give some time to stop all the services,
    # otherwise force reboot/poweroff
    sleep 8
    case "`/sbin/runlevel|/bin/cut -c 3`" in
        0) 
            echo "Force power off"
            umount -r -a > /dev/null
            poweroff -f
            ;;
        6) 
            echo "Force reboot"
            umount -r -a > /dev/null
            reboot -f
            ;;
    esac

I know it isn't nice, but as minimum it works fine with RC_PARALLEL="YES" and I can get desktops rebooted/powered off. If you have solved this issue or have a better solution, please share!

[Skotlex]

Hi,

I'm experiencing the same behavior, but I thought it's because I use Gentoo with network boot and aufs. I've tried already to understand what's going on, but apparently it's very complicated. So as a dirty workaround I've placed in stop section of /etc/conf.d/local:
...

I solved this problem myself when I discovered that the problem wasn't the RC script failing to stop, but having an invocation of a run-level change WHILE in the midst of changing run-level.

Basically, when I did a shutdown/reboot, the moment wicd brings down the connection, my user scripts were invoking "rc nonetwork" to switch the runlevel, and having this invocation WHILE the system was going down is what broke hell over my laptop.

Perhaps, there should be some way for the rc command to detect and abort recursive calls.

[vklimovs]

I didn't see this topic before creating new one with question. I will be sure to update the topic I opened with solution, if there will be any.

I have two absolutely identical machines that have absolutely the same set of software installed (basically just system and system tools: cron, slocate, syslog, logrotate etc.). Both machines run OpenRC 0.6.2. However, after boot on one machine set of started services looks like that:

Code: Select all

Runlevel: default
 syslog-ng            [  started  ]
 iptables               [  started  ]
 udev-postmount   [  started  ]
 net.eth0              [  started  ]
 net.eth1              [  started  ]
 sshd                   [  started  ]
 vixie-cron           [  started  ]
 ntpd                   [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 udev-mount        [  started  ]
Dynamic Runlevel: manual

but on another one like that:

Code: Select all

Runlevel: default
 syslog-ng             [  started  ]
 vixie-cron             [  started  ]
 iptables                [  started  ]
 net.eth0               [  started  ]
 net.eth1               [  started  ]
 ntpd                     [  started  ]
 udev-postmount    [  started  ]
 sshd                     [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 sysfs                    [  started  ]
Dynamic Runlevel: manual

Basically, the difference is that in dynamic runlevel "needed" one machine starts sysfs while another one starts udev-mount.

Why is that? Which is correct one? How do I make the one that starts incorrect service start correct one?

[punloh]

Hi. OpenRC 'hangs' once or twice on startup and shutdown but continues normally when I press any key. I've tried disabling parallel startup but it didn't help. It seems to have started after upgrade to 0.6 and is still present in 0.6.2. Any ideas?

[Goverp]

Finally got around to migrating my 4-way AMD64 box to OpenRc.
Great improvement over the old start-up: was 48 seconds to KDE login screen,
with OpenRc, 27 seconds.

So then I went for parallel start-up (the numbers above were serial).
And a raft of services starting with portmap hung waiting for ntp-client,
which was strange as it had already started OK.

FWIW, I noticed I had net.lo in boot run-level, but net.eth0 and ntp-client etc.
in default run-level.
Moving net.lo to default and changing rc_depend_strict to YES appears to
have cured it.

That cut the time to the KDE login screen to 22 seconds!
Now to see if I can get X to start faster.

[js08]

I have two absolutely identical machines that have absolutely the same set of software installed (basically just system and system tools: cron, slocate, syslog, logrotate etc.). Both machines run OpenRC 0.6.2. However, after boot on one machine set of started services looks like that:

Code: Select all

Runlevel: default
 syslog-ng            [  started  ]
 iptables               [  started  ]
 udev-postmount   [  started  ]
 net.eth0              [  started  ]
 net.eth1              [  started  ]
 sshd                   [  started  ]
 vixie-cron           [  started  ]
 ntpd                   [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 udev-mount        [  started  ]
Dynamic Runlevel: manual

but on another one like that:

Code: Select all

Runlevel: default
 syslog-ng             [  started  ]
 vixie-cron             [  started  ]
 iptables                [  started  ]
 net.eth0               [  started  ]
 net.eth1               [  started  ]
 ntpd                     [  started  ]
 udev-postmount    [  started  ]
 sshd                     [  started  ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed
 sysfs                    [  started  ]
Dynamic Runlevel: manual

Why is that? Which is correct one? How do I make the one that starts incorrect service start correct one?

Hi I have smilar effects(sys-apps/openrc-0.6.3) with manually started daemons...

Code: Select all

...
Dynamic Runlevel: manual
 chroot_gen32                            [  started  ]

very seldom...

Code: Select all

...
Dynamic Runlevel: manual
 chroot_gen32                             [  started  ]
 boinc                                         [  started  ]

rc-status is most of the time not able to show "boinc",
but rc-status -s shows always that boinc is started

[Poikilotherm]

And another issue with OpenRC This time its a rather special thing, but I hope you guys can help me out

I have a cluster node where I want to test the new OpenVZ RHEL6 Kernel, as I need some of the OCFS2 Patches in there. The OpenVZ people added some new stuff to their code and it seems that they use now CGroups as LXC does. This leads into a big booting problem...

When I boot the machine, the kernel comes up. When it changes to INIT, openrc loads, but in the boot runlevel it only mount /proc, sets the hostname and thats it. Of course there is the root remount missing and especially the localmount... Wondering why the init process does not do all the stuff that is configured for the runlevel, I found after a few hours of digging into the problem that "rc -S" tells me this is an LXC container. The expected result is an empty string (compared by a few other machines).

I think that openrc decides this machine is an LXC container as /proc/self/cgroup gives us informations that normally appears only inside of an LXC container. I saw a patch for openrc on the bug list (sry, I don't find that link anymore...) that had a look into this file and got accepted for upstream a while ago. The regex in there fits to the output below:

Code: Select all

$ cat /proc/self/cgroup
2:cpu:/2147483647
1:blkio:/0

As I mentioned earlier, this is added by the OpenVZ stuff now using cgroups, too. That CPU Limit is the same number OpenVZ uses for "infinity" which in return is the default for Container 0 = OpenVZ Host. Unfortunately I have no experience with LXC, but I think there has to be another way OpenRC detects wheter it is inside a LXC container or not. Is there a chance for you dev guys to fix this? Perhaps a LXC guy will have a look at this thread, too...

Thanks for your help!

[Poikilotherm]

Solved this one with a quick fix that come to my mind last night

Have a look in here: http://bugs.gentoo.org/show_bug.cgi?id=291364
(This is the above mentioned bug I forgot the link of...)

[deurk]

Can anyone find a reason for this to be displayed when I restart a service?

Code: Select all

 * Caching service dependencies ... /lib64/rc/sh/rc-functions.sh: line 91: shell_var: command not found       [ ok ]

[MoonWalker]

Latest openrc 0.7 adds the following shunk to rc.conf

# This is the subsystem type. Valid options on Linux:
# "" - nothing special
# "lxc" - Linux Containers
# "openvz" - Linux OpenVZ
# "prefix" - Prefix
# "uml" - Usermode Linux
# "vserver" - Linux vserver
# "xen0" - Xen0 Domain
# "xenU" - XenU Domain
# If unset, the old automagic detection code will be triggered. Said old code
# is deprecated and be removed not later than 2010/03/01.
rc_sys=""

Apart from the date that must be a joke I find this being sparse if not poorly documented as it leave at least me scratching my head whether this should be set on the host system or in the virtual container or both, anyone being clear on this?

[myceliv]

rc_sys="" is not the same as rc_sys is not set at all. It's having it unset that makes rc try to use the deprecated code. So for regular linux, nothing special that default value of "" is correct.

[Edit:] Ah, I did not read carefully. I would set "" on host, and the appropriate virtual inside vm's.

[MoonWalker]

Yes got that figured out after opening a bug about it and was pointed at the Baselayout and OpenRC Migration Guide, wasn't aware of that this document also serve as some kind of user documentation and I migrated quite some time ago.

[depontius]

Is there still a plan for Gentoo to move to OpenRC and baselayout-2?

I ask that because I'm installing a new hardened system now, and it would be good to migrate before I start depending on it, rather than after, if I'm going to move. But this thread started (part #1) almost 3 years ago. OpenRC/baselayout-2 titled threads and discussions have dropped well down the list pretty much any search - even when searching for them. Add to that that Uberlord "retired" some time ago, and it makes me wonder if this entire migration has stalled and will likely be overtaken by some sort of systemd or upstart migration instead.

[asturm]

The Bug tracker is alive and kicking: https://bugs.gentoo.org/show_bug.cgi?id=295613

Several blockers have been fixed over the last weeks, now there still remain two that need to be either ironed out or considered unimportant. As I understand, both are close at being closed. I think it won't take long anymore.

[guid0]

I route into tap0 device using the following /etc/conf.d/net content. (please note that some parts have already been migrated to the new baselayout2/openrc format.

Code: Select all

config_eth1="22.64.250.66 netmask 255.255.255.0 broadcast 82.64.250.66"
config_eth0="192.168.0.66 netmask 255.255.255.0 broadcast 192.168.0.255"

tuntap_tap0="tap"
config_tap0="10.10.10.20 netmask 255.255.255.0 broadcast 10.10.10.255"

routes_tap0=(
#"192.168.0.8"
#"192.168.0.9"
"192.168.0.47"
#"192.168.0.48"
#"192.168.0.53"
"192.168.0.63"
"192.168.0.77"
#"22.64.250.8"
#"22.64.250.9"
"22.64.250.47"
#"22.64.250.48"
#"22.64.250.53"
"22.64.250.63"
"22.64.250.77"
)

routes_eth1=("default via 22.64.250.1")

which would generate the following routing table:

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
22.64.250.63    0.0.0.0         255.255.255.255 UH    0      0        0 tap0
22.64.250.47    0.0.0.0         255.255.255.255 UH    1000   0        0 tap0
22.64.250.77    0.0.0.0         255.255.255.255 UH    1000   0        0 tap0
192.168.0.77    0.0.0.0         255.255.255.255 UH    1000   0        0 tap0
192.168.0.63    0.0.0.0         255.255.255.255 UH    0      0        0 tap0
192.168.0.47    0.0.0.0         255.255.255.255 UH    1000   0        0 tap0
22.64.250.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         22.64.250.1     0.0.0.0         UG    0      0        0 eth1

I have tried various formats but would like to know how to port route_tap0 and config_tap0 properly.
guid0

[Basilisk]

In order to avoid double-posting, could you please take a look to this post?