Re: auto restarting in crontab

[debian-user]

"p...@ymail.ne.jp"  wrote:
> debian-u...@howorth.org.uk wrote:
> > But it sounds like what...@ymail.ne.jp  is doing isn't best practice
> > either, although I don't fully understand what they mean by "I often
> > change default ruby in interactive shell". If they mean 'global'
> > then I suspect they should be using 'local' instead. Or just
> > possibly 'shell'.  
> 
> I installed ruby only in my personal account, not the global.
> Sometimes I was using the older ruby version (1.x), but sometimes I
> am using the latest ruby (3.x). For example, different streaming
> libraries for ruby require different versions.
> 
> For instance, I developed a ruby client for Kafka streaming, and 
> deployed it in crontab, and this script must use ruby 3.x version.
> 
> 0 * * * * ruby kafka-consumer.rb
> 
> But one day I changed the default version in my personal path to ruby 
> 1.x via rbenv, the crontab above should not work. This is a risk, is
> it?

You're using terms I don't recognize from my brief reading of the docs.
But it seems you're doing things that I don't see mentioned there, and
that you have older ruby versions that I don't expect to see. So I
suggest reading the docs and trying to follow them. I believe your
kafka-consumer should be set up with rbenv local so it doesn't matter
what you say in the crontab.

> regards
> Yong

Re: auto restarting in crontab

[Nicolas George]

debian-u...@howorth.org.uk (12023-03-17):
> Please don't send me an individual copy of emails; I am subscribed.

Nobody can remember who is subscribed and who is not: do not write this
in your mail, write it in the headers, just like I did.

-- 
  Nicolas George

Re: auto restarting in crontab

[debian-user]

Please don't send me an individual copy of emails; I am subscribed.

Dan Ritter  wrote:
> debian-u...@howorth.org.uk wrote: 
> > Dan Ritter  wrote:  
> > > p...@ymail.ne.jp wrote:   
> > > > For dev stuff, for example, I have many versions of ruby
> > > > installed in the system by rbenv.
> > > > 
> > > > Since I often change default ruby in interactive shell, this may
> > > > break the ruby for sysadmin job in crontab. What’s the solution
> > > > for this?  
> > > 
> > > Everywhere it matters, set an explicit PATH at the beginning.
> > > 
> > > There is no other solution.  
> > 
> > Err, I know nothing about the subject but that doesn't seem to
> > correspond with what it says in the readme at
> > https://github.com/rbenv/rbenv  
> 
> rbenv is a fancy way of setting the PATH. It changes out setting
> the PATH directly for requiring you to set up a .ruby-version
> file for every project. If you commit to it, it might be better
> for you. If you don't, it's harder to debug what's going wrong.

The point is that the OP said they were using rbenv, so that's what
matters to them. That's what they've chosen.

> In general, development environments might want multiple Ruby
> versions but production should only have one. If the production
> version isn't the one that Debian is currently shipping, the
> Debian-shipped version shouldn't be installed at all.
> 
> -dsr-

Re: auto restarting in crontab

[Greg Wooledge]

On Fri, Mar 17, 2023 at 08:04:24AM +0800, p...@ymail.ne.jp wrote:
> Sometimes I was using the older ruby version (1.x), but sometimes I am using
> the latest ruby (3.x). For example, different streaming libraries for ruby
> require different versions.
> 
> For instance, I developed a ruby client for Kafka streaming, and deployed it
> in crontab, and this script must use ruby 3.x version.
> 
> 0 * * * * ruby kafka-consumer.rb

How is cron going to know which ruby to use?  Cron uses a very minimalist
PATH.  From crontab(5):

   Several environment variables are set up automatically by  the  cron(8)
   daemon.  SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
   /etc/passwd  line  of  the   crontab's   owner.PATH   is   set   to
   "/usr/bin:/bin".   HOME,  SHELL, and PATH may be overridden by settings
   in the crontab; LOGNAME is the user that the job is running  from,  and
   may not be changed.

Cron is going to look for /usr/bin/ruby or /bin/ruby and that's it,
unless there's more to this crontab that you haven't shown us.

If you need your crontab to use a specific version of ruby, on a system
with multiple versions installed, you need to use the full path to one
of them, or set the PATH variable.

Re: auto restarting in crontab

[p...@ymail.ne.jp]

debian-u...@howorth.org.uk wrote:

But it sounds like what...@ymail.ne.jp  is doing isn't best practice
either, although I don't fully understand what they mean by "I often
change default ruby in interactive shell". If they mean 'global' then I
suspect they should be using 'local' instead. Or just possibly 'shell'.


I installed ruby only in my personal account, not the global.
Sometimes I was using the older ruby version (1.x), but sometimes I am 
using the latest ruby (3.x). For example, different streaming libraries 
for ruby require different versions.


For instance, I developed a ruby client for Kafka streaming, and 
deployed it in crontab, and this script must use ruby 3.x version.


0 * * * * ruby kafka-consumer.rb

But one day I changed the default version in my personal path to ruby 
1.x via rbenv, the crontab above should not work. This is a risk, is it?


regards
Yong

Re: auto restarting in crontab

[Jeffrey Walton]

On Thu, Mar 16, 2023 at 7:03 PM Dan Ritter  wrote:
>
> debian-u...@howorth.org.uk wrote:
> > Dan Ritter  wrote:
> > > p...@ymail.ne.jp wrote:
> > > > For dev stuff, for example, I have many versions of ruby installed
> > > > in the system by rbenv.
> > > >
> > > > Since I often change default ruby in interactive shell, this may
> > > > break the ruby for sysadmin job in crontab. What’s the solution for
> > > > this?
> > >
> > > Everywhere it matters, set an explicit PATH at the beginning.
> > >
> > > There is no other solution.
> >
> > Err, I know nothing about the subject but that doesn't seem to
> > correspond with what it says in the readme at
> > https://github.com/rbenv/rbenv
>
> rbenv is a fancy way of setting the PATH. It changes out setting
> the PATH directly for requiring you to set up a .ruby-version
> file for every project. If you commit to it, it might be better
> for you. If you don't, it's harder to debug what's going wrong.
>
> In general, development environments might want multiple Ruby
> versions but production should only have one. If the production
> version isn't the one that Debian is currently shipping, the
> Debian-shipped version shouldn't be installed at all.

Likely this. Debian removed update-alternatives for Ruby; see [1]. And
from [1] under "Installing Ruby versions not packaged in Debian":

While ruby-build is a great tool to build Ruby versions
that are not available via APT, you should still use the
Debian-packaged versions of Ruby whenever possible since
they are tested and supported by the Debian community.

[1] https://wiki.debian.org/Ruby

Jeff

Re: auto restarting in crontab

[Dan Ritter]

debian-u...@howorth.org.uk wrote: 
> Dan Ritter  wrote:
> > p...@ymail.ne.jp wrote: 
> > > For dev stuff, for example, I have many versions of ruby installed
> > > in the system by rbenv.
> > > 
> > > Since I often change default ruby in interactive shell, this may
> > > break the ruby for sysadmin job in crontab. What’s the solution for
> > > this?
> > 
> > Everywhere it matters, set an explicit PATH at the beginning.
> > 
> > There is no other solution.
> 
> Err, I know nothing about the subject but that doesn't seem to
> correspond with what it says in the readme at
> https://github.com/rbenv/rbenv

rbenv is a fancy way of setting the PATH. It changes out setting
the PATH directly for requiring you to set up a .ruby-version
file for every project. If you commit to it, it might be better
for you. If you don't, it's harder to debug what's going wrong.

In general, development environments might want multiple Ruby
versions but production should only have one. If the production
version isn't the one that Debian is currently shipping, the
Debian-shipped version shouldn't be installed at all.

-dsr-

Re: auto restarting in crontab

[debian-user]

Dan Ritter  wrote:
> p...@ymail.ne.jp wrote: 
> > For dev stuff, for example, I have many versions of ruby installed
> > in the system by rbenv.
> > 
> > Since I often change default ruby in interactive shell, this may
> > break the ruby for sysadmin job in crontab. What’s the solution for
> > this?
> 
> Everywhere it matters, set an explicit PATH at the beginning.
> 
> There is no other solution.

Err, I know nothing about the subject but that doesn't seem to
correspond with what it says in the readme at
https://github.com/rbenv/rbenv

But it sounds like what p...@ymail.ne.jp is doing isn't best practice
either, although I don't fully understand what they mean by "I often
change default ruby in interactive shell". If they mean 'global' then I
suspect they should be using 'local' instead. Or just possibly 'shell'.

> -dsr-

Re: auto restarting in crontab

[Jude DaShiell]

I tried installing task-lxqt-desktop using apt and that didn't go well at
all.  Since I use a screen reader I ended up installing bullseye mate with
the installation disc then upgrading to bookworm.  That worked.  So far as
I can tell, a11y work was not done on lxqt to bring up orca if speakup got
used during an install.  I was curious as to differences between mate and
lxqt which is why I tried the install.


Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Thu, 16 Mar 2023, Dan Ritter wrote:

> p...@ymail.ne.jp wrote:
> > For dev stuff, for example, I have many versions of ruby installed in the 
> > system by rbenv.
> >
> > Since I often change default ruby in interactive shell, this may break the 
> > ruby for sysadmin job in crontab. What?s the solution for this?
>
>
> Everywhere it matters, set an explicit PATH at the beginning.
>
> There is no other solution.
>
> -dsr-
>
>

Re: auto restarting in crontab

[Dan Ritter]

p...@ymail.ne.jp wrote: 
> For dev stuff, for example, I have many versions of ruby installed in the 
> system by rbenv.
> 
> Since I often change default ruby in interactive shell, this may break the 
> ruby for sysadmin job in crontab. What’s the solution for this?


Everywhere it matters, set an explicit PATH at the beginning.

There is no other solution.

-dsr-

Re: Re: auto restarting in crontab

[pyh]

For dev stuff, for example, I have many versions of ruby installed in the 
system by rbenv.

Since I often change default ruby in interactive shell, this may break the ruby 
for sysadmin job in crontab. What’s the solution for this?

Re: auto restarting in crontab

[Nicolas George]

Greg Wooledge (12023-03-16):
>   So they installed
> parallel toolsets (commands including ps, echo, and so on) in two
> different directories.

Four: there is also /usr/xpg4/bin and /usr/xpg6/bin.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 01:57:26PM +0100, Christoph Brinkhaus wrote:
> I think you are right. The only remaining argument for specifying the
> complete path I have read about is as below.
> There might be the situation with different binaries but similar
> names. For example /usr/bin/nc is different to /bin/nc.
> But such a system should be a nightmare and I doubt if you can find
> such an installation in the wild.

This reminds me of Solaris.  As a successor to the BSD-ish SunOS, Solaris
(which is a System V-ish operating system) wanted to retain some
compatibility with its company's former product.  So they installed
parallel toolsets (commands including ps, echo, and so on) in two
different directories.  The SysV-ish command set, which is the preferred
one going forward, is in /usr/bin.  The BSD-ish command set, the legacy
one, is in /usr/ucb.

Users who want a BSD-ish experience (or scripts relying on that toolset)
are encouraged to make sure /usr/ucb appears before /usr/bin in their
PATH variables.  Users who want the new SysV-ish experience should do
the opposite, or not include /usr/ucb at all.

Re: auto restarting in crontab

[Christoph Brinkhaus]

Am Thu, Mar 16, 2023 at 07:27:22AM -0400 schrieb Greg Wooledge:
> On Thu, Mar 16, 2023 at 12:24:10PM +0100, Christoph Brinkhaus wrote:
> > The environments of login shells and crontab can be different. This
> > includes the path where to seek executables. Therefore it is good
> > practice not to write just the name of the executable as nc but the
> > name with the path as /usr/bin/nc. Here I took nc as an example.
> 
> It's better to set the PATH variable to whatever you need it to be.
> Then you don't have to hard-code the execution path of every single
> command in the script.  (Which means your script breaks when you move
> it to a system where nc is in /bin instead of /usr/bin, and so on.)
> 
I think you are right. The only remaining argument for specifying the
complete path I have read about is as below.
There might be the situation with different binaries but similar
names. For example /usr/bin/nc is different to /bin/nc.
But such a system should be a nightmare and I doubt if you can find
such an installation in the wild.

I have a few scripts which should run at Linux and FreeBSD. In the
past I have used uname to distinguish the platforms. This works but it
is bulky and ugly. Things will be fine if I concat the PATH required
for both systems and follow your advise.

Thank you and kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 12:24:10PM +0100, Christoph Brinkhaus wrote:
> The environments of login shells and crontab can be different. This
> includes the path where to seek executables. Therefore it is good
> practice not to write just the name of the executable as nc but the
> name with the path as /usr/bin/nc. Here I took nc as an example.

It's better to set the PATH variable to whatever you need it to be.
Then you don't have to hard-code the execution path of every single
command in the script.  (Which means your script breaks when you move
it to a system where nc is in /bin instead of /usr/bin, and so on.)

Re: auto restarting in crontab

[Christoph Brinkhaus]

Am Thu, Mar 16, 2023 at 08:55:54AM +0800 schrieb cor...@free.fr:
> Greetings,
> 
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.
> 
> #!/bin/bash
> 
> # scan the port
> nc -z 127.0.0.1 3000
> 
> if [ $? -eq 0 ];then
>   exit
> else
>   killall node
>   sleep 1
>   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> fi
> 
> 
> I can run the script by manual, but in crontab it won't work. that means,
> when node.js dies, it will not get restarted by this script automatically.
> 
The environments of login shells and crontab can be different. This
includes the path where to seek executables. Therefore it is good
practice not to write just the name of the executable as nc but the
name with the path as /usr/bin/nc. Here I took nc as an example.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: auto restarting in crontab

[Nicolas George]

Greg Wooledge (12023-03-16):
> That assumes you want to detach the process from its session in the
> first place.  It's NOT what you should do when running a managed
> service, though.
> 
> With a managed service, you don't want ANY of the old legacy "I want
> to run a daemon from an interactive shell and have it automatically
> separate itself from the interactive session" rubbish.

Indeed. But in the rare cases you want that rubbish, DO NOT USE nuhup.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 08:53:55AM +0100, Nicolas George wrote:
> cor...@free.fr (12023-03-16):
> >   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> 
> What Greg said. Plus:
> 
> Never use nohup. nohup should never have been invented, it is based on a
> complete lack of understanding of how sessions and control terminal
> work.
> 
> Instead:
> 
> - use setsid to detach the process from the session;
> 
> - explicitly redirect the input and outputs where you want them.

That assumes you want to detach the process from its session in the
first place.  It's NOT what you should do when running a managed
service, though.

With a managed service, you don't want ANY of the old legacy "I want
to run a daemon from an interactive shell and have it automatically
separate itself from the interactive session" rubbish.  You DON'T
want the daemon to fork a background child and abandon it.  You DON'T
want the daemon's output to be discarded, or automatically redirected
to some file.

The service manager needs the daemon to behave sensibly, at least in
systemd's "simple" case.  A single process, with output going to stdout
and/or stderr.  The manager will take care of grabbing the output and
logging it.

Re: auto restarting in crontab

[Nicolas George]

cor...@free.fr (12023-03-16):
>   nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &

What Greg said. Plus:

Never use nohup. nohup should never have been invented, it is based on a
complete lack of understanding of how sessions and control terminal
work.

Instead:

- use setsid to detach the process from the session;

- explicitly redirect the input and outputs where you want them.

Regards,

-- 
  Nicolas George

Re: auto restarting in crontab

[coreyh]

updated: Thanks for all your helps, especially @Greg and @Yong

Now this systemd service has been enabled and just works.
I put a file on /etc/systemd/system/xxx.service whose content as,

[Unit]
Description=xxx Front
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=corey
Group=corey
ExecStart=serve -s /home/corey/workspace/xxx-frontend/build

[Install]
WantedBy=multi-user.target


And run "systemctl enable xxx.service" then "systemctl start 
xxx.service", and it works perfectly.


regards,
Corey

Re: auto restarting in crontab

[Jeremy Ardley]

On 16/3/23 12:09, p...@ymail.ne.jp wrote:
Just for fun, I asked this question on ChatGPT, who gives the answers 
as follows.


Q:  Please help generate a systemd configuration for Debian linux

A: Sure, here's an example of a systemd configuration file for a 
Debian Linux service:


Be very careful of ChatGPT4.0 it makes many more errors than ChatGPT3.5 
and seems to have less memory of past questions but makes up for it by 
being very wordy and slow.


Most cases today I get a general gist from it but have to go reliable 
sources for an actual implementation



--
Jeremy
(Lists)

Re: auto restarting in crontab

[p...@ymail.ne.jp]

Just for fun, I asked this question on ChatGPT, who gives the answers as 
follows.


Q:  Please help generate a systemd configuration for Debian linux

A: Sure, here's an example of a systemd configuration file for a Debian 
Linux service:


```
[Unit]
Description=My Service
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5s
ExecStart=/usr/bin/my-service

[Install]
WantedBy=multi-user.target
```

In this example, replace `My Service` with the name of your service, and 
`/usr/bin/my-service` with the path to your service's executable.


Save this file with a `.service` extension, for example, 
`my-service.service`, and place it in the `/etc/systemd/system` directory.


Then, enable the service using the following command:

```
systemctl enable my-service.service
```

This will cause the service to start automatically at boot time.

You can start, stop, and restart the service using the following commands:

```
systemctl start my-service.service
systemctl stop my-service.service
systemctl restart my-service.service
```

You can also view the logs of the service using the following command:

```
journalctl -u my-service.service
```

This will show the logs for your service.

Thanks
Yong

p...@ymail.ne.jp wrote:



cor...@free.fr wrote:

where will I setup this script for systemd job? any reference?


You might look at this article as well.
https://linuxhandbook.com/create-systemd-services/

Yong

Re: auto restarting in crontab

[p...@ymail.ne.jp]

cor...@free.fr wrote:

where will I setup this script for systemd job? any reference?


You might look at this article as well.
https://linuxhandbook.com/create-systemd-services/

Yong

Re: auto restarting in crontab

[Greg Wooledge]

On Thu, Mar 16, 2023 at 09:40:48AM +0800, cor...@free.fr wrote:
> On 16/03/2023 09:32, Greg Wooledge wrote:
> > If that's more than you want to tackle, and if all you want is
> > automatic restarting (not the ability to stop it at will), then this
> > should suffice:
> > 
> > #!/bin/sh
> > PATH=/whatver/you/need
> > while true; do
> > serve -s /path/to/your/service
> > sleep 5
> > done
> > 
> > Then arrange for this script to be executed at boot time, and that's it.
> > No background stuff, no polling from crontab.  Just a simple loop.
> 
> Thanks Greg. I will update with the way you gave.
> where will I setup this script for systemd job? any reference?

Well... see, normally you wouldn't use this script *and* systemd.
This script is something you'd use *instead* of creating a systemd unit.

If you're going to use a shell script to set up the PATH and other
environment variables and chain-load the service, but manage it all with
systemd, then the script would look something like this:

#!/bin/sh
set -a
PATH=/whatever/you/need
SOME_OTHER_VAR=stuff
exec serve -s /path/to/your/service

Even this is still considered less than optimal, but it does simplify
maintenance.  If you need to adjust the service's environment frequently,
you can edit the shell script more easily than you can edit the unit
file.  So, using this hybrid approach isn't the worst thing you could do.

Now, in terms of setting up the unit file -- assuming you want a
system-wide service rather than a --user service, I'd go in one of two
directions, depending on whether you want to run it as yourself, or as
a dedicated user.

If you're going to run it as yourself, albeit in a system-wide unit,
I'd put it in your $HOME/bin/ directory.  That's where it makes sense
to put scripts that you've written that only you use.

If you're going to set up a dedicated user account to run it, then I'd
put the script in /usr/local/bin or /usr/local/sbin.  (But realistically,
the hybrid approach with a systemd unit *and* a script doesn't really
fit with the dedicated user.)

For writing a unit file, there's a basic tutorial at
.

I don't know how your service works (or Node.js, for that matter),
so I'm not sure if you want a "simple" service, or a "forking" service.
Let's assume "simple" at first.  This is appropriate if the service
is a single process that runs in the foreground and doesn't create
any child processes.

You also need a name.  Let's call it coreyserver.  And let's say you're
going to run it as yourself, and that your username is corey.

Then this unit file might work:

[Unit]
Description=Corey Server
After=network.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=corey
Group=corey
ExecStart=/home/corey/bin/coreyserver

[Install]
WantedBy=multi-user.target

Re: auto restarting in crontab

[coreyh]

On 16/03/2023 09:32, Greg Wooledge wrote:

On Wed, Mar 15, 2023 at 08:00:20PM -0500, Nicholas Geovanis wrote:

On Wed, Mar 15, 2023, 7:56 PM  wrote:
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.


There's so much wrong with that.

If you want to manage a service, the *best* thing you could do would be
to write a systemd unit for it (either a system-wide unit, or a --user
unit, your choice).  Let systemd start it, restart it automatically 
when

it dies if that's what you want, and so on.

If that's more than you want to tackle, and if all you want is
automatic restarting (not the ability to stop it at will), then this
should suffice:

#!/bin/sh
PATH=/whatver/you/need
while true; do
serve -s /path/to/your/service
sleep 5
done

Then arrange for this script to be executed at boot time, and that's 
it.

No background stuff, no polling from crontab.  Just a simple loop.




Thanks Greg. I will update with the way you gave.
where will I setup this script for systemd job? any reference?

regards





>nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &


This will log stdout and stderr in nohup.out in the working directory.
Look for errors there.  I bet it's a PATH issue.

Cron jobs run in a sanitized environment and may not be running with 
the

permissions you have as root on the command line.


I doubt the permissions are different.  Probably just PATH and maybe 
some

other environment variables that the Javascript program expects, but
which are not present in cron's environment.

Re: auto restarting in crontab

[Greg Wooledge]

On Wed, Mar 15, 2023 at 08:00:20PM -0500, Nicholas Geovanis wrote:
> On Wed, Mar 15, 2023, 7:56 PM  wrote:
> > My script for monitoring Node.js app as follows. I put it in crontab for
> > auto-check and restart if failure.

There's so much wrong with that.

If you want to manage a service, the *best* thing you could do would be
to write a systemd unit for it (either a system-wide unit, or a --user
unit, your choice).  Let systemd start it, restart it automatically when
it dies if that's what you want, and so on.

If that's more than you want to tackle, and if all you want is
automatic restarting (not the ability to stop it at will), then this
should suffice:

#!/bin/sh
PATH=/whatver/you/need
while true; do
serve -s /path/to/your/service
sleep 5
done

Then arrange for this script to be executed at boot time, and that's it.
No background stuff, no polling from crontab.  Just a simple loop.

> >nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &

This will log stdout and stderr in nohup.out in the working directory.
Look for errors there.  I bet it's a PATH issue.

> Cron jobs run in a sanitized environment and may not be running with the
> permissions you have as root on the command line.

I doubt the permissions are different.  Probably just PATH and maybe some
other environment variables that the Javascript program expects, but
which are not present in cron's environment.

Re: auto restarting in crontab

[Nicholas Geovanis]

On Wed, Mar 15, 2023, 7:56 PM  wrote:

> Greetings,
>
> My script for monitoring Node.js app as follows. I put it in crontab for
> auto-check and restart if failure.
>
> #!/bin/bash
>
> # scan the port
> nc -z 127.0.0.1 3000
>
> if [ $? -eq 0 ];then
>exit
> else
>killall node
>sleep 1
>nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
> fi
>
>
> I can run the script by manual, but in crontab it won't work. that
> means, when node.js dies, it will not get restarted by this script
> automatically.
>
> Can you give any hints?
>

Cron jobs run in a sanitized environment and may not be running with the
permissions you have as root on the command line.

Thanks
> Corey Hickman
>
>

auto restarting in crontab

[coreyh]

Greetings,

My script for monitoring Node.js app as follows. I put it in crontab for 
auto-check and restart if failure.


#!/bin/bash

# scan the port
nc -z 127.0.0.1 3000

if [ $? -eq 0 ];then
  exit
else
  killall node
  sleep 1
  nohup serve -s  /home/myUsername/workspace/xxx-frontend/build &
fi


I can run the script by manual, but in crontab it won't work. that 
means, when node.js dies, it will not get restarted by this script 
automatically.


Can you give any hints?

Thanks
Corey Hickman