pkg issue after FreeBSD 11 upgrade

Wed Aug 30 12:30:33 UTC 2017

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 at 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 at kkk:~ # service cron start
> cron already running?  (pid=2287).
>
> root at 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 at 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 at kkk: /usr/ports/custom/ze/# ps ax | grep cron
>   1280  -  Is       0:00.97 /usr/sbin/cron -s
>
> root at 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 at 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 at 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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"