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 2 of 2 — ← Prev page 1 [2]

#256110

debian-user@howorth.org.uk wrote: 
> 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

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-

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

#256111

On Thu, Mar 16, 2023 at 7:03 PM Dan Ritter <dsr@randomstring.org> wrote:
>
> debian-user@howorth.org.uk wrote:
> > 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
>
> 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

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

#256119

debian-user@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

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

#256120

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

Dan Ritter <dsr@randomstring.org> wrote:
> debian-user@howorth.org.uk wrote: 
> > 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  
> 
> 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-

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

#256112

debian-user@howorth.org.uk wrote:
> But it sounds like whatpyh@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

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

#256113

On Fri, Mar 17, 2023 at 08:04:24AM +0800, pyh@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.

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

#256121

"pyh@ymail.ne.jp" <pyh@ymail.ne.jp> wrote:
> debian-user@howorth.org.uk wrote:
> > But it sounds like whatpyh@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

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

#256096

Am Thu, Mar 16, 2023 at 08:55:54AM +0800 schrieb coreyh@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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web