Giter VIP home page Giter VIP logo

openrc's Introduction

OpenRC README

OpenRC is a dependency-based init system that works with the system-provided init program, normally /sbin/init.

building and installing

OpenRC uses the meson build system, so use the usual methods for this build system to build and install.

Notes

We don't support building a static OpenRC with PAM.

PKG_PREFIX should be set to where packages install to by default.

LOCAL_PREFIX should be set to where user maintained packages are. Only set LOCAL_PREFIX if different from PKG_PREFIX.

ROOTPREFIX should be set when the root path is different from '/'.

rc and rc.shutdown are the hooks from the BSD init into OpenRC.

devd.conf is modified from FreeBSD to call /etc/rc.devd which is a generic hook into OpenRC.

inittab is the same, but for SysVInit as used by most Linux distributions. This can be found in the support folder.

Obviously, if you're installing this onto a system that does not use OpenRC by default then you may wish to backup the above listed files, remove them and then install so that the OS hooks into OpenRC.

Discussions

We are testing discussions, so feel free to open topics there.

Reporting Bugs

Please report bugs on our bug tracker.

If you can contribute code , please feel free to do so by opening pull requests.

IRC Channel

We have an official irc channel, #openrc on the libera network. Please connect your irc client to irc.libera.chat and join #openrc on that network.

openrc's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openrc's Issues

start-stop-daemon.sh: inconsistent service naming in the output

ebegin lines in ssd_{start,stop} functions refer to the service by its $name, while eend lines by $RC_SVCNAME. openrc-run also uses $RC_SVCNAME.

Log then looks like this:

* Stopping ${name} ...
* start-stop-daemon: 1 process refused to stop
* Failed to stop ${RC_SVCNAME}                         [ !! ]
* ERROR: ${RC_SVCNAME} failed to stop

I'm not sure whether this is the intended behaviour, because in case where $name differs drastically, it may not be clear what was done.

--stdout and --stderr to support redirection to syslog

I find myself supporting a lot of new Golang applications that don't have options to send logs to the syslog daemon. It would be great if I could handle that with a oneliner config change in an init script.

Perhaps it could be something like this:

--stdout syslog:daemon.info \
--stderr syslog:daemon.err

Where the tag would be populated by either $SVCNAME or --name.

I'm willing to write a PR for the change. I'm curious if there is community interest, and what the syntax/execution would be.

init.d/bootmisc with openrc-init

I switched over to openrc-init and ran into this after issuing the command "openrc-shutdown --reboot":

/etc/openrc/init.d/bootmisc: line 243: halt: command not found

Obviously this error occurs because I uninstalled sysvinit after verifying that openrc-init works.

cgroup v2 support

Version 2 of cgroups has been considered stable in the mainline kernel for two release cycles now. It would be really nice to have the option to use it with OpenRC.

Based on my (limited) knowledge of the internals of cgroupv2 and OpenRC, here's what would have to change:

  • Add an option in rc.conf to select between cgroup v1 and cgroup v2 support.
  • Abstract how paths are constructed to files in cgroups. cgroup v2 uses a unified hierarchy (equivalent to everything being co-mounted), usually rooted at /sys/fs/cgroup.
  • Add a config option to select which controllers to enable when using cgroup v2. cgroup v2 requires controllers to be explicitly enabled before they can be used.
  • Add a config option to specify parameters for cgroup v2 controllers. Because of the unified hierarchy, it makes little sense to split the config for each controller to a separate variable.

detect openrc configuration files locations at runtime

arch linux , systemd-free.org and manjaro use different locations for openrc.
Using SYSCONFDIR and BINDIR , we can set the correct location at build time.

Packages providing openrc service files for arch linux can not be used on systemd-free.org , manjaro and vice versa.
If the locations needed for services could be detected at openrc runtime, it should be possible to create packages that work on all systems that share a package manager / package build system..

Is there a way to achieve this ?

shellchecked

shellcheck finds some bugs.
etc/rc.shutdown.in: LDLIBRARY_PATH->LD_LIBRARY_PATH
sh/init.sh.Linux.in: proc="linprocfs"->procfs="linprocfs"

sysctl.conf obsolete on some distros

Can it be made so, that /etc/sysctl.conf won't be tried to load on boot, if a config in /etc/sysctl.d/ exists?
No /etc/sysctl.conf currently throws an error on boot complaining about missing file.
For the moment, I fixed it with placing an empty /etc/sysctl.conf.

fsck init script doesn't work with f2fs filesystem (and maybe btrfs?)

* Checking local filesystems  ...
fsck.f2fs: invalid option -- 'p'
        Error: Unknown option ?

Usage: fsck.f2fs [options] device
[options]:
  -a check/fix potential corruption, reported by f2fs
  -d debug level [default:0]
  -f check/fix entire partition
  -t show directory tree [-d -1]

not sure how it behaves with btrfs but fsck.btrfs only says:

fsck.btrfs 
If you wish to check the consistency of a BTRFS filesystem or
repair a damaged filesystem, see btrfs(8) subcommand 'check'.

Implement service supervision?

The main argument of systemd fanboys against OpenRC is that it doesn’t support supervision, i.e. crashed services are not automatically restarted. I agree that it’s indeed a nice feature, that comes handy in some situations, although it cannot (and should not) replace a monitoring system.

I’m convinced that it can’t be hard to implement a simple supervising in OpenRC. What do you think about it?

Q q h options of systemd-tmpfiles not understood by openrc

Openrc 0.21.4 , systemd 228

* Setting up tmpfiles.d entries ...
tmpfiles: ignoring invalid entry on line 10 of `/usr/lib/tmpfiles.d//home.conf'
tmpfiles: ignoring invalid entry on line 11 of `/usr/lib/tmpfiles.d//home.conf'
tmpfiles: ignoring invalid entry on line 25 of `/usr/lib/tmpfiles.d//journal-nocow.conf'
tmpfiles: ignoring invalid entry on line 26 of `/usr/lib/tmpfiles.d//journal-nocow.conf'
tmpfiles: ignoring invalid entry on line 27 of `/usr/lib/tmpfiles.d//journal-nocow.conf'
tmpfiles: ignoring invalid entry on line 11 of `/usr/lib/tmpfiles.d//tmp.conf'
tmpfiles: ignoring invalid entry on line 12 of `/usr/lib/tmpfiles.d//tmp.conf'
tmpfiles: ignoring invalid entry on line 10 of `/usr/lib/tmpfiles.d//var.conf'

the relevant lines :

Q /home 0755 - - -
q /srv 0755 - - -
h /var/log/journal - - - - +C
h /var/log/journal/%m - - - - +C
h /var/log/journal/remote - - - - +C
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
q /var 0755 - - -

from man tmpfiles.d

 q
       Similar to v. However, makes sure that the subvolume will be assigned to the same higher-level
       quota groups as the subvolume it has been created in. This ensures that higher-level limits and
       accounting applied to the parent subvolume also include the specified subvolume. On non-btrfs file
       systems, this line type is identical to d. If the subvolume already exists and is already assigned
       to one or more higher level quota groups, no change to the quota hierarchy is made. Also see Q
       below. See btrfs-qgroup(8) for details about the btrfs quota group concept.
  Q
       Similar to q. However, instead of copying the higher-level quota group assignments from the parent
       as-is, the lowest quota group of the parent subvolume is determined that is not the leaf quota
       group. Then, an "intermediary" quota group is inserted that is one level below this level, and
       shares the same ID part as the specified subvolume. If no higher-level quota group exists for the
       parent subvolume, a new quota group at level 255 sharing the same ID as the specified subvolume is
       inserted instead. This new intermediary quota group is then assigned to the parent subvolume's
       higher-level quota groups, and the specified subvolume's leaf quota group is assigned to it.

       Effectively, this has a similar effect as q, however introduces a new higher-level quota group for
       the specified subvolume that may be used to enforce limits and accounting to the specified
       subvolume and children subvolume created within it. Thus, by creating subvolumes only via q and Q,
       a concept of "subtree quotas" is implemented. Each subvolume for which Q is set will get a
       "subtree" quota group created, and all child subvolumes created within it will be assigned to it.
       Each subvolume for which q is set will not get such a "subtree" quota group, but it is ensured that
       they are added to the same "subtree" quota group as their immediate parents.

       It is recommended to use Q for subvolumes that typically contain further subvolumes, and where it
       is desirable to have accounting and quota limits on all child subvolumes together. Examples for Q
       are typically /home or /var/lib/machines. In contrast, q should be used for subvolumes that either
       usually do not include further subvolumes or where no accounting and quota limits are needed that
       apply to all child subvolumes together. Examples for q are typically /var or /var/tmp. As with Q, q
       has no effect on the quota group hierarchy if the subvolume exists and already has at least one
       higher-level quota group assigned.
 h
       Set file/directory attributes. Lines of this type accept shell-style globs in place of normal path
       names.
       The format of the argument field is [+-=][aAcCdDeijsStTu] . The prefix + (the default one) causes
       the attribute(s) to be added; - causes the attribute(s) to be removed; = causes the attributes to
       be set exactly as the following letters. The letters "aAcCdDeijsStTu" select the new attributes for
       the files, see chattr(1) for further information.
       Passing only = as argument resets all the file attributes listed above. It has to be pointed out
       that the = prefix limits itself to the attributes corresponding to the letters listed here. All
       other attributes will be left untouched. Does not follow symlinks.

[discussion] Stopping dependant services automatically

Hi,

Let me illustrate the issue with an example:

When starting the libvirtd service, it needed virtlogd which got automatically started. However when libvirtd was stopped, virtlogd kept on running in the background...

Had a chat about it in the IRC channel, and this can be currently achieved in two ways, via running openrc to re-calculate dependencies and stop extra services (manual), or by using a stacked runlevel for libvirtd which derives from the default runlevel and switching to it when starting the service and switching back to the default runlevel to stop it (automatic after creating once).

To make it more convenient, could a config option be added to /etc/rc.conf which automatically stops dependant services when the original service has been stopped?

start-stop-daemon: issues with the `--retry` option

The --retry option is quite underdocumented. Most of its functionality is present only in the man page of the old debian predecessor and in its --help output:

Retry <schedule> is <item>|/<item>/... where <item> is one of
 -<signal-num>|[-]<signal-name>  send that signal
 <timeout>                       wait that many seconds
 forever                         repeat remainder forever
or <schedule> may be just <timeout>, meaning <signal>/<timeout>/KILL/<timeout>

Here are few points which are valid for this successor:

  1. value can be either timeout or a sequence of at least 2 timeouts/signals separated by /
  2. there is a special timeout forever, though it doesn't work because run_stop_schedule's while loop doesn't have a case to handle it, so it bails out when reaching the default case which is an error
  3. signals can be specified as [-][SIG]<SIGNAL_NAME>
  4. if only timeout is specified and --signal is not present, SIGTERM is sent
  5. manpage doesn't state --signal is an option that can be used together with --stop and --retry
  6. there is a default --retry when --stopping with a value of 5
  7. points 4 and 6 mean the default --retry would look like TERM/5

Don't ignore initscripts with different shebang silently

Hello OpenRC devs,

I'm using OpenRC on Parabola Linux.
After the upgrade from 0.24 to 0.24.1 I have noticed, that some init scripts just did not get executed during boot anymore. But they worked fine with rc-service $service start.
I have debugged this issue for about two hours now, and found the solution by reading a random open issue: Initscripts without the correct shebang (#!/sbin/openrc-run on Parabola) get ignored.

Lots of initscripts on Parabola still have #!/usr/bin/openrc-run as shebang, and of course my custom init scripts had that shebang too (as I have copied old Parabola init scripts as starting point).

I want to spare other people the same pain, so could you please not silently ignore those initscripts, but display a waning when encountering these (eg. during init)?

Thanks for making OpenRC!

EDIT: Parabola Bugreport: https://labs.parabola.nu/issues/1240

Supervise-daemon does not give up restarting a daemon if the daemon fails to start

I'm creating a OpenRC service file and I'm utilizing supervise-daemon. The 'thing' I want to supervise is a simple shell script.
When starting the service with rc-service transcoder start if ends up in an infinite loop spewing supervise-daemon: failed to exec /home/transcoder/fetch.sh': No such file or directory`
I've checked and double checked if the file exists and it does, it is also executable.
Does openrc use some sort of implicit chroot?

My service file:

#!/sbin/openrc-run
supervisor=supervise-daemon

user=transcoder
supervise_daemon_args="-u $user"
command=/home/transcoder/fetch.sh
command_args="arg1 arg2"
pidfile=/run/transcoder.pid
retry=10800 # 3 hours
transcoder_status_file=/run/transcoder_has_ever_been_started

depend() {
    need net
}

start_pre() {
  # If this file exists then transcoder has been started before.
  # It might be so that the media server is down. Wait for 3 hours.
  if [ -f $transcoder_status_file ]; then
    sleep $retry
  fi

  touch /run/transcoder_has_ever_been_started
}

Based on the source I've more of less recreated the explicit supervise-daemon command:

supervise-daemon --start --pidfile /run/transcoder.pid /home/transcoder/fetch.sh -- arg1 arg2

But that yields the same result:

 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory
 * supervise-daemon: failed to exec `/home/transcoder/fetch.sh': No such file or directory

/sys/fs/cgroup/openrc/bootmisc/tasks: No such file or directory

Hi,

Using OpenRC 0.13.11 on Manjaro Linux, with eudev and Consolekit2. I looked at /var/log/rc.log and found the following message(s) when shutting down:

/usr/lib/rc/sh/rc-cgroup.sh: line 88: /sys/fs/cgroup/openrc/bootmisc/tasks: No such file or directory
 * Unmounting loop devices
 * Unmounting filesystems
 * Deactivating swap devices ...
 [ ok ]

Full log: http://pastebin.com/z4UUHHji
The packages used can be found here: https://github.com/manjaro/packages-openrc
(package containing OpenRC is openrc-core)

System info:

$ inxi -Fxz
System:    Host: manjaro Kernel: 3.18.10-1-MANJARO x86_64 (64 bit gcc: 4.9.2)
           Desktop: Xfce 4.12.1-MANJARO (Gtk 2.24.27) Distro: ManjaroLinux 0.9.0-openrc Bellatrix
Machine:   System: innotek product: VirtualBox v: 1.2
           Mobo: Oracle model: VirtualBox v: 1.2 Bios: innotek v: VirtualBox date: 12/01/2006
CPU:       Dual core Intel Core i5-3210M (-MCP-) cache: 6144 KB flags: (lm nx sse sse2 sse3 ssse3) bmips: 9974 
           clock speeds: max: 2492 MHz 1: 2492 MHz 2: 2492 MHz
Graphics:  Card: InnoTek Systemberatung VirtualBox Graphics Adapter bus-ID: 00:02.0
           Display Server: X.Org 1.17.1 driver: ati Resolution: [email protected]
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
           GLX Version: 3.0 Mesa 10.5.1 Direct Rendering: Yes
Audio:     Card Intel 82801AA AC'97 Audio Controller driver: snd_intel8x0 ports: d100 d200 bus-ID: 00:05.0
           Sound: Advanced Linux Sound Architecture v: k3.18.10-1-MANJARO
Network:   Card: Intel 82540EM Gigabit Ethernet Controller
           driver: e1000 v: 7.3.21-k8-NAPI port: d010 bus-ID: 00:03.0
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 21.5GB (55.8% used) ID-1: /dev/sda model: VBOX_HARDDISK size: 21.5GB
Partition: ID-1: / size: 19G used: 9.8G (57%) fs: ext3 dev: /dev/sda1
           ID-2: swap-1 size: 1.61GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 113 Uptime: 52 min Memory: 195.5/2005.8MB
           Init: SysVinit rc: OpenRC runlevel: default Gcc sys: 4.9.2 Client: Shell (bash 4.3.331) inxi: 2.2.19 

Dont know what is causing it, though I dont think its affecting any functionality..

Edit-

$ ls -l /sys/fs/cgroup/openrc/
total 0
drwxr-xr-x 2 root root 0 Mar 30 19:15 acpid
-rw-r--r-- 1 root root 0 Mar 30 20:37 cgroup.clone_children
-rw-r--r-- 1 root root 0 Mar 30 20:37 cgroup.procs
-r--r--r-- 1 root root 0 Mar 30 20:37 cgroup.sane_behavior
drwxr-xr-x 2 root root 0 Mar 30 19:15 consolekit
drwxr-xr-x 2 root root 0 Mar 30 19:15 cronie
drwxr-xr-x 2 root root 0 Mar 30 19:15 dbus
drwxr-xr-x 2 root root 0 Mar 30 19:15 dhcpcd
-rw-r--r-- 1 root root 0 Mar 30 19:15 notify_on_release
-rw-r--r-- 1 root root 0 Mar 30 20:37 release_agent
drwxr-xr-x 2 root root 0 Mar 30 19:15 syslog-ng
-rw-r--r-- 1 root root 0 Mar 30 19:15 tasks
drwxr-xr-x 2 root root 0 Mar 30 19:15 udev
drwxr-xr-x 2 root root 0 Mar 30 19:15 xdm

services in 'boot' runlevel are not pulled in when switching to empty runlevel

The services in 'boot' and 'sysinit' runlevels should be pulled in when switching to any runlevel (except shutdown). This only happens if there are services to start in the runlevel.

When booting the alpine iso we have an empty 'default' runlevel and unlike Gentoo, we don't explicitly run the 'boot' level from /etc/inittab. This has worked fine til operc-0.13 and later.

Screenshot:

(none):~# rc-status --runlevel                                                  
default
(none):~# rc-update                                                             
             bootmisc | boot                                                    
                devfs |                       sysinit                           
                dmesg |                       sysinit                           
             hostname | boot                                                    
              hwclock | boot                                                    
            hwdrivers |                       sysinit                           
            killprocs |              shutdown                                   
                 mdev |                       sysinit                           
              modloop |                       sysinit                           
              modules | boot                                                    
             mount-ro |              shutdown                                   
            savecache |              shutdown                                   
               sysctl | boot                                                    
               syslog | boot
(none):~# rc-status                                                             
Runlevel: default                                                               
Dynamic Runlevel: hotplugged                                                    
Dynamic Runlevel: needed                                                        
 sysfs                                                             [  started  ]
 mdev-mount                                                        [  started  ]
Dynamic Runlevel: manual
(none):~# openrc default                                                        
(none):~# rc-update -s add boot default                                         
 * rc-update: cannot stack the sysinit runlevel
(none):~# openrc boot                                                           
 * Loading modules ...                                                    [ ok ]
 * Setting system clock using the hardware clock [UTC] ...                [ ok ]
 * Checking local filesystems  ...                                        [ ok ]
 * Remounting filesystems ...                                             [ ok ]
 * Mounting local filesystems ...                                         [ ok ]
 * Configuring kernel parameters ...                                      [ ok ]
 * Migrating /var/lock to /run/lock ...                                   [ ok ]
 * Migrating /var/run to /run ...                                         [ ok ]
 * Creating user login records ...                                        [ ok ]
 * Wiping /tmp directory ...                                              [ ok ]
 * Setting hostname ...                                                   [ ok ]
 * Starting busybox klogd ...                                             [ ok ]
 * Starting busybox syslog ...                                            [ ok ]
localhost:~# rc-status --runlevel                                               
boot
localhost:~# openrc default                                                     
localhost:~# 

Problems with 0.20.1 make in chroot

Hi,

I run into a strange problem with latest version 0.20.1, I have trouble compiling it, but only in chroot.

If I use makepkg, ie build host is running system, everything goes well, the package gets created.

If I try to make the package in chroot, same build as for 0.19.1, it fails:

log:
http://pastebin.com/jcFtaULy

$ uname -a
Linux manjaro-openrc 4.2.8.1-1-MANJARO #1 SMP PREEMPT Fri Jan 8 23:56:16 UTC 2016 x86_64 GNU/Linux

Is there a new depend I am missing?

tmpfiles.sh : doesn't support tmpfiles.d v option

tmpfiles: ignoring invalid entry on line 11 of /usr/lib/tmpfiles.d//tmp.conf' tmpfiles: ignoring invalid entry on line 12 of/usr/lib/tmpfiles.d//tmp.conf'
tmpfiles: ignoring invalid entry on line 21 of `/usr/lib/tmpfiles.d//var.conf'

these are the 3 lines that gives this message :
v /tmp 1777 root root 10d
v /var/tmp 1777 root root 30d
v /var/lib/machines 0700 - - -

from man timpfiles.d :
v
Create a subvolume if the path does not exist yet and the file system supports this (btrfs). Otherwise create a normal directory, in the same way as d.

Note : archlinux, booting openrc 0.16.4 with systemd 219 (used for udev)

ncurses includes

When detecting ncurses via pkg-config it would make sense to pass "--cflags" argument to pkg-config so that the ncurses headers are found properly as on my system they are not and are located in /include/ncursesw.

rc_crashed_start is not working

Hi,

I hope I get it right. When stated in /etc/rc.conf
rc_crashed_start=YES
then OpenRC should try to bring up services which crashed, right?
I set this variable, reboot, then verify that vixie-cron is running, kill vixie-cron PID, rc-status showed me that vixie-cron is in "crashed" state, but even after 30 minutes, it does not try to restart the service...

I have latest stable Gentoo (amd64) with latest stable OpenRC.

Thank you

start-stop-daemon.sh undocumented variables

  1. procname changing --name option
  2. command_user changing --user option
  3. command_args_background which is append to command_args
    • for some reason cannot be specified if command_background evaluates to true

modules-load.d support can cause kernel modules to be loaded twice

On my Gentoo system the app-emulation/virtualbox-modules package installs /usr/lib/modules-load.d/virtualbox.conf for systemd users. However I use OpenRC, and I specify the VirtualBox kernel modules in /etc/conf.d/modules. The modules-load.d support that was added to 0.21.x with commit 556dbff, will cause the VirtualBox kernel modules to be loaded twice during boot. Is there any way to prevent the modules listed in /usr/lib/modules-load.d from being loaded?

Stale services dependencies cache while editing /etc/rc.conf

Steps to reproduce:
echo 'rc_need="zram-init"' >> /etc/rc.conf
reboot
Observe that no services start because all now depend on zram-init
mount -o remount,rw / (required because mount fails)
sed -i 's/rc_need="zram-init"//' /etc/rc.conf
reboot
Observe that services still fail to start

rc-update -u
Updates cache, and all returns to normal.

Let me know if I can provide any more information

emerge --info

Portage 2.2.26 (python 2.7.10-final-0, default/linux/amd64/13.0, gcc-4.9.3, glibc-2.21-r2, 4.2.8-tuxonice x86_64)
=================================================================
System uname: Linux-4.2.8-tuxonice-x86_64-Intel-R-_Core-TM-_i7-2620M_CPU_@_2.70GHz-with-gentoo-2.2
KiB Mem:    16323664 total,  14344928 free
KiB Swap:   10485756 total,  10485756 free
Timestamp of repository gentoo: Sat, 26 Mar 2016 00:45:01 +0000
sh bash 4.3_p42-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
ccache version 3.1.9 [disabled]
app-shells/bash:          4.3_p42-r1::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.10-r1::gentoo, 3.4.3-r1::gentoo
dev-util/ccache:          3.1.9-r4::gentoo
dev-util/cmake:           3.3.1-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.19.1::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:           2.21-r2::gentoo
Repositories:

R_Overlay
    location: /var/lib/repos/R_Overlay
    sync-type: laymansync
    sync-uri: rsync://roverlay.dev.gentoo.org/roverlay
    masters: gentoo
    priority: 50

bumblebee
    location: /var/lib/repos/bumblebee
    sync-type: laymansync
    sync-uri: git://github.com/Bumblebee-Project/bumblebee-gentoo
    masters: gentoo
    priority: 50

haskell
    location: /var/lib/repos/haskell
    sync-type: laymansync
    sync-uri: git://github.com/gentoo-haskell/gentoo-haskell.git
    masters: gentoo
    priority: 50

java
    location: /var/lib/repos/java
    sync-type: laymansync
    sync-uri: git://anongit.gentoo.org/proj/java.git
    masters: gentoo
    priority: 50

mate
    location: /var/lib/repos/mate
    sync-type: laymansync
    sync-uri: git://github.com/Sabayon/mate-overlay.git
    masters: gentoo
    priority: 50

mate-community
    location: /var/lib/repos/mate-community
    sync-type: laymansync
    sync-uri: git://github.com/infirit/mate-community.git
    masters: gentoo
    priority: 50

mv
    location: /var/lib/repos/mv
    sync-type: laymansync
    sync-uri: git://anongit.gentoo.org/user/mv.git
    masters: gentoo
    priority: 50

pentoo
    location: /var/lib/repos/pentoo
    sync-type: laymansync
    sync-uri: git://github.com/pentoo/pentoo-overlay.git
    masters: gentoo
    priority: 50

printer-drivers
    location: /var/lib/repos/printer-drivers
    sync-type: laymansync
    sync-uri: git://anongit.gentoo.org/proj/printer-drivers.git
    masters: gentoo
    priority: 50

rion
    location: /var/lib/repos/rion
    sync-type: laymansync
    sync-uri: git://github.com/rion-overlay/rion-overlay.git
    masters: gentoo
    priority: 50

steam-overlay
    location: /var/lib/repos/steam-overlay
    sync-type: laymansync
    sync-uri: git://github.com/anyc/steam-overlay.git
    masters: gentoo
    priority: 50

tox-overlay
    location: /var/lib/repos/tox-overlay
    sync-type: laymansync
    sync-uri: git://github.com/Tox/gentoo-overlay-tox.git
    masters: gentoo
    priority: 50

wine-a-holics
    location: /var/lib/repos/wine-a-holics
    sync-type: laymansync
    sync-uri: git://github.com/NP-Hardass/wine-a-holics.git
    masters: gentoo
    priority: 50

x11
    location: /var/lib/repos/x11
    sync-type: laymansync
    sync-uri: git://anongit.gentoo.org/proj/x11
    masters: gentoo
    priority: 50

gentoo
    location: /var/lib/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://Portage/gentoo-repo
    priority: 75

gentoo-mate
    location: /var/lib/repos/gentoo-mate
    masters: gentoo
    priority: 80

local
    location: /var/lib/repos/local
    masters: gentoo
    priority: 80

np-hardass-overlay
    location: /var/lib/repos/np-hardass-overlay
    sync-type: git
    sync-uri: https://github.com/NP-Hardass/np-hardass-overlay.git
    masters: gentoo
    priority: 90

wine-overlay
    location: /var/lib/repos/wine-overlay
    sync-type: git
    sync-uri: https://github.com/NP-Hardass/wine-overlay.git
    masters: gentoo
    priority: 90

cvs-workdir
    location: /var/lib/repos/cvs-workdir
    masters: gentoo
    priority: 100

Installed sets: @archive-formats
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -march=native"
DISTDIR="/var/lib/distfiles"
EMERGE_DEFAULT_OPTS=" --verbose=y --quiet-build=y --buildpkg-exclude "virtual/* sys-kernel/*-sources""
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="rsync://mirrors.rit.edu/gentoo/ ftp://mirrors.rit.edu/gentoo/ http://mirrors.rit.edu/gentoo/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j9"
PKGDIR="/var/lib/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="7zip X aac acl acpi aes alsa amd64 avahi avx bash-completion berkdb bluetooth branding bzip2 cairo caja cleartype cli consolekit corefonts cracklib crypt cuda cups curl cxx dbus dell dhcp directfb djvu dri dvb dvd eap-tls epub exif fbcon ffmpeg flac fortran ftp gdbm gif git gnome-keyring gpg gpm gstreamer gtk gtk3 iconv icu ieee1394 ipv6 jpeg jpeg2k kerberos lame laptop lcdfilter ldap libnotify lm_sensors lzma mate mate-keyring matroska mmx mmxext modules mp3 mp4 mpeg multilib ncurses nls nptl nvidia ogg opencl opengl openmp openrc openssl openvpn pam pcre pdf png policykit polkit popcnt postscript qt qt4 qt5 quicktime rar rdesktop readline rtsp samba sasl seccomp session smpeg sse sse2 sse3 sse4_1 sse4_2 ssh ssl ssse3 steamruntime svg tcpd theora threads tiff truetype twolame type1 udev unicode upnp upower v4l v4l2 vaapi vdpau vim-syntax vorbis vpnc wavepack win32codecs x264 x265 xattr xinerama xscreensaver xvid zeroconf zip zlib zsh-completion" ABI_X86="64" ALSA_CARDS="hda-intel usb-audio" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev synaptics mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB en_US ja" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="nvidia intel i915 i965 modesetting vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

SIGSEGV in selinux_setup() (rc-selinux.c:337)

I'm getting a SIGSEGV in this line:

curr_t = xstrdup(context_type_get(curr_con));

The cause is that, context_new() in curr_con = context_new(curr_context); returns 0 when curr_context's value is "invalid" for the function. This is the part in libselinux (2.6) where it gets rejected (context.c:35):

if (count < 2 || count > 5) {	/* might not have a range */
	goto err;
}

The "invalid" value I'm having is "kernel", which as I examined was read from /proc/thread-self/attr/current by getcon()'s subfunctions (see procattr.c:79 of libselinux 2.6). I still have to examine why I'm having this value. I have some idea why but I think it's not yet necessary to mention it here.

But regardless of that, I think OpenRC should add some sanity checks for this to prevent SIGSEGV from happening (basically, if (curr_context == NULL) ... errno ...), and perhaps add some messages so users would get an idea of what's going on. Also, if "kernel" is a valid context, perhaps it should also do something about it, regardless of whether it's caused by a wrong configuration or not.

commit "handle modules comments"

This commit produces actually messages at boot, attempting to load a comment.
I have this on 3 different machines.

c289774

 * Loading module ## ...
 * Failed to load ##
 [ !! ]
 * Loading module ## ...
 * Failed to load ##
 [ !! ]
 * Loading module ## ...
 * Failed to load ##
 [ !! ]
 * Loading module nvidia ...
 * Failed to load nvidia
 [ !! ]
 * Loading module vboxdrv ...
 * Failed to load vboxdrv
 [ !! ]
 * Loading module vboxpci ...
 * Failed to load vboxpci
 [ !! ]
 * Loading module vboxnetadp ...
 * Failed to load vboxnetadp
 [ !! ]
 * Loading module vboxnetflt ...
 * Failed to load vboxnetflt
 [ !! ]
 * Loading module nvidia ...
 [ ok ]
 * Loading module vboxdrv ...
 [ ok ]
 * Loading module vboxnetadp ...
 [ ok ]
 * Loading module vboxpci ...
 [ ok ]
 * Loading module vboxnetflt ...
 [ ok ]

Add SSD_IONICELEVEL env var

SSD_NICELEVEL is nice and all, but start-stop-daemon can also control a daemon's ionice level. It might be nice to have an environment variable that controls IO niceness, too.

rc-service(8) ignores -C option and EINFO_COLOR

The rc-service utility seems to ignore the -C aka. --nocolor it doesn't seem to respect the EINFO_COLOR environment variable either.

When I invoke rc-service -C <existing service> status the output contains colors. If I run rc-service -C <non-existing service> status the out doesn't contain colors. Furthermore, if I run TERM=foo rc-service -C <existing service> status the output doesn't contain colors either.

I am using OpenRC 0.21.3.

tmpfiles.sh: update needed

systemd 209 introduced the concept of unsafe operations for tmpfiles.

systemd/systemd@c4708f1

The operations which should only be executed during boot are appended with an exclamation mark, such as:
r! /tmp/.X[0-9]*-lock

Since tmpfiles.sh doesn't understand this syntax, it is generating warnings such as:

tmpfiles: ignoring invalid entry on line 18 of `/usr/lib/tmpfiles.d//x11.conf'

Note: I am using OpenRC 0.12.4 on Arch Linux.

Directory support for /etc/conf.d/modules?

Would it be possible to support /etc/conf.d/modules being a directory so it can be used with multiple files inside that directory declaring the modules to load vs just the single file it is now?

Remove (useless) ChangeLog

Please remove the useless ChangeLog (nobody wants a plain commit list when anybody have access to that said list), or else, add a proper ChangeLog (which highlights noticeable change between version bumps.)

The current format--commit list--does not satisfy anybody, does it? I mean those who want a ChangeLog but have no use of the current format. Morever, the current format is too big and just conflate the tarball for no purpose at all... but confuse the users that want one--I am one of them.

End result: I am now boycoting, for a few months, newer OpenRC versions if I don't have the time to take care of it to not end up... with unbootable system with bad surprise(s).

Thanks.

Clean up rc-cgroup.sh for clarity

Please, consider this patch in an attempt to clean up rc-cgroup.sh. I've just took a look the other day because I needed to make quick similar file for Supervision-Scripts and had a hard time going trough it because of poor coding style (somewhat confused at times) and bad variable naming scheme.

I suggest as well:
* Renaming cgroup_cleanup() to cgroup_del_service() or cgroup_remove_service() to get more consistency on helpers naming (in par with cgroup_add_service()). This is not done in the current iteration because it would require patching runscripts.sh.
* Use an environment variable--(e.g.) RC_CGROUP_NAME--for the use of 'openrc' group (name.)

Thanks.

(I am opening a bug request because I don't want to clone OpenRC and submit pull requests. Too much has to be done for that end. Moreover, upstream can or could completely ignore it--too much work and troubles for nothing. No thanks, Sir!)

NOTE: This is a copy of bug request.

Process containment using FUSE instead of CGROUP

Currently cgroups is used in systemd/openrc for process containment. Although cgroups is a very easy solution on linux to handle daemon double fork or crash, it seems to be the major stopper for system/openrc to be cross platform.

I'm thinking about an alternative approach for process containment, utilizing the widely accepted FUSE interface in all major unix systems. Below is a brief description:
a). A fuse daemon will providing a special file system, let's say /run/initfs
b). For every daemon which needs to be contained, we can start a helper process first, and open a file in the special file system. For instance, to start apache daemon, we start the helper and create/open a file "/run/initfs/apache". Make sure close-on-exit is NOT set on this file descriptor.
c). Fork-exec to start the daemon. Now we can identify all process with reference to "/run/initfs/apache" as a part of the apache daemon.
d). The initfs could prevent daemons from accidentally closing this fd, by returning error code to "close()" call from clients via fuse api, unless the client process exits.

How do you think?

proposal: transition OpenRC to using the Meson build system

All,

I am interested in transitioning away from the current makefiles OpenRC uses to a build system based on meson [1].

In 0.24, my plan is to make both build systems available and document building OpenRC via meson. Then, at some point in the future, I want to retire the Makefiles.

The possible down side I see is that this will add python 3, ninja and meson as build time dependencies.

The upside is a build system which will handle parallel builds and portability to multiple operating systems better than our current makefiles. Also ninja is much faster than GNU make, so it will decrease build times.

I am opening this issue to gather ideas both for and against this proposal.

[1] http://mesonbuild.com

l10n support (localization, translations, etc...)

Hello friends of the openRC project, greetings from Honduras; i here because I want to support the project with translations into spanish and see what else I could support the project, hoping to give me the space.

Sorry my english is a bit bad, some parts I support in google translate...

Success in the project, the best init.

localmount fails with aufs at shutdown

I am using aufs on manjaro, and aufs leaves a config file in /sys/fs/aufs with the kernel config.
Thus, localmount fails at shutdown, because it doesn't do a directory test.

Something like this should prevent the umounting triggered if a file is present.

for aufs_si_dir in /sys/fs/aufs/*; do
        if [[ -d $aufs_si_dir ]];then
            aufs_mount_dir=${aufs_si_dir#/sys/fs/aufs/}
            aufs_si_id="$(printf "%s" $aufs_mount_dir | sed 's/_/=/g')"
            aufs_mount_point="$(mountinfo -o ${aufs_si_id})"
            for x in $aufs_si_dir/br[000-999]; do
                aufs_branch=$(sed 's/=.*//g' $x)
                eindent
                if ! mount -o "remount,del:$aufs_branch" "$aufs_mount_point" > /dev/null 2>&1; then
                    ewarn "Failed to remove branch $aufs_branch from aufs \
                        $aufs_mount_point"
                fi
                eoutdent
                sync
            done
        fi
    done

agetty login display

I just converted to using agetty in openrc instead of sysvinit's inittab. However there is a visual issue with the agetty login display when run from openrc. What happens is the login prompt is shown in the middle of other text instead of at the end. To get around this I put --delay in my /etc/conf.d/agetty file like so:
agetty_options="--noclear --delay 1"

This does fix the graphical issue of the text overlapping, but introduces a delay every time that I logout of my session.

Is there a better way to fix this without using --delay?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.