Date: Wed, 30 Aug 2017 13:30:29 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-ports@freebsd.org Subject: Re: pkg issue after FreeBSD 11 upgrade Message-ID: <f0209e6f-f66d-22a8-7e6e-2eb083cebbad@multiplay.co.uk> In-Reply-To: <CAJajdNUOg_HMboH563=GSK1QzzcV0v_5WV3v8=Vj7Tk9Rvp32A@mail.gmail.com> References: <CAJajdNUJGgcmvetRFNbtcpwBkzcyArMSg4F2bBELs=qHH1pB=w@mail.gmail.com> <4c16c960-3b4a-75ab-41ed-51c8109b940a@FreeBSD.org> <CAJajdNV1xLovnx-GRLPR-H4muFgxMCSQrqri4FagyfdtMTv3Ww@mail.gmail.com> <CAJajdNUOg_HMboH563=GSK1QzzcV0v_5WV3v8=Vj7Tk9Rvp32A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Try tracing the install with truss or ktrace. I suspect you'll find there is an issue where a pipe being closed; stdin, stdout or stderr, which results in the daemon that was started being stopped again, or something similar. On 30/08/2017 13:00, Cassiano Peixoto wrote: > Hi Matthew, > > Sorry back to this subject. But I really need to restart services with a > port. I'm quite sure there is a bug with pkg and FreeBSD 11. > > I made a simple port to restart cron service: > > # $FreeBSD$ > PORTNAME= ze > PORTVERSION= 1.0 > CATEGORIES= custom > MASTER_SITES= # > DISTFILES= # > EXTRACT_ONLY= # NONE > > MAINTAINER= peixotocassiano@gmail.com > COMMENT= ze port > > #NO_MTREE= yes > > > > SUB_FILES= pkg-install > > > > NO_BUILD= yes > > NO_WRKSUBDIR= yes > > > > do-install: > > mkdir -p ${STAGEDIR}${DATADIR} > > @${CP} -r ${FILESDIR}/versions ${STAGEDIR}${DATADIR}/ > > > > post-install: > > ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL > > > .include <bsd.port.mk> > > Here is my pkg-install to restart cron service: > > #!/bin/sh > > if [ $2 = "POST-INSTALL" ]; then > > service cron restart > > fi > > Here is the output when I install the port: > > root@kkk:~ # service cron start > cron already running? (pid=2287). > > root@kkk:~ # pkg install ze > Updating Custom repository catalogue... > Fetching meta.txz: 100% 560 B 0.6kB/s 00:01 > Fetching packagesite.txz: 100% 122 KiB 62.6kB/s 00:02 > Processing entries: 100% > Custom repository update completed. 427 packages processed. > All repositories are up to date. > The following 1 package(s) will be affected (of 0 checked): > > New packages to be INSTALLED: > ze: 1.0 > > Number of packages to be installed: 1 > > 672 B to be downloaded. > [1/1] Fetching ze-1.0.txz: 100% 672 B 0.7kB/s 00:01 > Checking integrity... done (0 conflicting) > [1/1] Installing ze-1.0... > + set -- ze-1.0 PRE-INSTALL > + [ PRE-INSTALL '=' POST-INSTALL ] > Extracting ze-1.0: 100% > + set -- ze-1.0 POST-INSTALL > + [ POST-INSTALL '=' POST-INSTALL ] > + service cron restart > Stopping cron. > Waiting for PIDS: 2287. > Starting cron. > > root@kkk:~ # ps ax | grep cron > 2320 1 S+ 0:00.00 grep cron > > As you can see the cron has stopped but hasn't started. > > But If I install the same port with traditional ports approach it works, > see: > > root@kkk: /usr/ports/custom/ze/# ps ax | grep cron > 1280 - Is 0:00.97 /usr/sbin/cron -s > > root@kkk: /usr/ports/custom/ze# make install > ===> ze-1.1 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by ze-1.1 for building > ===> Extracting for ze-1.1 > ===> Patching for ze-1.1 > ===> Configuring for ze-1.1 > ===> Staging for ze-1.1 > ===> Generating temporary packing list > mkdir -p /usr/ports/custom/ze/work/stage/usr/local/share/ze > /bin/sh /usr/ports/custom/ze/work/pkg-install ze-1.1 POST-INSTALL > ====> Compressing man pages (compress-man) > ===> Installing for ze-1.1 > ===> Checking if ze already installed > Stopping cron. > Waiting for PIDS: 1280. > Starting cron. > ===> Registering installation for ze-1.1 > Installing ze-1.1... > > root@kkk: /usr/ports/custom/ze# ps ax | grep cron > 37527 - Ss 0:00.00 /usr/sbin/cron -s > > Thanks for your help. > > > > On Fri, Aug 11, 2017 at 1:45 PM, Cassiano Peixoto <peixotocassiano@gmail.com >> wrote: >> Hi Matthew, >> >> Thanks for your answer. Slapd is just an example, it happens with any >> application like apache, mysql, dovecot and others. >> >> I can see the process is running and up, and it dies after pkg process has >> finished. Looks like pkg is killing any application related to its thread. >> >> I know it's not the best approach, but used to work on FreeBSD 10. >> >> Anyway, I'll change my script to restart services out of pkg process. >> >> Thanks. >> >> On Fri, Aug 11, 2017 at 5:09 AM, Matthew Seaman <matthew@freebsd.org> >> wrote: >> >>> On 10/08/2017 22:05, Cassiano Peixoto wrote: >>>> I ran into an issue after FreeBSD 11 upgrade. I have some meta ports >>> that >>>> starts services like slapd. >>>> >>>> Its has been working fine on 10-STABLE. But after FreeBSD >>>> 11-STABLE r321625M upgrade it stopped working. >>>> >>>> Here is a simple example of my pkg-install.in script: >>>> >>>> #!/bin/sh >>>> /usr/local/etc/rc.d/slapd stop >>>> /usr/local/etc/rc.d/slapd start >>>> >>>> I can see its executing while upgrading a package: >>>> >>>> Stopping slapd. >>>> Waiting for PIDS: 13875. >>>> Starting slapd. >>>> >>>> But looking if the process is running, it's not: >>>> >>>> # ps ax | grep slapd >>>> 14164 0 S+ 0:00.00 grep slapd >>>> >>>> Then I manually run the rc.d script and the service starts: >>>> >>>> # /usr/local/etc/rc.d/slapd restart >>>> slapd not running? (check /var/run/openldap/slapd.pid). >>>> Starting slapd. >>>> >>>> So my question is: something has changed on FreeBSD 11 not allowing this >>>> kind of execution? >>>> >>>> BTW, I'm using pkg 1.10.1 and my ports collection is as same as I was >>> using >>>> on FreeBSD 10. >>> Restarting daemons after upgrading is something the project has been >>> quite resistant to implementing. Mostly because as soon as you start >>> looking into it in any depth the true complexity of doing that sort of >>> thing reliably for any conceivable system becomes apparent and you end >>> up muttering darkly about systemd and losing the will to live. >>> >>> However, yes, restarting slapd -- it's clear that your script does get >>> called, but slapd fails to start at that point during the upgrade >>> process. slapd is well known (at least to me) for failing to start >>> /silently/ -- you need to check the process is actually there after >>> trying to start it, and look at the logfiles and so forth. It also >>> seems to quit at the slightest provocation, presumably to avoid any >>> potential for data corruption. >>> >>> So check you logs to see why slapd didn't start. It's quite possible >>> that it was simply that something else that slapd needed wasn't >>> available at that exact point during the upgrade process, and just >>> waiting until the upgrade had finished would sort things out. >>> >>> Cheers, >>> >>> Matthew >>> >>> > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f0209e6f-f66d-22a8-7e6e-2eb083cebbad>