Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #256079 > unrolled thread

auto restarting in crontab

Back to article view | Back to linux.debian.user

Contents

  auto restarting in crontab coreyh@free.fr - 2023-03-16 02:00 +0100
    Re: auto restarting in crontab Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-03-16 02:10 +0100
      Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-16 02:40 +0100
        Re: auto restarting in crontab coreyh@free.fr - 2023-03-16 02:50 +0100
          Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-16 04:20 +0100
            Re: auto restarting in crontab coreyh@free.fr - 2023-03-16 07:30 +0100
          Re: auto restarting in crontab "pyh@ymail.ne.jp" <pyh@ymail.ne.jp> - 2023-03-16 05:00 +0100
            Re: auto restarting in crontab "pyh@ymail.ne.jp" <pyh@ymail.ne.jp> - 2023-03-16 05:10 +0100
              Re: auto restarting in crontab Jeremy Ardley <jeremy@ardley.org> - 2023-03-16 06:00 +0100
    Re: auto restarting in crontab Nicolas George <george@nsup.org> - 2023-03-16 09:00 +0100
      Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-16 12:10 +0100
        Re: auto restarting in crontab Nicolas George <george@nsup.org> - 2023-03-16 12:10 +0100
    Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-16 12:30 +0100
      Re: auto restarting in crontab Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-16 14:00 +0100
        Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-16 14:10 +0100
          Re: auto restarting in crontab Nicolas George <george@nsup.org> - 2023-03-16 14:20 +0100
            Re: Re: auto restarting in crontab pyh@ymail.ne.jp - 2023-03-16 17:30 +0100
              Re: auto restarting in crontab Dan Ritter <dsr@randomstring.org> - 2023-03-16 18:40 +0100
                Re: auto restarting in crontab Jude DaShiell <jdashiel@panix.com> - 2023-03-16 19:00 +0100
                Re: auto restarting in crontab debian-user@howorth.org.uk - 2023-03-16 23:20 +0100
                  Re: auto restarting in crontab Dan Ritter <dsr@randomstring.org> - 2023-03-17 00:10 +0100
                    Re: auto restarting in crontab Jeffrey Walton <noloader@gmail.com> - 2023-03-17 00:40 +0100
                    Re: auto restarting in crontab Nicolas George <george@nsup.org> - 2023-03-17 13:20 +0100
                    Re: auto restarting in crontab debian-user@howorth.org.uk - 2023-03-17 13:20 +0100
                  Re: auto restarting in crontab "pyh@ymail.ne.jp" <pyh@ymail.ne.jp> - 2023-03-17 01:10 +0100
                    Re: auto restarting in crontab Greg Wooledge <greg@wooledge.org> - 2023-03-17 01:20 +0100
                    Re: auto restarting in crontab debian-user@howorth.org.uk - 2023-03-17 13:30 +0100
    Re: auto restarting in crontab Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-16 12:30 +0100

Page 1 of 2  [1] 2  Next page →

#256079 — auto restarting in crontab

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

[toc] | [next] | [standalone]

#256080

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 15, 2023, 7:56 PM <coreyh@free.fr> 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
>
>

[toc] | [prev] | [next] | [standalone]

#256081

On Wed, Mar 15, 2023 at 08:00:20PM -0500, Nicholas Geovanis wrote:
> On Wed, Mar 15, 2023, 7:56 PM <coreyh@free.fr> 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.

[toc] | [prev] | [next] | [standalone]

#256082

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 <coreyh@free.fr> 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.

[toc] | [prev] | [next] | [standalone]

#256083

On Thu, Mar 16, 2023 at 09:40:48AM +0800, coreyh@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
<https://wiki.debian.org/systemd/Services>.

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

[toc] | [prev] | [next] | [standalone]

#256088

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

[toc] | [prev] | [next] | [standalone]

#256084

coreyh@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

[toc] | [prev] | [next] | [standalone]

#256085

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

pyh@ymail.ne.jp wrote:
> 
> 
> coreyh@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
> 

[toc] | [prev] | [next] | [standalone]

#256086

On 16/3/23 12:09, pyh@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)

[toc] | [prev] | [next] | [standalone]

#256091

coreyh@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

[toc] | [prev] | [next] | [standalone]

#256093

On Thu, Mar 16, 2023 at 08:53:55AM +0100, Nicolas George wrote:
> coreyh@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.

[toc] | [prev] | [next] | [standalone]

#256094

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

[toc] | [prev] | [next] | [standalone]

#256095

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.)

[toc] | [prev] | [next] | [standalone]

#256097

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.

[toc] | [prev] | [next] | [standalone]

#256098

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.

[toc] | [prev] | [next] | [standalone]

#256099

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

[toc] | [prev] | [next] | [standalone]

#256101

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?

[toc] | [prev] | [next] | [standalone]

#256103

pyh@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-

[toc] | [prev] | [next] | [standalone]

#256106

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 <jdashiel at panix dot com>
"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:

> pyh@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-
>
>

[toc] | [prev] | [next] | [standalone]

#256109

Dan Ritter <dsr@randomstring.org> wrote:
> pyh@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 pyh@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-

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web