Score:0

Start service after all http handling services have started

cn flag

I have been puzzling over this one for a while now and I have managed to refine my issue to one problem. I have a service which is supposed to run a shell script to start daemon processes (using nohup), these processes are discord bots written using nodejs and discordjs. Currently I have a service that starts the test discord bot when I run it using sudo systemctl start startdiscordbots and that works fine. The issue is when I restart the computer the service throws the error below:

/daemons/discordbots/discounter/node_modules/discord.js/src/rest/RequestHandler.js:172
Aug 31 13:35:15 ubuntu start.sh[2459]:         throw new HTTPError(error.message, error.constructor.name, error.status, request);
Aug 31 13:35:15 ubuntu start.sh[2459]:               ^
Aug 31 13:35:15 ubuntu start.sh[2459]: HTTPError [FetchError]: request to https://discord.com/api/v9/gateway/bot failed, reason: getaddrinfo EAI_AGAIN discord.com
Aug 31 13:35:15 ubuntu start.sh[2459]:     at RequestHandler.execute (/daemons/discordbots/discounter/node_modules/discord.js/src/rest/RequestHandler.js:172:15)
Aug 31 13:35:15 ubuntu start.sh[2459]:     at processTicksAndRejections (node:internal/process/task_queues:96:5)
Aug 31 13:35:15 ubuntu start.sh[2459]:     at async RequestHandler.push (/daemons/discordbots/discounter/node_modules/discord.js/src/rest/RequestHandler.js:50:14)
Aug 31 13:35:15 ubuntu start.sh[2459]:     at async WebSocketManager.connect (/daemons/discordbots/discounter/node_modules/discord.js/src/client/websocket/WebSocketManager.js:128:9)
Aug 31 13:35:15 ubuntu start.sh[2459]:     at async Client.login (/daemons/discordbots/discounter/node_modules/discord.js/src/client/Client.js:245:7) {
Aug 31 13:35:15 ubuntu start.sh[2459]:   code: 500,
Aug 31 13:35:15 ubuntu start.sh[2459]:   method: 'get',
Aug 31 13:35:15 ubuntu start.sh[2459]:   path: '/gateway/bot',
Aug 31 13:35:15 ubuntu start.sh[2459]:   requestData: { json: undefined, files: [] }
Aug 31 13:35:15 ubuntu start.sh[2459]: }

So I know that the service starts fine once all other services have been loaded correctly but I am guessing that there is a service that I need to put in the After= part of the startdiscordbots.service file that I have missed, my startdiscordbots.service code is below

[Unit]
Description=Start discord bots as background processes

After=network.target systemd-user-sessions.service

[Service]
Type=simple
ExecStart=/startup/start.sh
Restart=on-failure
RestartSec=5
KillMode=process
User=ubuntu

[Install]
WantedBy=multi-user.target

Does anyone know if there is a service that I need to specify in the After= that I have missed or is there something else going on?

The computer I am using is a RaspberryPi with Ubuntu Server installed, I am using node v16.8.0 and npm v7.21.0 with discordjs v13.1.0. I only have access to the terminal so please don't give answers telling me to use other tools.

Any help would be amazing!

waltinator avatar
it flag
You're looking at the wrong thing, it's not a service. You want to wait until network connectivity is established. Only then, you can reach things across the network.
Bobcat33 avatar
cn flag
@waltinator How would I go about doing that? I seem to have come up with a solution (by adding `After=multi-user.target`) but I'm not sure how long it will last...
Score:1
it flag

Write a function that blocks until network is up, makes other tests (is there a default route (man ip ip-route), can you host google.com (man host), etc., then starts your services. I've written a bash script to help with this: https://github.com/waltinator/net-o-matic It watches the connection, and when the connection drops, does a user-specified thing to try to reconnect. A little bash knowledge will let you modify this. Read man bash.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.