Waitmax executes program in a new process. If that process does not exit within a certain time, it is being killed with signal TERM. Waitmax is available under GPL Version 2. Reproducible: Always Manpage of waitmax waitmax(1) User commands waitmax(1) NAME waitmax - allow program to run at most a specified amount of time SYNOPSIS waitmax [-s signum] maxtime programm [ args...] DESCRIPTION waitmax executes program in a new process. If process has not exited after at most maxtime seconds, it is being killed with sig~ nal TERM. OPTIONS -s, --signal signum Use signum to kill the program instead of TERM. -h, --help Show short help and exit. -V, --version Show version and exit. EXIT VALUES 255 The program has been signalled and terminated, because the time has elapsed, before the program has exited itself. 254 The program has exited neither by signal nor normally. Strange. This should never happen. 253 The program couldn~t be executed. 128+signum The program has terminated with signal signum before the time has elapsed (not by waitmax, but by itself or some other process). 1 Waitmax has been called with illegal options. CREDITS Many thanks to Jürgen Kuchenbecker, who had the idea of writing such a program and who assisted me in coding and testing it. AUTHOR waitmax was written by Mathias Kettner. The most current source code is located at http://mathias-kettner.de/waitmax.html. waitmax 1.0 March 2008 waitmax(1)
Compiles and runs fine acid@localhost /tmp $ tar -xzf waitmax-1.0.tar.gz acid@localhost /tmp $ cd waitmax-1.0 acid@localhost /tmp/waitmax-1.0 $ ls configure COPYING Makefile waitmax.1 waitmax.c waitmax.spec acid@localhost /tmp/waitmax-1.0 $ ./configure Sorry. This software has no configure-Script Please simply do a 'make' and 'make install make compile software make install install into /usr/bin and /usr/share make DESTDIR=/tmp/hirn install into /tmp/hirn/usr/bin make uninstall remove installed software make rpm create binary RPM package make clean remove created temporary files make distclean remove all created files acid@localhost /tmp/waitmax-1.0 $ make /bin/sh: line 0: type: diet: not found Compiling with normal gcc... echo "Fine. Typing 'make install' as root now will install into /usr/bin" Fine. Typing 'make install' as root now will install into /usr/bin acid@localhost /tmp/waitmax-1.0 $ ls configure COPYING Makefile waitmax waitmax.1 waitmax.c waitmax.spec acid@localhost /tmp/waitmax-1.0 $ ./waitmax 10 sleep 11 acid@localhost /tmp/waitmax-1.0 $ echo $? 255 acid@localhost /tmp/waitmax-1.0 $
Created attachment 147223 [details] Ebuild for waitmax-1.0
Created attachment 284987 [details] updated ebuild eapi bump, avoid dummy configure, patch makefile to to respect $CC etc.
Created attachment 284989 [details] fix a few things in makefile
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/sys-apps/waitmax
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
