you seem to be on to something …
ghost 3528 0.0 3.1 908940 64760 ? Ssl 12:16 0:01 ghost run
ghost 3538 0.1 4.6 1262656 93944 ? Sl 12:16 0:33 /usr/bin/node current/index.js
ghost 3828 0.0 3.1 908908 64812 ? Ssl 12:26 0:00 ghost run
ghost 3838 0.1 4.6 1259320 94872 ? Sl 12:26 0:21 /usr/bin/node current/index.js
Also thank you so much for your time and attention @Hannah. I know you don’t have to do this.
Really grateful 
config.production.json …
{
"url": "http://janusworx.com",
"server": {
"port": 2368,
"host": "127.0.0.1"
},
"database": {
"client": "mysql",
"connection": {
"host": "localhost",
"user": "ghost-713",
"password": "",
"database": "jwghost"
}
},
"mail": {
"transport": "Direct"
},
"logging": {
"transports": [
"file",
"stdout"
]
},
"process": "systemd",
"paths": {
"contentPath": "/var/www/jw/content"
}
}
Both of those look normal to me - for ps -aux, you will get 2 items per ghost install, so 4 for 2 blogs is correct. Config also looks correct (I wondered if file was in the logging transports twice).
If you’re running a blog or multiple blogs using Ghost CLI then we expect that everything will “just work”. I’m trying to rule out anything obvious but I don’t see anything at all that explains this!
Is there any thing at all about your setup, other than it being 2 blogs, that we should know? Anything that went wrong or that you customised?
I can see that the URL is configured as HTTP, but your site is loading over HTTPS and redirecting HTTP -> HTTPS.
ghost config url https://janusworx.com will change the config, ghost restart will apply the change.
I do not expect that to help, but means all your meta and canonical urls output by Ghost will be https so they don’t end up redirecting, so still a useful improvement.
will try. gimme 5 mins
also other than two blogs, I’ve used certbot to do certs in my nginx config.
everything is vanilla
posting my config
server {
listen 80;
listen [::]:80;
server_name janusworx.com;
root /var/www/jw/system/nginx-root;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:2368;
}
location ~ /.well-known {
allow all;
}
client_max_body_size 50m;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/janusworx.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/janusworx.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
}
Interesting, is there a reason you used certbot instead of ghost-cli/acme.sh for ssh?
Not likely to be the cause, but is a deviation from a standard CLI setup.
i don’t remember, but the cli was hassling in those days.
may be if I did it all over again, I’d stick to the normal route
I also have static fileserves at files.janusworx.com and podcast.mjbraganza.com which I also needed certs for.
That also would have been another reason why.
creating a post to test as we speak. will update you in 5-10 mins
@Hannah! Hannah! Hannah!
You fixed it 
Switching the config url to https did the trick.
Tried it on both blogs and it worked.
I’m doing a little jig here 
Thank you! Thank you! Thank you!
Ok cool. I’m not sure why that was causing a 404, but I guess that the scheduler does not follow 301 redirects.
Note: If you setup SSL with Ghost-CLI it will automatically make that config change for you, so if you setup using CLI a while ago, struggled with SSL and did it yourself, that explains why we aren’t in a “just working” state.
@Kate something to review next week and make sure this is working as expected or whether we perhaps need to tweak something.
Oh - did that also fix the duplicate logging?
No. Still two entries
But then like you said, maybe my blogs are out of whack.
The next time something breaks, I’m just going to nuke and start anew.
Thank you once again!
I was running into duplicated log lines with the latest CLI version today. I’ve raised an issue:
[2018-05-23 12:49:00] INFO “GET /ghost/api/v0.1/schedules/posts/5a0fc6070223bc3593b44293?client_id=ghost-scheduler&client_secret=c7c0fd07a406” 404 5ms
This is a GET request to publish the post, but the endpoint is a PUT. That’s why we see a 404 here.
@jasonbraganza5d
I guess this is caused by the redirect condition in your nginx config
if ($scheme != "https") {
return 301 https://$host$request_uri;
}
A 301 will change the method from PUT to GET. If you would e.g. use a 307 http code and set your blog url to http, it should work.
But of course, setting the blog url to https is the right solution 
Thank you very much for troubleshooting this. Had the same problem on my dockerized setup.
Slight difference on my side was that I set up a bridge network in my docker-compose file.
If any other Docker faithful are still having trouble getting scheduled posts to work with the fix, you’ll need to figure out which internal IP ufw is blocking.
You can use docker inspect, or if that is unclear just use the same approach as @lenoir_aaron and watch the output of sudo tail -f /var/log/syslog in the container running Ghost when a scheduled post goes up.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.