Re: meta rc-scripts [Re: CHANGE net/samba - drop meta rc-script]
On Wed, Jul 03, 2024 at 11:01:41AM GMT, Stuart Henderson wrote: > On 2024/07/02 20:57, Bjorn Ketelaars wrote: > > The meta rc-script for Samba does not play nice with 'rcctl ls rogue'. > > When a meta script is used, services started by the child scripts are > > seen as rogue [0]. > > There are 5 others of these, and they do encapsulate knowledge of > which order the daemons should be started/stopped in. In the case of > gromox/kopano there are a _lot_ of daemons, and for netatalk the > two separate daemons don't have very memorable names, so they do > add something useful. > > It seems a bit sad to remove meta scripts just because a new thing > was added to daily. > the ls rogue in daily could be removed if it does not really work, until someone fix it
Re: meta rc-scripts [Re: CHANGE net/samba - drop meta rc-script]
> On 3 Jul 2024, at 8:01 pm, Stuart Henderson wrote: > > On 2024/07/02 20:57, Bjorn Ketelaars wrote: >> The meta rc-script for Samba does not play nice with 'rcctl ls rogue'. >> When a meta script is used, services started by the child scripts are >> seen as rogue [0]. > > There are 5 others of these, and they do encapsulate knowledge of > which order the daemons should be started/stopped in. In the case of > gromox/kopano there are a _lot_ of daemons, and for netatalk the > two separate daemons don't have very memorable names, so they do > add something useful. > > It seems a bit sad to remove meta scripts just because a new thing > was added to daily. > That was my initial thought too. My preference is to keep it but if not i have a copy... Ian McWilliam
meta rc-scripts [Re: CHANGE net/samba - drop meta rc-script]
On 2024/07/02 20:57, Bjorn Ketelaars wrote: > The meta rc-script for Samba does not play nice with 'rcctl ls rogue'. > When a meta script is used, services started by the child scripts are > seen as rogue [0]. There are 5 others of these, and they do encapsulate knowledge of which order the daemons should be started/stopped in. In the case of gromox/kopano there are a _lot_ of daemons, and for netatalk the two separate daemons don't have very memorable names, so they do add something useful. It seems a bit sad to remove meta scripts just because a new thing was added to daily.
Re: Dealing with daemons that don't behave like daemons in rc scripts
On Sat, Dec 09, 2023 at 01:03:31PM +, Edd Barrett wrote:
> (If we are fine with the general approach, and if this is something that we
> are
> going to need to do for other ports, perhaps it would be better for rc.d to
> have some kind of built-in support for using a daemon-wrapper? I don't know)
Maybe that'd look something like this:
```
--- rc.subr.origSat Dec 9 18:28:27 2023
+++ rc.subr Sat Dec 9 18:44:51 2023
@@ -174,7 +174,7 @@
}
rc_start() {
- rc_exec "${daemon} ${daemon_flags}"
+ rc_exec "${daemon_wrapper:+${daemon_wrapper} }${daemon} ${daemon_flags}"
}
```
With a rc script looking like this:
```
#!/bin/ksh
daemon="/usr/local/bin/navidrome"
daemon_user="_navidrome"
daemon_flags="-c /etc/navidrome.toml"
daemon_wrapper="/usr/local/sbin/daemon"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_cmd $1
```
(Still doesn't start right when `daemon_logger` is set though)
--
Best Regards
Edd Barrett
https://www.theunixzoo.co.uk
Dealing with daemons that don't behave like daemons in rc scripts
Hi,
I'm in the middle of this ongoing saga to get audio/navidrome to be startable
at boot time via an rc script. Despite the moaning below, I do like it as a
music player/streamer.
The problem: navidrome doesn't behave like a daemon:
- it doesn't setsid(2)
- it doesn't background itself
- it doesn't log to syslog: it logs to stdout
- it dies when sent SIGHUP
This is an unfortunate thing to want to run from an rc script at boot time, as
what seems to happen is:
- rc(8) forks off a navidrome, navidrome starts
- when rc is done starting everything, it exits, taking the controlling
terminal away with it.
- any child that didn't setsid(2) is sent SIGHUP as a result
- navidrome didn't, it dies - amsuingly they bother to catch SIGHUP, but just
exit anyway.
This kind of "daemon" appears to be a trend fuelled by things like systemd,
which are happy to host such services.
Navidrome upstream pointed be at this design principle document they are
following, which AFAICS, is in conflict with traditional daemonisation (it
proposes to run in the foreground and only ever logging to stdout):
https://12factor.net/
I suspect (but have not confirmed) that this same problem that people are
having with node.js daemons:
https://marc.info/?l=openbsd-ports=169583837426245=2
Whether we like it or not, if that's the kind of thing third-party software
wants to do, then what can we do? We can either patch everything that does this
(which is laborious for us), or use a hack like FreeBSD's daemon(8) tool to
first setsid(2) and then exec(3) the software in question:
https://man.freebsd.org/cgi/man.cgi?query=daemon=0=0=FreeBSD+14.0-RELEASE+and+Ports=default=html
There's also this similar (but seemingly unmaintained) "daemonize" tool:
https://linux.die.net/man/1/daemonize
I'm therefore exploring whether we want to try to use a daemon-a-like tool to
help daemonise unwilling programs.
Disclaimer: Nothing you are going to see below is production ready. I'm just
hacking quickly and experimenting to see what works and what doesn't.
After reviewing FreeBSD daemon(8) and daemonize(1), I decided they are too
complicated, and we don't need more than half of their features. I very quickly
put together my own minimal `daemon` program:
https://github.com/vext01/daemon
It just does what sanitisation we can, calls daemon(3) (with `noclose=1` for
now) and execs the program you asked for. A quickly hacked together port is
attached.
Then with the diff below, navidrome can be started at boot time.
With this hack though, for some reason you can't use `daemon_logger` to have
the logs go to syslog. If you try, then the navidrome starts, but `rcctl start`
reports a timeout.
I suspect something clever needs to be done with `pexp` to have `rc_check()`
match when logger(1) is in the mix. I burned a couple of hours trying to figure
this out yesterday and eventually gave up. If someone knowledgeable about rc.d
could help, I'd be most grateful.
But Even without syslog support, at least now you can start the damned thing at
boot!
(If we are fine with the general approach, and if this is something that we are
going to need to do for other ports, perhaps it would be better for rc.d to
have some kind of built-in support for using a daemon-wrapper? I don't know)
What do people think about all of this? Dead end, or worthwhile?
Thanks
Index: Makefile
===
RCS file: /cvs/ports/audio/navidrome/Makefile,v
diff -u -p -r1.16 Makefile
--- Makefile4 Dec 2023 21:06:03 - 1.16
+++ Makefile9 Dec 2023 12:08:46 -
@@ -2,6 +2,7 @@ COMMENT = modern music server and stream
MODGO_MODNAME =github.com/navidrome/navidrome
MODGO_VERSION =v0.50.1
+REVISION = 0
DISTNAME = navidrome-${MODGO_VERSION}
@@ -27,7 +28,8 @@ WANTLIB += ${COMPILER_LIBCXX} pthread z
LIB_DEPENDS = audio/taglib
-RUN_DEPENDS = graphics/ffmpeg
+RUN_DEPENDS = graphics/ffmpeg \
+ sysutils/daemon
MODULES = lang/go
Index: pkg/navidrome.rc
===
RCS file: /cvs/ports/audio/navidrome/pkg/navidrome.rc,v
diff -u -p -r1.3 navidrome.rc
--- pkg/navidrome.rc30 Nov 2023 14:04:10 - 1.3
+++ pkg/navidrome.rc9 Dec 2023 12:08:25 -
@@ -1,12 +1,12 @@
#!/bin/ksh
-daemon="${TRUEPREFIX}/bin/navidrome"
+daemon="${LOCALBASE}/sbin/daemon"
daemon_user="_navidrome"
-daemon_flags="-c ${SYSCONFDIR}/navidrome.toml"
+daemon_flags="${TRUEPREFIX}/bin/navidrome -c ${SYSCONFDIR}/navidrome.toml"
. /etc/rc.d/rc.subr
-rc_bg=YES
+pexp="${daemon_flags}"
rc_reload=NO
rc_cmd $1
--
Best Regards
Edd Barrett
https://www.theunixzoo.co.uk
daemon.tgz
Description: application/tar-gz
Re: MODPY_BIN vs pexp in rc scripts
On Fri, Jan 21, 2022 at 03:55:43PM +0100, Antoine Jacoutot wrote: > On Fri, Jan 21, 2022 at 03:21:04PM +0100, Marc Espie wrote: > > landry@ remarked that MODPY_BIN is probably > > too specific when updating /etc/rc scripts from ports. > > > > (and it's also wrong, because pexp is a regexp) > > > > It should be trivial to add a > > MODPY_PEXP > > variable specifically for that, to facilitate restarts > > after an upgrade > > I don't understand what you mean, could elaborate or give an example please? Brain-fart, I hadn't followed about pexp being properly stored under /var/run/rc, and neither did landry@ There remains the (very pedantic) point that pexp is a regexp, so that in /usr/local/bin/python3.8 The . can stand for "any character"
Re: MODPY_BIN vs pexp in rc scripts
On Fri, Jan 21, 2022 at 03:21:04PM +0100, Marc Espie wrote: > landry@ remarked that MODPY_BIN is probably > too specific when updating /etc/rc scripts from ports. > > (and it's also wrong, because pexp is a regexp) > > It should be trivial to add a > MODPY_PEXP > variable specifically for that, to facilitate restarts > after an upgrade I don't understand what you mean, could elaborate or give an example please? > The question is: what should the pexp for specific > python branches be currently set to ? > > > The current list of affected ports is rather small, looks to be: > > ports/databases/web2ldap > ports/devel/py-buildbot/buildbot > ports/devel/py-buildslave > ports/mail/kopano/core > ports/mail/mailman > ports/net/exabgp > ports/net/synapse > ports/news/sabnzbd > ports/productivity/radicale > ports/productivity/radicale2 > ports/productivity/tryton/5.0/trytond > ports/productivity/tryton/5.2/trytond > ports/security/yubiserve > ports/sysutils/salt > ports/sysutils/supervisor > ports/www/odoo > ports/www/puppetboard > ports/www/trac > -- Antoine
MODPY_BIN vs pexp in rc scripts
landry@ remarked that MODPY_BIN is probably too specific when updating /etc/rc scripts from ports. (and it's also wrong, because pexp is a regexp) It should be trivial to add a MODPY_PEXP variable specifically for that, to facilitate restarts after an upgrade The question is: what should the pexp for specific python branches be currently set to ? The current list of affected ports is rather small, looks to be: ports/databases/web2ldap ports/devel/py-buildbot/buildbot ports/devel/py-buildslave ports/mail/kopano/core ports/mail/mailman ports/net/exabgp ports/net/synapse ports/news/sabnzbd ports/productivity/radicale ports/productivity/radicale2 ports/productivity/tryton/5.0/trytond ports/productivity/tryton/5.2/trytond ports/security/yubiserve ports/sysutils/salt ports/sysutils/supervisor ports/www/odoo ports/www/puppetboard ports/www/trac
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
Hi Landry, Buildbot won't start from rc scripts anyway during system boot process automatically. I tried to run it by setting: rcctl enable buildbot ... stating network daemons: sshd bgpd relayd dhcpd smtpd vmd sndiod. starting package daemons: buildbot(failed). ... But it runs successfully manually from fully booted system by command even after buildbot(failed) return: rcctl start buildbot buildbot(failed) rcctl check buildbot buildbot(ok) I think it could be timeout because of long time needed to start buildbot. Could you check this to confirm? Do you think can it be solved? Martin ‐‐‐ Original Message ‐‐‐ On Thursday, July 23, 2020 8:17 AM, Martin wrote: > I confirm buildbot-worker works since automat has been updated to > py-automat-0.8.0. > > Great job, Landry! > > Martin > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, July 22, 2020 7:18 PM, Landry Breuil lan...@openbsd.org wrote: > > > On Wed, Jul 22, 2020 at 12:59:44PM +, Martin wrote: > > > > > It seems latest py-automat-20.2.0 should be used with updated > > > py-setuptools-49.x to run buildbot-worker correctly. > > > > good catch, i think 0.8.0 is enough per > > https://github.com/buildbot/buildbot/commit/a89eddb4acfdaa23bcb53806674a960e28cfccc1 > > > > - that's probably the switch to python 3.8 that broke it. > > Landry > >
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
On 2020/08/28 11:55, Landry Breuil wrote: > On Fri, Aug 28, 2020 at 09:46:31AM +, Martin wrote: > > Hi Landry, > > > > Buildbot won't start from rc scripts anyway during system boot process > > automatically. > > I tried to run it by setting: > > > > rcctl enable buildbot > > > > ... > > stating network daemons: sshd bgpd relayd dhcpd smtpd vmd sndiod. > > starting package daemons: buildbot(failed). > > ... > > > > But it runs successfully manually from fully booted system by command even > > after buildbot(failed) return: > > > > rcctl start buildbot > > buildbot(failed) > > rcctl check buildbot > > buildbot(ok) > > check twistd.log for details in buildbot workdir, and check the list of > processes running matching the pexep, ie > > pgrep -f '/usr/local/bin/python3.8 .*logfile=twistd.log --python=buildbot.tac' > > > I think it could be timeout because of long time needed to start buildbot. > > the default timeout set by rc.subr is 30s; check if adding > daemon_timeout=60 to /etc/rc.d/buildbot helps. In my experience it didnt > change anything. don't modify rc.d/buildbot, just set buildbot_timeout=60 in rc.conf.local > > > Could you check this to confirm? > > Do you think can it be solved? > > Dunno without more details. >
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
On Fri, Aug 28, 2020 at 09:46:31AM +, Martin wrote: > Hi Landry, > > Buildbot won't start from rc scripts anyway during system boot process > automatically. > I tried to run it by setting: > > rcctl enable buildbot > > ... > stating network daemons: sshd bgpd relayd dhcpd smtpd vmd sndiod. > starting package daemons: buildbot(failed). > ... > > But it runs successfully manually from fully booted system by command even > after buildbot(failed) return: > > rcctl start buildbot > buildbot(failed) > rcctl check buildbot > buildbot(ok) check twistd.log for details in buildbot workdir, and check the list of processes running matching the pexep, ie pgrep -f '/usr/local/bin/python3.8 .*logfile=twistd.log --python=buildbot.tac' > I think it could be timeout because of long time needed to start buildbot. the default timeout set by rc.subr is 30s; check if adding daemon_timeout=60 to /etc/rc.d/buildbot helps. In my experience it didnt change anything. > Could you check this to confirm? > Do you think can it be solved? Dunno without more details.
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
I confirm buildbot-worker works since automat has been updated to py-automat-0.8.0. Great job, Landry! Martin ‐‐‐ Original Message ‐‐‐ On Wednesday, July 22, 2020 7:18 PM, Landry Breuil wrote: > On Wed, Jul 22, 2020 at 12:59:44PM +, Martin wrote: > > > It seems latest py-automat-20.2.0 should be used with updated > > py-setuptools-49.x to run buildbot-worker correctly. > > good catch, i think 0.8.0 is enough per > https://github.com/buildbot/buildbot/commit/a89eddb4acfdaa23bcb53806674a960e28cfccc1 > > - that's probably the switch to python 3.8 that broke it. > > Landry >
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
On Wed, Jul 22, 2020 at 12:59:44PM +, Martin wrote: > It seems latest py-automat-20.2.0 should be used with updated > py-setuptools-49.x to run buildbot-worker correctly. good catch, i think 0.8.0 is enough per https://github.com/buildbot/buildbot/commit/a89eddb4acfdaa23bcb53806674a960e28cfccc1 - that's probably the switch to python 3.8 that broke it. Landry
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
It seems latest py-automat-20.2.0 should be used with updated py-setuptools-49.x to run buildbot-worker correctly. Martin ‐‐‐ Original Message ‐‐‐ On Monday, July 20, 2020 8:45 PM, Martin wrote: > Master has been created in /var/buildbot by: > > buildbot create-master master > buildbot start master > works. > > But I can't start Buildbot by > rcctl start buildbot > > Any suggestions? > > Martin
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
Landry, thanks for reply.
Buildbot now starts from rc scripts successfully. It was /var/buildbot folder
contents permissions problem.
But now I'm stuck with buildbot-worker built from -current.
I've just created a worker by commands from README:
su -m _buildslave -c "buildbot-worker create-worker /var/buildslave localhost
worker-obsd test
Worker created successfully.
When I try to start it:
# rcctl -d start buildbot_worker
doing _rc_parse_conf
doing _rc_quirks
buildbot_sorker_flags empty, using default >/var/buildslave<
doing rc_check
buildbot_worker
doing rc_start
doing_rc_wait start
doing rc_check
doing rc_check
Alarm clock
/etc/rc.d/buildbot_worker: kill: 2092: Nosuch process
doing _rc_write_runfile
(ok)
Nothing started since then.
# cat twisted.log show some errors with automat (py3-twisted-20.3.0p0,
py3-automaat-0.6.0p1):
2020-07-22 11:08:58+ [-] Loading buildbot.tac...
2020-07-22 11:08:59+ [-] Loaded.
2020-07-22 11:08:59+ [-] twistd 20.3.0 (/usr/local/bin/python3.8 3.8.3)
starting up.
2020-07-22 11:08:59+ [-] reactor class:
twisted.internet.pollreactor.PollReactor.
2020-07-22 11:08:59+ [-] Starting Worker -- version: 2.8.1
2020-07-22 11:08:59+ [-] recording hostname in twistd.hostname
2020-07-22 11:08:59+ [-] Traceback (most recent call last):
2020-07-22 11:08:59+ [-] File "/usr/local/bin/buildbot-worker", line 11,
in
2020-07-22 11:08:59+ [-] load_entry_point('buildbot-worker==2.8.1',
'console_scripts', 'buildbot-worker')()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/scripts/runner.py",
line 266, in run
2020-07-22 11:08:59+ [-] sys.exit(subcommandFunction(subconfig))
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/scripts/start.py", line
80, in startCommand
2020-07-22 11:08:59+ [-] return startWorker(basedir, config['quiet'],
config['nodaemon'])
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/scripts/start.py", line
103, in startWorker
2020-07-22 11:08:59+ [-] return launch(nodaemon)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/scripts/start.py", line
142, in launch
2020-07-22 11:08:59+ [-] run()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/scripts/twistd.py", line 31, in
run
2020-07-22 11:08:59+ [-] app.run(runApp, ServerOptions)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/app.py", line 674,
in run
2020-07-22 11:08:59+ [-] runApp(config)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/scripts/twistd.py", line 25, in
runApp
2020-07-22 11:08:59+ [-] runner.run()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/app.py", line 385,
in run
2020-07-22 11:08:59+ [-] self.postApplication()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/scripts/_twistd_unix.py", line
254, in postApplication
2020-07-22 11:08:59+ [-] self.startApplication(self.application)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/scripts/_twistd_unix.py", line
453, in startApplication
2020-07-22 11:08:59+ [-] app.startApplication(application, not
self.config['no_save'])
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/app.py", line 690,
in startApplication
2020-07-22 11:08:59+ [-] service.IService(application).startService()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/service.py", line
288, in startService
2020-07-22 11:08:59+ [-] service.startService()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/pb.py", line 236, in
startService
2020-07-22 11:08:59+ [-] WorkerBase.startService(self)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/buildbot_worker/base.py", line 418, in
startService
2020-07-22 11:08:59+ [-] service.MultiService.startService(self)
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/service.py", line
288, in startService
2020-07-22 11:08:59+ [-] service.startService()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/twisted/application/internet.py", line
1138, in startService
2020-07-22 11:08:59+ [-] self._machine.start()
2020-07-22 11:08:59+ [-] File
"/usr/local/lib/python3.8/site-packages/automat/_methodical.py", line 126, in
__get__
2020-07-22
Re: Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
On Mon, Jul 20, 2020 at 08:45:53PM +, Martin wrote: > Master has been created in /var/buildbot by: > > buildbot create-master master > buildbot start master > works. > > But I can't start Buildbot by > rcctl start buildbot > > Any suggestions? rcctl -d start buildbot, and look at /var/buildbot/twistd.log ? maybe you didnt follow readme, which advised to run those commands as _buildbot user, and now perms dont match what's expected ?
Can not start Buildbot by rc scripts, but 'buildbot start master' works (built from -current)
Master has been created in /var/buildbot by: buildbot create-master master buildbot start master works. But I can't start Buildbot by rcctl start buildbot Any suggestions? Martin
Re: isc-dhcp: add rc scripts, etc.
On 11 okt 2014, at 14:42, Stuart Henderson st...@openbsd.org wrote: OK? (Jakob, do you want to remain listed as maintainer of this?) Nah, you can remove me. jakob
isc-dhcp: add rc scripts, etc.
Adds rc scripts for isc-dhcpd, isc-dhcrelay.
Adds a dedicated userid for the isc-dhcpd script.
Turn off groff, there are now only whitespace changes.
OK? (Jakob, do you want to remain listed as maintainer of this?)
Index: infrastructure/db/user.list
===
RCS file: /cvs/ports/infrastructure/db/user.list,v
retrieving revision 1.237
diff -u -p -r1.237 user.list
--- infrastructure/db/user.list 3 Oct 2014 11:29:34 - 1.237
+++ infrastructure/db/user.list 11 Oct 2014 12:40:09 -
@@ -252,3 +252,4 @@ id usergroup port options
741 _bind _bind net/isc-bind
742 _restund _restundtelephony/baresip/restund
743 _gdnsd _gdnsd net/gdnsd
+744 _isc-dhcp _isc-dhcp net/isc-dhcp
Index: net/isc-dhcp/Makefile
===
RCS file: /cvs/ports/net/isc-dhcp/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- net/isc-dhcp/Makefile 23 Sep 2014 10:13:40 - 1.35
+++ net/isc-dhcp/Makefile 11 Oct 2014 12:40:09 -
@@ -5,6 +5,7 @@ COMMENT-client= ISC DHCP Client
COMMENT-omapi= ISC DHCP OMAPI
VERSION= 4.3.1
+REVISION= 0
DISTNAME= isc-dhcp-${VERSION}
PKGNAME= isc-dhcp-${VERSION:S/-P/./}
PKGNAME-main= isc-dhcp-server-${VERSION:S/-P/./}
@@ -29,7 +30,6 @@ WANTLIB= c
MULTI_PACKAGES=-main -omapi -client
-USE_GROFF= Yes
USE_GMAKE= Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-early-chroot \
Index: net/isc-dhcp/pkg/PLIST-main
===
RCS file: /cvs/ports/net/isc-dhcp/pkg/PLIST-main,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST-main
--- net/isc-dhcp/pkg/PLIST-main 14 Jan 2012 12:43:25 - 1.4
+++ net/isc-dhcp/pkg/PLIST-main 11 Oct 2014 12:40:09 -
@@ -1,4 +1,6 @@
@comment $OpenBSD: PLIST-main,v 1.4 2012/01/14 12:43:25 sthen Exp $
+@newgroup _isc-dhcp:744
+@newuser _isc-dhcp:744:_isc-dhcp:daemon:ISC DHCP
user:/nonexistent:/sbin/nologin
@conflict isc-dhcp-*
@pkgpath net/isc-dhcp
@man man/man5/dhcp-eval.5
@@ -12,3 +14,5 @@
share/examples/isc-dhcp/
share/examples/isc-dhcp/dhcpd.conf
@extra /var/db/dhcpd.leases
+@rcscript ${RCDIR}/isc_dhcpd
+@rcscript ${RCDIR}/isc_dhcrelay
Index: net/isc-dhcp/pkg/isc_dhcpd.rc
===
RCS file: net/isc-dhcp/pkg/isc_dhcpd.rc
diff -N net/isc-dhcp/pkg/isc_dhcpd.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/isc-dhcp/pkg/isc_dhcpd.rc 11 Oct 2014 12:40:09 -
@@ -0,0 +1,12 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+daemon=${TRUEPREFIX}/sbin/dhcpd
+daemon_flags=-user _isc-dhcp -group _isc-dhcp
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+
+rc_cmd $1
Index: net/isc-dhcp/pkg/isc_dhcrelay.rc
===
RCS file: net/isc-dhcp/pkg/isc_dhcrelay.rc
diff -N net/isc-dhcp/pkg/isc_dhcrelay.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ net/isc-dhcp/pkg/isc_dhcrelay.rc11 Oct 2014 12:40:09 -
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+daemon=${TRUEPREFIX}/sbin/dhcrelay
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+
+rc_cmd $1
Re: Deconflict rc scripts of base httpd and apache-httpd-openbsd
s/pprobably/probably/ in current.HTML, otherwise OK.
On 26 July 2014 20:09:45 BST, Matthias Kilian k...@outback.escape.de wrote:
On Sat, Jul 26, 2014 at 08:46:41PM +0200, Matthias Kilian wrote:
[...]
And here's the diff for current.html:
And now with a working link to pkg_add(1):
Index: faq/current.html
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.532
diff -u -p -r1.532 current.html
--- faq/current.html 24 Jul 2014 17:48:08 - 1.532
+++ faq/current.html 26 Jul 2014 19:08:42 -
@@ -65,6 +65,7 @@
lia href=#201407162014/07/16 - lynx(1) moved to ports/a
lia href=#201407222014/07/22 - [ports] Increased file descriptor
use in KDE4/a
lia href=#201407232014/07/23 - Changes to /etc infrastructure/a
+lia href=#201407262014/07/26 - rc scripts of both apache
webservers renamed/a
/ul
@@ -694,6 +695,23 @@ additional log sockets in most cases, so
removed:
pre
syslogd_flags=${syslogd_flags} -a /path/to/dev/log
+/pre
+
+a name=20140726/a
+h32014/07/26 - [ports] rc scripts of both apache webservers
renamed/h3
+The rc scripts of the apache-httpd-openbsd and apache-httpd packages
had
+been renamed from httpd to apache resp. httpd2 to apache2, to avoid
+conflicts with the base httpd.
+If you're running one or both of them, you have to replace httpd
+by apache in your pkg_scripts and httpd?_flags entries.
+p
+After upgrading the apache-httpd-openbsd package, you'll also have to
bring
+the rc script of the base http, which
+a
href=http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_addsektion=1;pkg_add(1)/a
+has moved out of the way, and you should remove partial package
pprobably left around:
+pre
+ mv -i /etc/rc.d/httpd.* /etc/rc.d/httpd
+ pkg_delete partial-apache-httpd-openbsd
/pre
hr
--
Sent from a phone, please excuse the formatting.
Deconflict rc scripts of base httpd and apache-httpd-openbsd
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.532
diff -u -p -r1.532 current.html
--- faq/current.html24 Jul 2014 17:48:08 - 1.532
+++ faq/current.html26 Jul 2014 18:41:49 -
@@ -65,6 +65,7 @@
lia href=#201407162014/07/16 - lynx(1) moved to ports/a
lia href=#201407222014/07/22 - [ports] Increased file descriptor use in
KDE4/a
lia href=#201407232014/07/23 - Changes to /etc infrastructure/a
+lia href=#201407262014/07/26 - rc scripts of both apache webservers
renamed/a
/ul
@@ -694,6 +695,23 @@ additional log sockets in most cases, so
removed:
pre
syslogd_flags=${syslogd_flags} -a /path/to/dev/log
+/pre
+
+a name=20140726/a
+h32014/07/26 - [ports] rc scripts of both apache webservers renamed/h3
+The rc scripts of the apache-httpd-openbsd and apache-httpd packages had
+been renamed from httpd to apache resp. httpd2 to apache2, to avoid
+conflicts with the base httpd.
+If you're running one or both of them, you have to replace httpd
+by apache in your pkg_scripts and httpd?_flags entries.
+p
+After upgrading the apache-httpd-openbsd package, you'll also have to bring
+the rc script of the base http, which
+a
href=http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_configsektion=8;pkg_add(8)/a
+has moved out of the way, and you should remove partial package pprobably left
around:
+pre
+ mv -i /etc/rc.d/httpd.* /etc/rc.d/httpd
+ pkg_delete partial-apache-httpd-openbsd
/pre
hr
Re: Deconflict rc scripts of base httpd and apache-httpd-openbsd
On Sat, Jul 26, 2014 at 08:46:41PM +0200, Matthias Kilian wrote:
[...]
And here's the diff for current.html:
And now with a working link to pkg_add(1):
Index: faq/current.html
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.532
diff -u -p -r1.532 current.html
--- faq/current.html24 Jul 2014 17:48:08 - 1.532
+++ faq/current.html26 Jul 2014 19:08:42 -
@@ -65,6 +65,7 @@
lia href=#201407162014/07/16 - lynx(1) moved to ports/a
lia href=#201407222014/07/22 - [ports] Increased file descriptor use in
KDE4/a
lia href=#201407232014/07/23 - Changes to /etc infrastructure/a
+lia href=#201407262014/07/26 - rc scripts of both apache webservers
renamed/a
/ul
@@ -694,6 +695,23 @@ additional log sockets in most cases, so
removed:
pre
syslogd_flags=${syslogd_flags} -a /path/to/dev/log
+/pre
+
+a name=20140726/a
+h32014/07/26 - [ports] rc scripts of both apache webservers renamed/h3
+The rc scripts of the apache-httpd-openbsd and apache-httpd packages had
+been renamed from httpd to apache resp. httpd2 to apache2, to avoid
+conflicts with the base httpd.
+If you're running one or both of them, you have to replace httpd
+by apache in your pkg_scripts and httpd?_flags entries.
+p
+After upgrading the apache-httpd-openbsd package, you'll also have to bring
+the rc script of the base http, which
+a
href=http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_addsektion=1;pkg_add(1)/a
+has moved out of the way, and you should remove partial package pprobably left
around:
+pre
+ mv -i /etc/rc.d/httpd.* /etc/rc.d/httpd
+ pkg_delete partial-apache-httpd-openbsd
/pre
hr
Re: rc scripts
On Thu, Jul 03, 2014 at 02:13:46PM +1000, Ian McWilliam wrote:
Hi all,
Need some advice on the rc script infrastructure and the best way to detect
running processes.
is some like the following acceptable practice or are there some existing
functions that will do the
equivalent.
rc_pre() {
pgrep -fq ${TRUEPREFIX}/bin/samba
if [[ $? == 0 ]]; then
rc_err $0: Cannot run while AD Server Running
fi
}
I am not sure what you are looking for here. You want to make sure one cannot
start samba if it's already running?
If so, rc_check() does what you want. If you meant something else, please
elaborate :-)
Secondly is it acceptable to create a common rc script to hold common subs
used amongst multiple rc
script for a port, eg samba.subr that will be used by smbd and nmbd rc
scripts?
No, the only time we use a common rc script is to start all processes of a
common package (like we do with samba3 already).
--
Antoine
Re: rc scripts
On Thu, Jul 3rd, 2014 at 4:07 PM, Antoine Jacoutot ajacou...@bsdfrog.org
wrote:
On Thu, Jul 03, 2014 at 02:13:46PM +1000, Ian McWilliam wrote:
Hi all,
Need some advice on the rc script infrastructure and the best way to
detect running processes.
is some like the following acceptable practice or are there some
existing functions that will do the
equivalent.
rc_pre() {
pgrep -fq ${TRUEPREFIX}/bin/samba
if [[ $? == 0 ]]; then
rc_err $0: Cannot run while AD Server Running
fi
}
I am not sure what you are looking for here. You want to make sure one
cannot start samba if it's already running?
If so, rc_check() does what you want. If you meant something else, please
elaborate :-)
OK. Samba4 contains the /usr/local/bin/samba which is the full blown Active
Directory Server.
The RC script for that (when I write it) will need checks to make sure that
smbd / nmbd / winbindd are
not running as those daemons are not used in an ADS setup.
The above example is to check when starting the old file / print / winbind
servers that the ADS server
is not running incase you accentually started any of them while running an ADS
setup.
For those people just wanting smb file / print services or the old NT domain
setup, you can still use
smbd / nmbd / winbind.
Hope that describes the scenarios that the samba4 stuff will give us.
Secondly is it acceptable to create a common rc script to hold common
subs used amongst multiple rc
script for a port, eg samba.subr that will be used by smbd and nmbd rc
scripts?
No, the only time we use a common rc script is to start all processes of a
common package (like we do with samba3 already).
OK, in that case, common functions will be duplicated 3 times in each of the
smbd, nmbd, winbindd rc
scripts.
--
Ian McWilliam
Re: rc scripts
OK. Samba4 contains the /usr/local/bin/samba which is the full blown Active Directory Server. The RC script for that (when I write it) will need checks to make sure that smbd / nmbd / winbindd are not running as those daemons are not used in an ADS setup. The above example is to check when starting the old file / print / winbind servers that the ADS server is not running incase you accentually started any of them while running an ADS setup. For those people just wanting smb file / print services or the old NT domain setup, you can still use smbd / nmbd / winbind. Hope that describes the scenarios that the samba4 stuff will give us. It does indeed. Ok then what you came up with is ok. At least, rc_pre() is the correct function to do that kind of checks. But you may want to use '/etc/rc.d/smbd check' ... instead. Secondly is it acceptable to create a common rc script to hold common subs used amongst multiple rc script for a port, eg samba.subr that will be used by smbd and nmbd rc scripts? No, the only time we use a common rc script is to start all processes of a common package (like we do with samba3 already). OK, in that case, common functions will be duplicated 3 times in each of the smbd, nmbd, winbindd rc scripts. What functions exactly? Sorry if I sound dumb but you did not provide much details and samba3 rc scripts don't seem to share any function. -- Antoine
Re: rc scripts
On 2014/07/03 16:23, Ian McWilliam wrote: OK, in that case, common functions will be duplicated 3 times in each of the smbd, nmbd, winbindd rc scripts. rc scripts shouldn't be complicated/long enough that the duplication is a problem :)
Re: rc scripts
On 2014-07-03 Thu 16:23 PM |, Ian McWilliam wrote: OK. Samba4 contains the /usr/local/bin/samba which is the full blown Active Directory Server. The RC script for that (when I write it) will need checks to make sure that smbd / nmbd / winbindd are not running as those daemons are not used in an ADS setup. They can also be started from /etc/inetd.conf
Re: rc scripts
On 2014-07-03 Thu 14:13 PM |, Ian McWilliam wrote: Secondly is it acceptable to create a common rc script to hold common subs used amongst multiple rc script for a port, eg samba.subr that will be used by smbd and nmbd rc scripts? . /usr/local/libexec/samba-control ?
Re: rc scripts
On 3/07/2014 8:29 PM, Craig R. Skinner wrote: On 2014-07-03 Thu 16:23 PM |, Ian McWilliam wrote: OK. Samba4 contains the /usr/local/bin/samba which is the full blown Active Directory Server. The RC script for that (when I write it) will need checks to make sure that smbd / nmbd / winbindd are not running as those daemons are not used in an ADS setup. They can also be started from /etc/inetd.conf Sure. If you want to run them that way, your on your own. I wouldn't recommend that unless your a masochist Ian McWilliam
rc scripts
Hi all,
Need some advice on the rc script infrastructure and the best way to detect
running processes.
is some like the following acceptable practice or are there some existing
functions that will do the
equivalent.
rc_pre() {
pgrep -fq ${TRUEPREFIX}/bin/samba
if [[ $? == 0 ]]; then
rc_err $0: Cannot run while AD Server Running
fi
}
Secondly is it acceptable to create a common rc script to hold common subs used
amongst multiple rc
script for a port, eg samba.subr that will be used by smbd and nmbd rc scripts?
Any thoughts / ideas appreciated.
--
Ian McWilliam
rc scripts for ejabberd and prosody
Those need more love, but I've been unable to give it to them recently so I'm sending to the list, maybe someone will manage to push it further and update with changes that were made in the mean time to our tree. My work is available in https://github.com/jasperla/openbsd-wip/tree/master/net/ejabberd and https://github.com/jasperla/openbsd-wip/tree/master/net/prosody -- viq pgpci1GKD95xj.pgp Description: PGP signature
rc scripts
hi there,
i am confused about the rc scripts.
existing ports have pkg/daemon.rc files and a
@rcscript ${RCDIR}/daemon
line in PLIST
pkg_create(1) says:
@rcscript filename
Script for the /etc/rc.d framework. Contrary to @file, absolute
paths are okay, e.g.,
@rcscript ${RCDIR}/ballsd
In this case, performs an implicit @cwd to ${RCDIR}.
this is not very helpful without the most important part that is in
the porting handbook FAQ:
1. The script has to be placed into ${PKGDIR} with a .rc extension, like
mpd.rc. This will allow the package tools to pick it up.
also, some ports have executable pkg/*.rc file, some dont.
what's the policy on that?
now on to my problem :]
$ cat pkg/tinyproxy.rc
#!/bin/sh
#
# $OpenBSD$
daemon=${TRUEPREFIX}/sbin/tinyproxy
. /etc/rc.d/rc.subr
rc_cmd $1
$ cat PLIST
@comment $OpenBSD$
@newgroup _tinyproxy:617
@newuser _tinyproxy:617:_tinyproxy:daemon:tinyproxy:/nonexistent:/sbin/nologin
@man man/man5/tinyproxy.conf.5
@man man/man8/tinyproxy.8
@bin sbin/tinyproxy
share/examples/tinyproxy/
share/examples/tinyproxy/tinyproxy.conf
@sample ${SYSCONFDIR}/tinyproxy.conf
share/tinyproxy/
share/tinyproxy/debug.html
share/tinyproxy/default.html
share/tinyproxy/stats.html
@rcscript ${RCDIR}/tinyproxy
but whenever i make make update-plist after make fake, i get:
=== Updating plist for tinyproxy-1.8.3
Scanning destdir
Getting old lists
1st pass identifying files
Attaching annotations
Sorting out destdir files
/etc/rc.d/tinyproxy does not belong
/etc/tinyproxy.conf does not belong
pkg/PLIST changed
and the @rcscript line is removed from the new PLIST.
$ diff -u PLIST.orig PLIST
--- PLIST.orig Thu Oct 13 23:14:12 2011
+++ PLIST Thu Oct 13 23:15:57 2011
@@ -11,4 +11,3 @@
share/tinyproxy/debug.html
share/tinyproxy/default.html
share/tinyproxy/stats.html
-@rcscript ${RCDIR}/tinyproxy
what am i doing wrong?
-f
--
to live is to risk dying.
Re: rc scripts
On Thu, 13 Oct 2011, frantisek holop wrote:
also, some ports have executable pkg/*.rc file, some dont.
what's the policy on that?
What do you mean?
now on to my problem :]
snip
but whenever i make make update-plist after make fake, i get:
=== Updating plist for tinyproxy-1.8.3
Scanning destdir
Getting old lists
1st pass identifying files
Attaching annotations
Sorting out destdir files
/etc/rc.d/tinyproxy does not belong
/etc/tinyproxy.conf does not belong
pkg/PLIST changed
and the @rcscript line is removed from the new PLIST.
$ diff -u PLIST.orig PLIST
--- PLIST.orig Thu Oct 13 23:14:12 2011
+++ PLIST Thu Oct 13 23:15:57 2011
@@ -11,4 +11,3 @@
share/tinyproxy/debug.html
share/tinyproxy/default.html
share/tinyproxy/stats.html
-@rcscript ${RCDIR}/tinyproxy
what am i doing wrong?
Nothing, it's an known year old bug in make plist.
--
Antoine
Re: rc scripts
hmm, on Thu, Oct 13, 2011 at 11:49:32PM +0200, Antoine Jacoutot said that
On Thu, 13 Oct 2011, frantisek holop wrote:
also, some ports have executable pkg/*.rc file, some dont.
what's the policy on that?
What do you mean?
-rwxr-xr-x 1 root wheel 267 Apr 9 2011 /usr/ports/www/nginx/pkg/nginx.rc*
-rw-rw-r-- 1 root wheel 279 Mar 17 2011
/usr/ports/net/avahi/pkg/avahi_daemon.rc
-rw-rw-r-- 1 root wheel 284 Mar 17 2011
/usr/ports/net/avahi/pkg/avahi_dnsconfd.rc
and so on...
+++ PLIST Thu Oct 13 23:15:57 2011
@@ -11,4 +11,3 @@
share/tinyproxy/debug.html
share/tinyproxy/default.html
share/tinyproxy/stats.html
-@rcscript ${RCDIR}/tinyproxy
what am i doing wrong?
Nothing, it's an known year old bug in make plist.
doh
-f
--
there are no esc keys on prison pcs.
Re: rc scripts
On Fri, 14 Oct 2011, frantisek holop wrote: hmm, on Thu, Oct 13, 2011 at 11:49:32PM +0200, Antoine Jacoutot said that On Thu, 13 Oct 2011, frantisek holop wrote: also, some ports have executable pkg/*.rc file, some dont. what's the policy on that? What do you mean? -rwxr-xr-x 1 root wheel 267 Apr 9 2011 /usr/ports/www/nginx/pkg/nginx.rc* -rw-rw-r-- 1 root wheel 279 Mar 17 2011 /usr/ports/net/avahi/pkg/avahi_daemon.rc -rw-rw-r-- 1 root wheel 284 Mar 17 2011 /usr/ports/net/avahi/pkg/avahi_dnsconfd.rc and so on... That doesn't matter how they are in the cvs repo. If you look at /etc/rc.d they are all installed 555. -- Antoine
New tomcat diff (rc scripts)
The following diff add a rc script and zap some stuff that now has
become useless.
thoroughly tested; have a look at it.
ciao,
David
Index: v5/Makefile
===
RCS file: /cvs/ports/www/tomcat/v5/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- v5/Makefile 4 Jul 2011 07:41:37 - 1.17
+++ v5/Makefile 22 Jul 2011 10:44:38 -
@@ -10,6 +10,7 @@ PKGNAME= tomcat-${V}
PKGNAME-main= tomcat-${V}
PKGNAME-admin= tomcat-admin-${V}
PKGNAME-examples=tomcat-examples-${V}
+REVISION-main= 0
CATEGORIES=www
DISTFILES= ${DISTNAME}.tar.gz \
@@ -71,11 +72,6 @@ do-install:
${INSTALL_DATA_DIR} ${WRKINST}/${CONFDIR}/Catalina/localhost
${INSTALL_DATA} ${WRKDIST}/conf/Catalina/localhost/* \
${WRKINST}/${CONFDIR}/Catalina/localhost
- @${SUBST_CMD} -o ${BINOWN} -g ${BINGRP} \
- ${PREFIX}/tomcat/bin/setclasspath.sh
- @${SUBST_CMD} -o ${SHAREOWN} -g ${SHAREGRP} -c \
- ${FILESDIR}/tomcat.rc \
- ${SAMPLEDIR}/tomcat.rc
rm -r ${PREFIX}/tomcat/bin/[xi]64
find ${WRKINST} \
-name \*.beforesubst -or \
Index: v5/files/tomcat.rc
===
RCS file: v5/files/tomcat.rc
diff -N v5/files/tomcat.rc
--- v5/files/tomcat.rc 4 Jul 2011 07:41:37 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-# $OpenBSD: tomcat.rc,v 1.3 2011/07/04 07:41:37 dcoppa Exp $
-#
-# Define JAVA_HOME for _tomcat here
-# Start tomcat with following command:
-# $ sudo -u _tomcat ${TRUEPREFIX}/tomcat/bin/startup.sh
-#
-
-# javaPathHelper will pickup JAVA_HOME from the env. if
-# it is not set in the env it will default the jdk that
-# satisfied the RUN_DEPEND.
-JAVA_HOME=$(${LOCALBASE}/bin/javaPathHelper -h tomcat)
-JAVA_OPTS=-server
-
-# override other environment options:
-#CATALINA_HOME=${TRUEPREFIX}/tomcat
-#CATALINA_BASE=${CATALINA_BASE}
-#CATALINA_TMPDIR=${CATALINA_BASE}/temp
-#JAVA_OPTS=-server -Djava.net.preferIPv4Stack=true
-#JPDA_TRANSPORT=
-#JPDA_ADDRESS=
-#JSSE_HOME=
Index: v5/patches/patch-bin_catalina_sh
===
RCS file: v5/patches/patch-bin_catalina_sh
diff -N v5/patches/patch-bin_catalina_sh
--- v5/patches/patch-bin_catalina_sh29 Nov 2010 21:26:01 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-bin_catalina_sh,v 1.4 2010/11/29 21:26:01 sthen Exp $
bin/catalina.sh.orig Thu Jul 1 11:19:40 2010
-+++ bin/catalina.shTue Aug 3 04:52:30 2010
-@@ -156,7 +156,7 @@ fi
- CLASSPATH=$CLASSPATH$CATALINA_HOME/bin/bootstrap.jar
-
- if [ -z $CATALINA_BASE ] ; then
-- CATALINA_BASE=$CATALINA_HOME
-+ CATALINA_BASE=/var/tomcat
- fi
-
- if [ -z $CATALINA_OUT ] ; then
Index: v5/patches/patch-bin_setclasspath_sh
===
RCS file: v5/patches/patch-bin_setclasspath_sh
diff -N v5/patches/patch-bin_setclasspath_sh
--- v5/patches/patch-bin_setclasspath_sh4 Jul 2011 07:41:37 -
1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-bin_setclasspath_sh,v 1.4 2011/07/04 07:41:37 dcoppa Exp $
bin/setclasspath.sh.orig Thu Jul 1 11:19:40 2010
-+++ bin/setclasspath.shTue Aug 3 04:52:30 2010
-@@ -22,4 +22,9 @@
- #
-
-
-+# Read $JAVA_HOME - sudo doesn't pass environment variables
-+if [ -r ${SYSCONFDIR}/tomcat/tomcat.rc ]; then
-+ . ${SYSCONFDIR}/tomcat/tomcat.rc
-+fi
-+
- # Make sure prerequisite environment variables are set
- if [ -z $JAVA_HOME -a -z $JRE_HOME ]; then
Index: v5/pkg/PLIST-main
===
RCS file: /cvs/ports/www/tomcat/v5/pkg/PLIST-main,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST-main
--- v5/pkg/PLIST-main 29 Nov 2010 21:26:01 - 1.7
+++ v5/pkg/PLIST-main 22 Jul 2011 10:44:38 -
@@ -57,12 +57,6 @@ share/examples/tomcat/tomcat-users.xml
@mode
@owner
@group
-share/examples/tomcat/tomcat.rc
-@owner _tomcat
-@group _tomcat
-@sample ${SYSCONFDIR}/tomcat/tomcat.rc
-@owner
-@group
share/examples/tomcat/web.xml
@owner _tomcat
@group _tomcat
@@ -178,4 +172,5 @@ tomcat/server/webapps/manager/manager-ho
tomcat/server/webapps/manager/manager.xml
tomcat/server/webapps/manager/status.xsd
tomcat/server/webapps/manager/xform.xsl
+@rcscript ${RCDIR}/tomcat
@extraunexec rm -rf ${CATALINA_BASE}/logs/* ${CATALINA_BASE}/work/*
Index: v5/pkg/README-main
===
RCS file: /cvs/ports/www/tomcat/v5/pkg/README-main,v
retrieving revision 1.4
diff -u -p -r1.4 README-main
--- v5/pkg/README-main 4 Jul 2011 07:41:37 - 1.4
+++ v5/pkg/README-main 22 Jul 2011 10:44:38 -
@@ -25,13 +25,6 @@ Tomcat on OpenBSD uses the
