Mount can't be used in vservers, but /run is still needed. So we create
the directory and clear it out instead of mounting a tmpfs in that
situation.
reported-by: <patrick@gentoo.org>
X-Gentoo-Bug: 423739
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=423739
We want to lookup the service based on the applet name.
Reported-by: Christian Ruppert <idl0r@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
If you are not using linux, this should not affect you.
If you are using linux, from this point forward, openrc requires the
/run directory to be a mounted tmpfs. If it is, you can run
@LIBEXECDIR@/sh/migrate-to-run.sh as root to migrate your dependency
tree and state information to the new location. If it is not, you must
create the /run directory as root with permissions 755 then reboot your
system.
reported-by: Maxim Kammerer <mk@dee.su>
X-Gentoo-Bug: 401059
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=401059
Many of these helpers are not special to librc, so split them out so they
can be used in all source trees (including libeinfo).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This message was being taken by some users as an error, so I have
removed the part about "skipping..." Hopefully this will make the
message less alarming.
There were a couple of places where we were sourcing functions.sh in
@SYSCONFDIR@/init.d. This is only a backward compatibility symlink, so
it should not be used for openrc. The correct place to source this from
is @LIBEXECDIR@/sh.
We already have a special case for depend processing, so we should
change the working directory there only. This prevents us from forcing
all init scripts to be run in the init directory.
Enter the service directory, like gendeps.sh does, to make sure globs are
expanded in it rather than in /. That makes sure that globbing like "need *"
will end up in all files of the init.d directory.
Signed-off-by: Christian Ruppert <idl0r@gentoo.org>
Reported-by: Guenther Brunthaler <gb_about_gnu@gmx.net>
X-Gentoo-Bug: 412677
X-Gentoo-Bug-URL: https://bugs.gentoo.org/412677
Caused by bug 412589 I was looking at the do_mark_service() function and quickly
found that the segfault is caused by a strlen() call against a NULL pointer.
I also noticed it's using "/exclusive/%s.%s" so svcname.pid, all other functions
are just using the svcname.. So it seems that svcname.pid was/is never used and
thus not necessary at all.
In relation to the above, the if statement in the do_mark_service() function
("if (ok && svcname && strcmp(svcname, service) == 0) {") needs to be
fixed/improved as svcname and service are almost always equal, see my comment in
the function for further details.
Signed-off-by: Christian Ruppert <idl0r@gentoo.org>
Reported-by: Patrick McLean <chutzpah@gentoo.org>
X-Gentoo-Bug: 412589
X-Gentoo-Bug-URL: https://bugs.gentoo.org/412589
sysfs needs to be available before we can check interfaces. On udev
systems this was not a problem, but with mdev/static-dev, there is no
other need for sysfs until later in the init.
X-Gentoo-Bug: 410701
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=410701
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
On linux systems running >=linux-3.2, the /proc/net/dev file cannot be
relied on to show the order network interfaces were added to the system.
Also, there is currently a bug in the implementation of the seek call
for this file which can cause a system to go into an infinite loop.
This commit changes the _ifindex function to retreive the value of
/sys/class/net/${IFACE}/ifindex and use that value instead of attempting
to calculate one from the interface's position in /proc/net/dev.
reported-by: John Keeping <john.keeping@lineone.net>
X-Gentoo-Bug: 410127
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=410127
On linux systems, fsck was not taking into account which filesystems
were local or remote. This commit adds the -t option, with an
appropriate value, to the fsck call so that remote file systems are not
checked.
reported-by: Vladimir Berezhnoy <non7top@gmail.com>
X-Gentoo-Bug: 408363
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=408363
The -q option is not implemented by BusyBox, so instead of using that, make
it so that the standard error is caught, but standard output is thrown
away.
Note: the ordered behaviour of redirection is part of POSIX so we should be
on the safe side with this change, as first we duplicate the output
descriptor to be used as stderr, then we change the output descriptor to
point to NULL.
Signed-off-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
In most cases, changing the MAC on a bond manually is wrong. The bonding
module will do it as needed to failover between interfaces, or to get
multiple interfaces to correctly have the same MAC.
We cannot however enforce it, as there are some corner cases where it is
actually valid (hardware that requires specific MAC configuration, like
some quad-port NICs).
Suggested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
The newer bonding code using sysfs does not clearly show the most common
bond parameter: mode
Also include a path to the referenced kernel documentation for the other
settings.
X-Gentoo-Bug: 408333
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=408333
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Upstream has clarified via IRC:
- hardcoding /usr/lib/ is an explicit choice. It should NOT consider
$libdir at all.
- The z/Z relabel types should call restorecon, not chcon.
- Whitespace is not allowed in tmpfiles.d/*.conf path entries,
but is allowed in globs results. Fixed quoting of path arguments for
this.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
This is the baseline support for tmpfiles.d.
Still missing:
- SELinux relabel, pending upstream clarification
- LIBDIR vs multilib systems, pending upstream clarification
- Whitespace in paths?
- Clean support not implemented
- "x" exclude type not implemented
X-Gentoo-Bug: 396003
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=396003
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
The location of the ifconfig binary has changed in
net-tools-1.60_p20120127084908, and if we do not check both locations
for it, the user will get errors like:
_is_wireless: command not found
_exists: command not found
X-Gentoo-Bug: 407757
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=407757
The commands defined in the extra_commands variable do not depend on
whether the service is stopped or started, so it is valid to run them in
chroot environments.
Also, add a note to the runscript man page about the commands in
extra_commands being able to run whether or not the service is started.
Reported-by: Robin Johnson <robbat2@gentoo.org>
X-Gentoo-Bug: 406713
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=406713
This looks up an option on the kernel command line. For now, itworks on
linux and returns NULL on the bsds, but we are definitely open to
patches for that side.
