Right after reboot, the init-scripts are not working correctly: 1. reboot 2. racoon is running and has pid 3. init-script fails to mark racoon as started cause of already existing pid of racoon Restarting racoon with init-script is not working cause of existing pid. You need to manually killall racoon and start init-script.
Problem was inherited with init-script changes from: https://bugs.gentoo.org/435174
Uhm, wait, what you mean "cause of already existing pid of racoon" — if you're saying that the pid from the previous reboot is already there, that's a problem for most init scripts, that's why /var/run is cleaned up and (in the most recent OpenRC) handled in tmpfs.
(In reply to comment #2) > Uhm, wait, what you mean "cause of already existing pid of racoon" — if > you're saying that the pid from the previous reboot is already there, that's > a problem for most init scripts, that's why /var/run is cleaned up and (in > the most recent OpenRC) handled in tmpfs. No. I mean racoon is running with valid pid-file and the init-script has status "stopped".
(In reply to comment #3) > (In reply to comment #2) > > Uhm, wait, what you mean "cause of already existing pid of racoon" — if > > you're saying that the pid from the previous reboot is already there, that's > > a problem for most init scripts, that's why /var/run is cleaned up and (in > > the most recent OpenRC) handled in tmpfs. > > No. I mean racoon is running with valid pid-file and the init-script has > status "stopped". cilly i haven't been able to reproduce that. How did the valid pid get there? Did you start racoon without the init script?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Uhm, wait, what you mean "cause of already existing pid of racoon" — if > > > you're saying that the pid from the previous reboot is already there, that's > > > a problem for most init scripts, that's why /var/run is cleaned up and (in > > > the most recent OpenRC) handled in tmpfs. > > > > No. I mean racoon is running with valid pid-file and the init-script has > > status "stopped". > > cilly i haven't been able to reproduce that. How did the valid pid get > there? Did you start racoon without the init script? cilly does it happen every time? I think i'm going to set up a vm and just reboot a few times.
Yes it happens every time. The previous init-scripts didn't have the problem.
(In reply to comment #4) > cilly i haven't been able to reproduce that. How did the valid pid get > there? Did you start racoon without the init script? I have no idea how racoon got started, the init-script should start it. I didn't start anything manually.
Do you have the actual message that gets printed? I think I have a hunch of what could be: the time to start racoon might be higher than the default timeout that s-s-d expects so it reports it as failed even though it's started... I got that problem with another service before, the trick is to increase the timeout.
(In reply to comment #8) > Do you have the actual message that gets printed? I think I have a hunch of > what could be: the time to start racoon might be higher than the default > timeout that s-s-d expects so it reports it as failed even though it's > started... I got that problem with another service before, the trick is to > increase the timeout. Sep 18 14:22:49 pluto /etc/init.d/racoon[4284]: start-stop-daemon: did not create a valid pid in `/var/run/racoon.pid' Sep 18 14:22:49 pluto /etc/init.d/racoon[4265]: ERROR: racoon failed to start But that message is bs, since the pid is valid and racoon is running. I don't see the new init-scripts as improvement. Please, make them more solid. Ipsec is an important service for me which must be available right after boot, since I am hosting some clients. So why isn't it working reliably? Is this the new init-system? Or are there missing some checks in the init-script?
> missing some checks in the init-script? cilly, let's test diego's suggestion. Try adding this line: start_stop_daemon_args="--wait 1000" You can add it just before start_pre(), like this: command=/usr/sbin/racoon command_args="-f ${RACOON_CONF} ${RACOON_OPTS}" pidfile=/var/run/racoon.pid start_stop_daemon_args="--wait 1000" If it still doesn't work, try an insanely high value like 10000 just to make sure this isn't the isue.
FWIW without the pidfile checking in s-s-d racoon can crash and you have no way to be notified as OpenRC won't monitor it. That's why I needed those changes. By the way, Anthony, can't you close the depending bug and just have this one open until fixed?
(In reply to comment #10) > > missing some checks in the init-script? > > cilly, let's test diego's suggestion. Try adding this line: > > start_stop_daemon_args="--wait 1000" > > You can add it just before start_pre(), like this: > > command=/usr/sbin/racoon > command_args="-f ${RACOON_CONF} ${RACOON_OPTS}" > pidfile=/var/run/racoon.pid > start_stop_daemon_args="--wait 1000" > > > > > If it still doesn't work, try an insanely high value like 10000 just to make > sure this isn't the isue. This seems to fix it.
(In reply to comment #12) > (In reply to comment #10) > > > missing some checks in the init-script? > > > > cilly, let's test diego's suggestion. Try adding this line: > > > > start_stop_daemon_args="--wait 1000" > > > > You can add it just before start_pre(), like this: > > > > command=/usr/sbin/racoon > > command_args="-f ${RACOON_CONF} ${RACOON_OPTS}" > > pidfile=/var/run/racoon.pid > > start_stop_daemon_args="--wait 1000" > > > > > > > > > > If it still doesn't work, try an insanely high value like 10000 just to make > > sure this isn't the isue. > > This seems to fix it. cilly before I commit this, can you try smaller values and see where it breaks for you. Sorry to throw more work at you but there is a competition here: the longer I make the wait, the greater the guarantee it will work, but the longer the delay in booting/restarting. 1000 = 1 second.
blueness: The value of 1000 = 1 second is okay. With shorter values it sometimes works and sometimes doesn't.
(In reply to comment #14) > blueness: The value of 1000 = 1 second is okay. With shorter values it > sometimes works and sometimes doesn't. Fixed in the tree with ipsec-tools-0.8.0-r5. You can adjust the wait time by editing /etc/conf.d/racoon. I've set the default to RACOON_WAIT="1000" Please test and reopen if there's a problem.
(In reply to comment #15) > (In reply to comment #14) > > blueness: The value of 1000 = 1 second is okay. With shorter values it > > sometimes works and sometimes doesn't. > > Fixed in the tree with ipsec-tools-0.8.0-r5. You can adjust the wait time > by editing /etc/conf.d/racoon. I've set the default to > > RACOON_WAIT="1000" > > Please test and reopen if there's a problem. Working perfectly!
