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

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

Script vs command line behaviour

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

Contents

  Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 14:40 +0200
    Re: Script vs command line behaviour Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-12 14:50 +0200
      Re: Script vs command line behaviour Frédéric Marchal <frederic.marchal@wowtechnology.com> - 2016-10-12 15:30 +0200
      Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 15:50 +0200
        Re: Script vs command line behaviour Greg Wooledge <wooledg@eeg.ccf.org> - 2016-10-12 16:00 +0200
          Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 16:20 +0200
            Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-12 16:30 +0200
              Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 17:10 +0200
                Re: Script vs command line behaviour Darac Marjal <mailinglist@darac.org.uk> - 2016-10-12 17:20 +0200
                Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-12 17:20 +0200
                  Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 16:50 +0200
                    Re: Script vs command line behaviour Nicolas George <george@nsup.org> - 2016-10-13 17:00 +0200
                      Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-14 01:10 +0200
              Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:30 +0200
                Re: Script vs command line behaviour Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-14 02:50 +0200
        Re: Script vs command line behaviour Gene Heskett <gheskett@shentel.net> - 2016-10-12 16:40 +0200
          Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-12 17:20 +0200
            Re: Script vs command line behaviour Frank <zuiderduin@gmx.com> - 2016-10-12 18:00 +0200
              Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:20 +0200
      Re: Script vs command line behaviour Andre Majorel <aym-naibed@teaser.fr> - 2016-10-15 11:50 +0200
        Re: Script vs command line behaviour Henrique de Moraes Holschuh <hmh@debian.org> - 2016-10-15 15:50 +0200
    Re: Script vs command line behaviour Jude DaShiell <jdashiel@panix.com> - 2016-10-12 23:00 +0200
      Re: Script vs command line behaviour Mark Fletcher <mark27q1@gmail.com> - 2016-10-13 01:00 +0200

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

#173492

On Sat, 15 Oct 2016, Andre Majorel wrote:
> Or is pkill more than a wrapper around kill(pid, 15) and
> kill(pid, 9) ?

pkill is quite less prone to killing the wrong process due to a race
when you use it properly.

In the general case one should avoid SIGKILL.  Trying other signals that
allow for orderly exit first is extremely recommended.  SIGTERM being
the typical one you'd want.  There is also SIGQUIT, but too many
programers get it wrong and trap SIGTERM for clean exit, but forget to
actually trap SIGQUIT as well.

> I used to have a user who had the bad habit of indiscriminately
> going straight for SIGKILL. It was annoying. But not as much as
> the fact that SIGKILL can't do anything about processes stuck in
> "D" state. I really wish I knew a way to get rid of these.

Processes are stuck in "D" state when the kernel is doing something on
their behalf.

State "D" is not really "waiting for IO" as I have seen people describe
it, it would be more correct to call it "in the middle of a syscall".
"waiting for IO" is just a subset of the reasons why a process can get
stuck in "D" state... even if it is the most common one (AFAIK).

-- 
  Henrique Holschuh

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

#173458

On Wed, 12 Oct 2016, Mark Fletcher wrote:

> Date: Wed, 12 Oct 2016 08:34:22
> From: Mark Fletcher <mark27q1@gmail.com>
> To: debian-user@lists.debian.org
> Subject: Script vs command line behaviour
> Resent-Date: Wed, 12 Oct 2016 12:34:43 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> Greetings
>
> I am observing a strange behaviour and I am wondering what stupid thing
> I have done that is causing it. A shell command that is supposed to
> start fetchmail running every 15 minutes works fine run from the command
> line, but has no effect when run from inside a script. I am running
> Jessie upgraded many times from an original install from etch, I think
> it was. Or squeeze. Whichever of those two it was that came first.
>
> I recently took the plunge and installed Amanda to get my backups
> organised. At the moment I am only backing up the one machine but will
> expand it later to other machines on my network.
>
> Automating the Amanda backup once I was happy with the configuration
> prompted me to write a small bash shell script, reproduced below. It
> expects to run as root. It stops the svnserve instance running on my
> machine and a mysql instance, and also stops the fetchmail daemon. Then
> it starts with a basic amanda config and, if my Windows VMs are not
> running, adds their disks and config directories to the stuff that is in
> scope for backup. If they are running it refrains from including them.
> Then, it kicks off the backup, running as the backup user. Finally, it
> restarts the services it stopped.
>
> Then I have created a systemd service to run this script, and set up a
> systemd timer to kick off the pocess at 01:30 local time every day.
>
> It runs fine, at the right time, except for one thing. When I get up in
> the morning and come to my computer, I find that the backup report is
> sitting in my email reporting success, SVNServe is running as it should
> be, mysql is running as it should be -- but fetchmail has not been
> restarted.
>
> If I do sudo journalctl -b | grep fetchmail and look at this morning's
> entries, I see the following:
>
> Oct 12 01:30:02 kazuki sudo[2197]: root : TTY=unknown ; PWD=/ ;
> USER=mark ; COMMAND=/usr/bin/fetchmail -q Oct 12 01:30:02 kazuki
> homebackup.sh[2154]: fetchmail: background fetchmail at 31717 killed.
>
> Oct 12 04:19:04 kazuki sudo[3582]: root : TTY=unknown ; PWD=/ ;
> USER=mark ; COMMAND=/usr/bin/fetchmail -d 900
>
> [lines justified to be easier to read]
>
> The first of those lines indicates the script successfully stopped
> fetchmail at 01:30 before starting the backup.
>
> The second would appear to indicate at least that it correctly attempted
> to start fetchmail again, as my non-privileged user mark, at 04:19 when
> the backup finished. But, when I came to my computer at about 07:30 this
> morning, fetchmail was not running and all the mails to this list from
> you lovely people were backed up at my email provider waiting to be
> downloaded.
>
> I started fetchmail by hand from the command line, and came home this
> evening to find it still running sweetly. And it'll continue to do so
> until tonight's backup run kills it, at which point I'll get up tomorrow
> morning to find it is not running again, if the experience of the last
> few days is anything to go by.
>
> If I copy and paste the line that is supposed to restart fetchmail from
> the script (reproduced below) to a root shell, with PWD=/, and run the
> command, it works, correctly. I am stumped why it is not working from
> the script. Anyone see what I have missed? I wondered if it was paths
> not being set right, but from the above journal log you can see it
> correctly mapped the fetchmail instance to /usr/bin/fetchmail.
>
>
> /etc/systemd/scripts/homebackup.sh:
>
> #! /bin/bash
>
> # THIS ASSUMES MYSQL AND SVNSERVE ARE RUNNING, AND WE WANT THEM RUNNING
> # AGAIN ONCE DONE
>
> # stop a couple of services we don't want running while doing backups
> systemctl stop mysql
> systemctl stop svnserve
>
> # The systemctl stop for svnserve may not work as I haven't got around to
> # making a stop script for it.
> # So kill the process the old fashioned way
> ps -ef | grep svnserve | grep -v grep | awk '{print $2}' | xargs kill -9
>
> # And kill fetchmail so it doesn't update the mail while we are backing up
> sudo -u mark fetchmail -q
>
> # Start with the base disklist
> cp /etc/amanda/RealBackup/disklist.stem /etc/amanda/RealBackup/disklist
>
> # If the two VirtualBox VMs are NOT running, add them to the disk list
> sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo localhost /opt/vms/TRADER2 comp-user-tar >> /etc/amanda/RealBackup/disklist
> sudo -u mark vboxmanage showvminfo "TRADER2" | grep -q "running (since" || echo "localhost "\""/home/mark/VirtualBox VMs/TRADER2"\"" comp-user-tar" >> /etc/amanda/RealBackup/disklist
> sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo localhost /opt/vms/TRADER3 comp-user-tar >> /etc/amanda/RealBackup/disklist
> sudo -u mark vboxmanage showvminfo "TRADER3" | grep -q "running (since" || echo "localhost "\""/home/mark/VirtualBox VMs/TRADER3"\"" comp-user-tar" >> /etc/amanda/RealBackup/disklist
>
> # Now actually run the backup
> sudo -u backup amdump RealBackup
>
> # and restart the services we stopped
> systemctl start svnserve
> systemctl start mysql
> sudo -u mark fetchmail -d 900
>
>
>
> Mark
>
I think the issue revolves around unknown pwd.  Perhaps running fetchmail 
as the user rather than root will solve that problem.
>

--

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

#173459

On Wed, Oct 12, 2016 at 04:51:40PM -0400, Jude DaShiell wrote:

> ># and restart the services we stopped
> >systemctl start svnserve
> >systemctl start mysql
> >sudo -u mark fetchmail -d 900
> >
> I think the issue revolves around unknown pwd.  Perhaps running fetchmail as
> the user rather than root will solve that problem.

sudo -u mark fetchmail -d 900   _IS_ running fetchmail as the user, no?

Mark

[toc] | [prev] | [standalone]

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

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

csiph-web