Solution (almost certainly): postfix fails to launch at boot

[Gerben Wierda]

> On 10 Jan 2020, at 18:37, Gerben Wierda  wrote:
> 
> postfix is started during boot on my macOS system. This fails with:
> 
> Jan 10 18:00:08 mail postfix/master[488]: fatal: bind 0.0.0.0 port 25: 
> Address already in use
> Jan 10 18:00:10 mail /postfix-script[511]: fatal: mail system startup failed
> 
> but when I shortly thereafter launch it it just starts fine.
> 
> It seems something in the postfix/macOS combo makes this happen. Probably a 
> weirdness in macOS if postfix starts when the system is still in some startup 
> state (there have been more issues like this with macOS), so what I could use 
> is a way to make postfix a bit more persistent in trying to start on a fatal.
> 
> startupitem.create  yes
> startupitem.start   "${prefix}/sbin/${name} start"
> startupitem.stop"${prefix}/sbin/${name} stop"
> 
> Given that postfix writes a pid file in 
> /opt/local/var/spool/postfix/pid/master.pid would it be possible to use a 
> startupitem.pidfile entry that triggers daemondo to try to relaunch when this 
> happens? Note: postfix is started by a program running  script which then 
> starts the master process that writes the pid file.
> 

It is not necessary as the cause has (probably) been found.

macOS still contains a postfix and it is launched at boot time during 60 
seconds with a launchdaemon plist 
/System/Library/LaunchDaemons/com.apple.postfix.master.plist:


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


Label
com.apple.postfix.master
Program
/usr/libexec/postfix/master
ProgramArguments

master
-e
60

QueueDirectories

/var/spool/postfix/maildrop

AbandonProcessGroup




This runs master for 60 seconds during boot to clear any queue created by 
Apple’s sendmail and when something is dropped in that queue. This creates a 
race condition with MacPorts postfix (hence the remark in the mail-server Port 
that launching postfix after boot is unreliable).

Apple’s postfix master is steered by /etc/postfix/master.cf, which contains 
entries for smtpd (2x) and postscreen. Commenting these out:

#  Begin auto-generated section 
# This section of the master.cf file is auto-generated by the Server Admin
#  Mail backend plugin whenever mails settings are modified.
# GW: Commented postscreen, smtpd commands as Apple's postfix master gets run 
for 60 sec at boot
#smtp  inet  n   -   n   -   1   postscreen
#smtpd pass  -   -   n   -   -   smtpd
dnsblog   unix  -   -   n   -   0   dnsblog
tlsproxy  unix  -   -   n   -   0   tlsproxy
#submission inet n   -   n   -   -   smtpd
#  -o smtpd_tls_security_level=encrypt

Will result in Apple’s postfix not starting to listen on ports 25 and 587 for 
60 seconds during boot or when anything is dropped in its queue by sendmail. 
(Actually, the second line doesn’t need to be as it doesn’t listen on inet)

Maybe the postfix port should issue a warning about /etc/postfix/master.cf or 
even better, uncomment these lines (not-commented lines that end in ’smtpd' or 
‘postscreen’ and every non-empty-non-comment line that starts with whitespace 
immediately after. Multiline edit, so a job for awk and beyond my comfort zone.)

G

postfix fails to launch at boot

[Gerben Wierda]

postfix is started during boot on my macOS system. This fails with:

Jan 10 18:00:08 mail postfix/master[488]: fatal: bind 0.0.0.0 port 25: Address 
already in use
Jan 10 18:00:10 mail /postfix-script[511]: fatal: mail system startup failed

but when I shortly thereafter launch it it just starts fine.

It seems something in the postfix/macOS combo makes this happen. Probably a 
weirdness in macOS if postfix starts when the system is still in some startup 
state (there have been more issues like this with macOS), so what I could use 
is a way to make postfix a bit more persistent in trying to start on a fatal.

startupitem.create  yes
startupitem.start   "${prefix}/sbin/${name} start"
startupitem.stop"${prefix}/sbin/${name} stop"

Given that postfix writes a pid file in 
/opt/local/var/spool/postfix/pid/master.pid would it be possible to use a 
startupitem.pidfile entry that triggers daemondo to try to relaunch when this 
happens? Note: postfix is started by a program running  script which then 
starts the master process that writes the pid file.

G

Works! (Was: nginx with +dav and +davext variant doesn't work)

[Gerben Wierda]

It took some time because I first had to solve my MacPorts/git issues, but now 
that I have (and created another attempt at a pull request for unbound) I could 
test this and I can report that it works.

Thank you!

Gerben

> On 6 Jan 2020, at 02:48, Marius Schamschula  > wrote:
> 
> Gerben,
> 
> We normally don’t livecheck module versions. The web-dav module has been 
> updated twice.
> 
> I’ve updated the Portfile. Let me know if this fixes your issue.
> 
> I haven’t tested, as I personally don’t use web-dav on nginx (I do use it on 
> Apache under FreeBSD).
> 
> In the future please open a ticket on trac.macports.org 
>  or, better yet, open a PR on GitHub.
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 
>> On Jan 5, 2020, at 4:23 PM, Gerben Wierda > > wrote:
>> 
>> Nobody?
>> 
>>> On 28 Dec 2019, at 14:57, Gerben Wierda >> > wrote:
>>> 
>>> Hello nginx maintainers and davext contributor,
>>> 
>>> Thank you for maintaining the nginx port.
>>> 
>>> I’ve installed nginx with DAV and DAVEXT support:
>>> 
>>> bash-3.2# port installed nginx
>>> The following ports are currently installed:
>>>   nginx 
>>> @1.17.6_0+dav+davext+fancyindex+flv+http2+mp4+secure_link+ssl+stream 
>>> (active)
>>> 
>>> But when I add directives from davext, nginx throws up emergencies. 
>>> 
>>> 2019/12/28 14:31:48 [emerg] 9175#0: unknown directive "dav_ext_lock_zone" 
>>> in /opt/local/etc/nginx/nginx.conf:39
>>> 
>>> or if I remove the dav_ext_lock_zone directive:
>>> 
>>> 2019/12/28 14:33:25 [emerg] 9186#0: invalid value "LOCK" in 
>>> /opt/local/etc/nginx/servers/albus.rna.nl:30 
>>> 
>>> nginx -V says:
>>> 
>>> configure arguments: --prefix=/opt/local 
>>> --with-cc-opt='-I/opt/local/include -Os' --with-ld-opt='-L/opt/local/lib 
>>> -Wl,-headerpad_max_install_names' 
>>> --conf-path=/opt/local/etc/nginx/nginx.conf 
>>> --error-log-path=/opt/local/var/log/nginx/error.log 
>>> --http-log-path=/opt/local/var/log/nginx/access.log 
>>> --pid-path=/opt/local/var/run/nginx/nginx.pid 
>>> --lock-path=/opt/local/var/run/nginx/nginx.lock 
>>> --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp 
>>> --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp 
>>> --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp 
>>> --http-uwsgi-temp-path=/opt/local/var/run/nginx/uwsgi_temp 
>>> --with-http_dav_module --with-http_dav_module 
>>> --add-module=/opt/local/var/macports/build/_Users_sysbh_MacPortsDev_macports-ports_www_nginx/nginx/work/nginx-dav-ext-module-0.1.0
>>>  --with-http_flv_module --with-http_ssl_module --with-http_v2_module 
>>> --with-http_mp4_module --with-http_secure_link_module --with-stream 
>>> --with-stream_ssl_module --with-stream_ssl_preread_module 
>>> --add-module=/opt/local/var/macports/build/_Users_sysbh_MacPortsDev_macports-ports_www_nginx/nginx/work/ngx-fancyindex-0.4.3
>>> 
>>> (The double --with-http_dav_module comes from +dav and +davext, same effect 
>>> with just +davext)
>>> 
>>> But after a build, the directory 
>>> /opt/local/var/macports/build/_Users_sysbh_MacPortsDev_macports-ports_www_nginx
>>>  does not exist, let alone its contents. But the same is true for 
>>> fancyindex and that directive is accepted.
>>> 
>>> I’m stumped. Why isn’t davext working?
>>> 
>>> Gerben Wierda
>>> Chess and the Art of Enterprise Architecture 
>>> Mastering ArchiMate 
>>> Architecture for Real Enterprises 
>>>  at 
>>> InfoWorld
>>> On Slippery Ice  at EAPJ
>>> 
>> 
> 

Re: Git question

[Steven Smith]

There’s always an xkcd.

Don’t forget to read the hover text:

> If that doesn't fix it, git.txt contains the phone number of a friend of mine 
> who understands git. Just wait through a few minutes of 'It's really pretty 
> simple, just think of branches as...' and eventually you'll learn the 
> commands that will fix everything.

> On Jan 10, 2020, at 2:57 AM, Michael  wrote:
> 
> 
> On 2020-01-09, at 2:33 PM, Steven Smith  > wrote:
> 
>> Me too. We’re discussing MacPorts-relevant git commands in 
>> https://github.com/macports/macports-ports/pull/6106 
>>  .
>> 
>> Easiest, most destructive to local:
>> 
>> # save all local files changed outside the git repo
>> 
>> git fetch --all
>> git reset --hard upstream/master
>> 
>> # restore all local files
> 
> I'm sorry, I just have to follow up with this xkcd ...
> 
> https://xkcd.com/1597/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Git question

[Christopher Jones]

> On 10 Jan 2020, at 9:34 am, Gerben Wierda  wrote:
> 
> OK. I'm back in git hell (suggestions made on this list, tips on 
> stackexchange, git documentation, nothing gives me the answer)
> 
> I have 
> albus:macports-ports sysbh$ git remote -v
> local https://github.com/gctwnl/macports-ports.git 
>  (fetch)
> local https://github.com/gctwnl/macports-ports.git 
>  (push)
> originhttps://github.com/macports/macports-ports.git 
>  (fetch)
> originhttps://github.com/macports/macports-ports.git 
>  (push)
> 
> So, my clone is ‘local’, the upstream repository is ‘origin’ (some 
> instructions tend to call this ‘upstream’, others ‘origin’, there seem to be 
> two ’sops’ on this in gitland. I think now that using ‘upstream’ is the 
> better choice as git defaults to ‘origin’ when no argument is given. So, I 
> need to rename too. But first let’s see if I can get this thing working in 
> the first place).
> 
> If I produce a pull request and I’m rebuffed because of an error I make, I 
> need to go back to testate of the official repository before proceeding 
> again. At such a point my own clone is both commits ahead and commits behind 
> the official repository. I need to lose my commits (as I am rebuffed by 
> macports maintainers if I have multiple ‘working’ commits in my pull 
> request). So, I need to reset my clone to the current state of the official 
> repository.
> 
> So, my clone is now two commits ahead of the official macports repository and 
> 343 commits behind. I need to reset my clone to be the same as the official 
> repository. The result of which is:
> 
> albus:macports-ports sysbh$ git fetch origin
> albus:macports-ports sysbh$ git reset --hard origin/master
> HEAD is now at dfb14de3eb5 pypy*-tkinter: ensure UsingTheRightCompiler
> albus:macports-ports sysbh$ git push
> Username for 'https://github.com':  
> gerben.wie...@rna.nl 
> Password for 'https://gerben.wie...@rna.nl@github.com': 
>  
> To https://github.com/gctwnl/macports-ports.git 
> 
>  ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to 
> 'https://github.com/gctwnl/macports-ports.git 
> '
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> 
> I don’t want to “Integrate the remote changes”, I want to lose them. How??


In this case because you changed history in your local master branch (by 
resetting) you need to force push

git push —force local master

> 
> G
> 
>> On 10 Jan 2020, at 08:57, Michael > > wrote:
>> 
>> 
>> On 2020-01-09, at 2:33 PM, Steven Smith > > wrote:
>> 
>>> Me too. We’re discussing MacPorts-relevant git commands in 
>>> https://github.com/macports/macports-ports/pull/6106 
>>>  .
>>> 
>>> Easiest, most destructive to local:
>>> 
>>> # save all local files changed outside the git repo
>>> 
>>> git fetch --all
>>> git reset --hard upstream/master
>>> 
>>> # restore all local files
>> 
>> I'm sorry, I just have to follow up with this xkcd ...
>> 
>> https://xkcd.com/1597/ 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Git question

[Dr M J Carter]

On Thu, Jan 09, 2020 at 11:57:56PM -0800, Michael wrote:

> On 2020-01-09, at 2:33 PM, Steven Smith <[1]steve.t.sm...@gmail.com>
> wrote:
> 
>> Me too. We’re discussing MacPorts-relevant git commands
>> in [2]https://github.com/macports/macports-ports/pull/6106 .
>> Easiest, most destructive to local:
>> # save all local files changed outside the git repo
>> git fetch --all
>> git reset --hard upstream/master
>> # restore all local files

Argh, but I invoke Thompson's Law.

> I'm sorry, I just have to follow up with this xkcd ...
> [3]https://xkcd.com/1597/

Don't forget the mouseover.

MaJoC's \euro 0.02: Always do a "git fetch" immediately before saying
"git push" etc.  Sometimes I manage to produce my own conflicts by
working at home and work separately, and this trick at least forewarns
me nondestructively of any interesting surprises which may be pending.
HTH, folks.

-- 
Dr Martin J Carter
Computer System Administrator
Astrophysics, University of Oxford

Re: Git question

[Gerben Wierda]

This actually completed, but on GitHub.com I still see:

This branch is 2 commits ahead, 343 commits behind macports:master.

In other words, any pull request will still be denied because it consists of 
multiple commits on a part instead of a single one.

I understand that MacPorts wants to keep the official repository clean, but 
there are no instructions on how to proceed when your pull request is denied 
because you’ll end up with (forbidden) multiple commits. And so far, nothing 
works.

G

> On 9 Jan 2020, at 22:41, Jeremy Lavergne  wrote:
> 
> If anyone else pushed between your fetch and push, you'll be out of date 
> again.
> 
> Not entirely sure what your workflow is, but you a current git should let you 
> do an autostash on pull (which might help your situation):
> 
> git pull --rebase --autostash && git push
> 
> 
> 
> On 1/9/20 4:34 PM, Gerben Wierda wrote:
>> Given my absolute lack of decent git skills (and it’s just too complicated 
>> for a fast skill increase) I have the following setup (which so far worked)
>> I have a macports-ports clone on GitHub which I use locally. I need a clone 
>> or I cannot create pull requests.
>> When I have to do a reset, I:
>> - save my changed files outside the git tree
>> - then:
>> # To reset the current reporsitory to what is in upstream (my repo is called 
>> 'local', upstream is called 'origin')
>>git fetch origin
>>git reset --hard origin/master
>> # I push the local store to my cloned repository on github:
>>git push
>> After this, my repo on github.com  
>> (gctwnl/macports-ports) and my local copy of my own repo are in sync with 
>> macports/macports-ports
>> Or so I thought. But I just tried this and I get:
>> albus:macports-ports sysbh$ git push
>> Username for 'https://github.com': gerben.wie...@rna.nl 
>> 
>> Password for 'https://gerben.wie...@rna.nl@github.com':
>> To https://github.com/gctwnl/macports-ports.git
>> ! [rejected] master -> master (non-fast-forward)
>> error: failed to push some refs to 
>> 'https://github.com/gctwnl/macports-ports.git'
>> hint: Updates were rejected because the tip of your current branch is behind
>> hint: its remote counterpart. Integrate the remote changes (e.g.
>> hint: 'git pull ...') before pushing again.
>> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>> So, apparently my ‘reboot’ isn’t hard enough. What went wrong? How do I
>> - reset my clone (both local and on GitHub.com ) to the 
>> current HEAD of the official repo in a way that /always/ works?
>> G

Re: Git question

[Gerben Wierda]

OK. I'm back in git hell (suggestions made on this list, tips on stackexchange, 
git documentation, nothing gives me the answer)

I have 
albus:macports-ports sysbh$ git remote -v
local   https://github.com/gctwnl/macports-ports.git (fetch)
local   https://github.com/gctwnl/macports-ports.git (push)
origin  https://github.com/macports/macports-ports.git (fetch)
origin  https://github.com/macports/macports-ports.git (push)

So, my clone is ‘local’, the upstream repository is ‘origin’ (some instructions 
tend to call this ‘upstream’, others ‘origin’, there seem to be two ’sops’ on 
this in gitland. I think now that using ‘upstream’ is the better choice as git 
defaults to ‘origin’ when no argument is given. So, I need to rename too. But 
first let’s see if I can get this thing working in the first place).

If I produce a pull request and I’m rebuffed because of an error I make, I need 
to go back to testate of the official repository before proceeding again. At 
such a point my own clone is both commits ahead and commits behind the official 
repository. I need to lose my commits (as I am rebuffed by macports maintainers 
if I have multiple ‘working’ commits in my pull request). So, I need to reset 
my clone to the current state of the official repository.

So, my clone is now two commits ahead of the official macports repository and 
343 commits behind. I need to reset my clone to be the same as the official 
repository. The result of which is:

albus:macports-ports sysbh$ git fetch origin
albus:macports-ports sysbh$ git reset --hard origin/master
HEAD is now at dfb14de3eb5 pypy*-tkinter: ensure UsingTheRightCompiler
albus:macports-ports sysbh$ git push
Username for 'https://github.com': gerben.wie...@rna.nl
Password for 'https://gerben.wie...@rna.nl@github.com': 
To https://github.com/gctwnl/macports-ports.git
 ! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 
'https://github.com/gctwnl/macports-ports.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I don’t want to “Integrate the remote changes”, I want to lose them. How??

G

> On 10 Jan 2020, at 08:57, Michael  wrote:
> 
> 
> On 2020-01-09, at 2:33 PM, Steven Smith  > wrote:
> 
>> Me too. We’re discussing MacPorts-relevant git commands in 
>> https://github.com/macports/macports-ports/pull/6106 
>>  .
>> 
>> Easiest, most destructive to local:
>> 
>> # save all local files changed outside the git repo
>> 
>> git fetch --all
>> git reset --hard upstream/master
>> 
>> # restore all local files
> 
> I'm sorry, I just have to follow up with this xkcd ...
> 
> https://xkcd.com/1597/ 
> 

Re: Git question

[Ken Cunningham]

That's about it!

K