watchdog service starts perfectly by '/etc/init.d/watchdog start' but is not started automatically when added to boot or default runlevel with 'rc-update add watchdog default' symlink is created, but the service is not started and even not listed with 'rc-status' I try to play with 'busybox-watchdog' - it's ok and, finally, when I rename '/etc/init.d/watchdog' to '/etc/init.d/awatch' and add it to runlevel, it was started properly at boot. I suppose it is because of the file name, which is started with 'w', being the last script name in alphabetical order.
probably it's not an order issue, because: isida init.d # rc-status -s | grep watchdog busybox-watchdog [ stopped ] isida init.d # mv watchdog watchdoga isida init.d # rc-status -s | grep watchdog busybox-watchdog [ stopped ] watchdoga [ stopped ]
Please post your `emerge --info sys-apps/watchdog' output in a comment.
post the full output of `rc-status -a`
(In reply to comment #2) > Please post your `emerge --info sys-apps/watchdog' output in a comment. isida / # emerge --info sys-apps/watchdog Portage 2.1.11.55 (default/linux/amd64/13.0, gcc-4.7.2, glibc-2.16.0, 3.8.3-k10 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.8.3-k10-x86_64-AMD_Phenom-tm-_II_X6_1045T_Processor-with-gentoo-2.2 KiB Mem: 8154332 total, 7450052 free KiB Swap: 4194300 total, 4194300 free Timestamp of tree: Sun, 10 Mar 2013 17:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p42 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.69 sys-devel/automake: 1.11.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo x-portage ACCEPT_KEYWORDS="amd64 ~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/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="rsync://gentoo.kiev.ua/gentoo-distfiles ftp://gentoo.kiev.ua/ http://gentoo.kiev.ua/ftp/ ftp://portage.org.ua/ http://portage.org.ua/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync4.ua.gentoo.org/gentoo-portage" USE="acl amd64 bash-completion berkdb bindist bzip2 cairo cgi cli cracklib crypt ctype curl curlwrappers cxx dnsdb dovecot-sasl dri exiscan-acl fastcgi ffmpeg fpm ftp gd gdbm geoip gif gnutls gpg gpm iconv imap jpeg lame lm_sensors lzma lzo magemagick maildir mbox mbx mhash mmx modules mudflap multilib mysql mysqli mysqlnd ncurses nls nptl openmp pam pango pcre pdo php png readline rrdcgi sasl session smime smtp spf sqlite sqlite3 sse sse2 sse3 ssl syslog tcpd threads truetype udev unicode vim-syntax x264 xmlreader xmlwriter zip zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" 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" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" 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 ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" 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: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= sys-apps/watchdog-5.13 was built with the following: USE="(multilib) -nfs" ABI_X86="64"
(In reply to comment #3) > post the full output of `rc-status -a` 'awatch' - is renamed 'watchdog' with 'watchdog' name it is not listed in the output isida / # rc-status -a * Caching service dependencies ... [ ok ] Runlevel: shutdown killprocs [ stopped ] savecache [ stopped ] mount-ro [ stopped ] Runlevel: boot hwclock [ started ] sysctl [ started ] modules [ started ] fsck [ started ] root [ started ] mtab [ started ] swap [ started ] localmount [ started ] bootmisc [ started ] termencoding [ started ] swapfiles [ started ] urandom [ started ] net.lo [ started ] keymaps [ started ] procfs [ started ] hostname [ started ] tmpfiles.setup [ started ] Runlevel: sysinit sysfs [ started ] udev-mount [ started ] devfs [ started ] dmesg [ started ] udev [ started ] Runlevel: default syslog-ng [ started ] net.eth0 [ started ] awatch [ started ] exim [ started ] netmount [ started ] nscd [ started ] ntpd [ started ] sshd [ started ] vixie-cron [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed Dynamic Runlevel: manual
here is an output from another gentoo box: takibase / # rc-status -s | grep watch busybox-watchdog [ stopped ] takibase / # ls -la /etc/init.d/ | grep watch -rwxr-xr-x 1 root root 368 Mar 12 01:57 busybox-watchdog -rwxr-xr-x 1 root root 974 Mar 17 01:59 watchdog
takibase / # mv /etc/init.d/watchdog /etc/init.d/watchdoh takibase / # rc-status -s | grep watch watchdoh [ stopped ] busybox-watchdog [ stopped ] LOL...
busybox-watchdog has 'provide watchdog' which causes the main watchdog init.d to "disappear"
(In reply to comment #8) > busybox-watchdog has 'provide watchdog' which causes the main watchdog > init.d to > "disappear" I'm not sure what I can do here. The situation as I see it is you have the busybox-watchdog service script declaring a virtual service "watchdog", then an actual "watchdog" service script. What happens if the watchdog service script is made to provide the watchdog virtual service by adding rc_provide="watchdog" to /etc/conf.d/watchdog?
adding "provide watchdog" statement to '/etc/init.d/watchdog' does not help - rc-* tools does not see it, but removing/changing those statement in '/etc/init.d/busybox-watchdog' actually do the trick.
(In reply to comment #10) > adding "provide watchdog" statement to '/etc/init.d/watchdog' does not help > - rc-* tools does not see it, but removing/changing those statement in > '/etc/init.d/busybox-watchdog' actually do the trick. Try this. Make both watchdog and busybox-watchdog provide a service that isn't called "watchdog", "watch-dog" for example, or rename the "watchdog" init script to something else and make both of them provide watchdog. It seems that a virtual service, like "watchdog" in this example cannot have the same name as a real init script.
if I put "provide watchdog" to '/etc/init.d/watchdog' and "provide busybox-watchdog" to '/etc/init.d/busybox-watchdog' rc-scripts feels happy, though I mentioned it in previous message. But this is merely a workaround, not a bug fix. Something should be done in the core system to work out of the box. busybox-watchdog is pre-installed by default, and when a user installs real watchdog service - it does not work, as in my case. And it takes pretty much time to find the reason.
(In reply to comment #9) i don't think 'provide foo' should white out an actual init.d named 'foo'. this might be how it always worked (it might not, but that doesn't matter), but it's not expected behavior for users. i don't think it's really necessary either.
(In reply to comment #13) > (In reply to comment #9) > > i don't think 'provide foo' should white out an actual init.d named 'foo'. > this might be how it always worked (it might not, but that doesn't matter), > but it's not expected behavior for users. i don't think it's really > necessary either. In this example, you have a virtual "watchdog" service, provided by busybox-watchdog, clashing with a real "watchdog" service from sys-apps/watchdog, since sys-apps/watchdog has an init script. The more I think about this, I think the fix is to add "provide watchdog" to sys-apps/watchdog's init script as well. At that point the user can select the one they want by adding it to a runlevel.
> The more I think about this, I think the fix is to add "provide watchdog" to > sys-apps/watchdog's init script as well. At that point the user can select > the one they want by adding it to a runlevel. When both provide 'watchdog', only busybox-watchdog is visible, so user can't select. takibase ~ # rc-status -s | grep watch busybox-watchdog [ stopped ] takibase ~ # head -n12 /etc/init.d/watchdog #!/sbin/runscript # Copyright 1999-2009 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-apps/watchdog/files/watchdog-init.d,v 1.3 2010/08/24 21:01:50 vapier Exp $ depend() { provide watchdog need localmount use logger } get_config() { takibase ~ # head -n12 /etc/init.d/busybox-watchdog #!/sbin/runscript # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-apps/busybox/files/watchdog.initd,v 1.2 2012/12/21 03:15:28 blueness Exp $ command="/bin/busybox watchdog" command_args="${WATCHDOG_OPTS}" pidfile="/var/run/watchdog.pid" depend() { provide watchdog }
(In reply to comment #15) > > The more I think about this, I think the fix is to add "provide watchdog" to > > sys-apps/watchdog's init script as well. At that point the user can select > > the one they want by adding it to a runlevel. > When both provide 'watchdog', only busybox-watchdog is visible, so user > can't select. > > takibase ~ # rc-status -s | grep watch > busybox-watchdog [ > stopped ] That's the correct output for rc-status, assuming that you only have added busybox-watchdog to the default runlevel. It only shows services that are added to a runlevel. Have you run these two commands to change the service you want to run? rc-update del busybox-watchdog default rc-update add watchdog default > takibase ~ # head -n12 /etc/init.d/watchdog > #!/sbin/runscript > # Copyright 1999-2009 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/sys-apps/watchdog/files/watchdog-init.d,v > 1.3 2010/08/24 21:01:50 vapier Exp $ > > depend() { > provide watchdog > need localmount > use logger > } > > get_config() { > takibase ~ # head -n12 /etc/init.d/busybox-watchdog > #!/sbin/runscript > # Copyright 1999-2012 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/sys-apps/busybox/files/watchdog.initd,v > 1.2 2012/12/21 03:15:28 blueness Exp $ > > command="/bin/busybox watchdog" > command_args="${WATCHDOG_OPTS}" > pidfile="/var/run/watchdog.pid" > > depend() { > provide watchdog > } This bit makes it possible for other services to use the name "watchdog" in their dependencies to refer to either service, so "provide watchdog" should be added to the /etc/init.d/watchdog script.
(In reply to comment #16) > (In reply to comment #15) > > > The more I think about this, I think the fix is to add "provide watchdog" to > > > sys-apps/watchdog's init script as well. At that point the user can select > > > the one they want by adding it to a runlevel. > > When both provide 'watchdog', only busybox-watchdog is visible, so user > > can't select. > > > > takibase ~ # rc-status -s | grep watch > > busybox-watchdog [ > > stopped ] > > That's the correct output for rc-status, assuming that you only have added > busybox-watchdog to the default runlevel. It only shows services that are > added to a runlevel. Have you run these two commands to change the service > you want to run? > > rc-update del busybox-watchdog default > rc-update add watchdog default Make sure you have done this part, that is how you select the service you want to run. I will look further into the rc-status display; I am having trouble reproducing what you are seeing with OpenRc git.
Ok, I get what's happening. Virtual services (names on provide lines) do not show up in rc-status. For example, if you run: rc-status -s | grep logger You get no output, but if you run: grep 'provide logger' /etc/init.d/* you will find that you have at least one provider on your system. There are currently two ways around this: 1. make up a new virtual service name, like watch-dog and use it in the provide lines of both /etc/init.d/busybox-watchdog and /etc/init.d/watchdog. 2. Rename /etc/init.d/watchdog to something else and add the "provide watchdog" line to it. I'm not sure whether it is a good idea to show virtuals in rc-status, because I think that would imply that you can stop or start them directly, which you can't. Thoughts?
I think provided/virtual services should not interfere (and hide) the real scripts I mean, if we have /etc/init.d/FOO which provides 'BAR' and /init/init.d/BAR which also provides 'BAR' first service completely hides the second, and it's bad.
(In reply to comment #19) > I think provided/virtual services should not interfere (and hide) the real > scripts > I mean, if we have > /etc/init.d/FOO which provides 'BAR' > and > /init/init.d/BAR which also provides 'BAR' > > first service completely hides the second, and it's bad. The issue isn't the order of services, but the type of service "bar" is. As soon as bar is seen on a provide line, it is considered a virtual service which then will take precedence over a real service with the same name. That is why you don't see "bar" in status, it is behaving just like any virtual service. You have several of them on your system, such as clock and logger, and none of these show up in rc-status. You can, however, manipulate their providers in rc-update and see which one is started in rc-status. For example, on my system, clock is provided by hwclock and logger by syslog-ng. The long and short is, I don't see a clean way a single name can refer to both a real and a virtual service.
I have added commit 879c7f0 to OpenRc git to clarify this on the man page for runscript. This will be part of OpenRc 0.12.
Great! IMHO, we should also rename the rc-init script for sys-apps/watchdog? '/etc/init.d/watchdogd'?
(In reply to comment #22) > Great! IMHO, we should also rename the rc-init script for sys-apps/watchdog? > '/etc/init.d/watchdogd'? You can do that, or, you can change the provide line in both scripts to be provide watch-dog or something else as long as it is not "watchdog". Either way will fix the issue.
I mean this should be done in Gentoo sources. I'm not a maintainer of watchdog. How to re-assign to somebody, who can?
All, please see comment #18. This is an issue because the busybox-watchdog script has "provide watchdog" in its depend function. This converts the watchdog service to a virtual service and virtual services have to take precedence over real services. The comment I mentioned above proposes two solutions; either of which would work.
imo, this is still wrong behavior when there is a real service however, no script in the tree i can see actually depends on "watchdog", so providing it is useless
should be all set now in the tree; thanks for the report! Commit message: Drop provide watchdog since no other init.d actually depends on this http://sources.gentoo.org/sys-apps/busybox/files/watchdog.initd?r1=1.2&r2=1.3
