Hi! I do have ssmtp set up to use a postfix server for my domain and directed both STDERR and STDOUT to /dev/null so there *should* have been no output to be mailed. To skirt the problem in my post, I decided to use the "autossh" package to do the redialing on ssh and wrapped it in a shell script for the keychain files, called and backgrounded at boot using /etc/rc.local (negating the need for cron to check on the status of the tunnel)
The problem of shell scripts going zombie when invoked by cron in this way still seems unresolved, but if anybody else attempts the same way of doing an automatic ssh reverse tunnel, they won't be left without a solution. Regards, Chris Torsten Giebl wrote: > Hello ! > > > I think i have the same problem as you. When cron starts a cronjob from a > user for example, > that returns more than just a status, for example, wget something, than cron > starts a child process > that is cron <defunced> from the start and exits a few seconds later, even if > the shell script that cron > started is not finished yet. > > I tried a lot of stuff to find a solution. > > 1. > > When you want cron to return a lot of data for exmaple lots of status > messages, > make sure that a mailer daemon like postfix or exim is installed or at least > a sendmail null daemon, if something like this exists. > > 2. > > When i freshly rebooted the system, just stop and start the cron daemon again > one time. > You have to do that after every reboot of course. > > This solved my problems with cron. > > > Hope this helps you too. > > -- cron's immediate child becomes a zombie process https://bugs.launchpad.net/bugs/137785 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
