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

Groups > linux.debian.user > #173452

Re: Script vs command line behaviour

Show all headers | View raw

On Thu, Oct 13, 2016 at 12:09:12AM +0900, Mark Fletcher wrote:
>On Wed, Oct 12, 2016 at 04:29:01PM +0200, Nicolas George wrote:
>> Le primidi 21 vendémiaire, an CCXXV, Mark Fletcher a écrit :
>> > Fetchmail isn't set up as a service through systemd, although mysql and
>> > svnserve are. fetchmail is just started from this script (or supposed to
>> > be!) and launched by hand from the command line when that fails.
>> >
>> > So at least systemd isn't complicating the issue.
>>
>> Maybe it is. Unlike SysV init and the other legacy tools, systemd keeps
>> tracks of the processes it starts, grouping them as "units" using pgroups.
>> Your script tries to start fetchmail in background, using the -d option
>> (which, by the way, is not present in the man page for the testing version,
>> unless I have trouble reading); that would allow it to escape SysV init and
>> cron, for example, but not systemd.
>>
>> I do not know the exact rules systemd applies to the processes started by a
>> timer, but it is entirely possible this is the source of your problem.
>> Remember when all the systemd haters started shouting "systemd broke screen
>> and tmux" because the option to clean up the processes in finished user
>> sessions had been activated by default.
>>
>You bring up a good point, actually. I'm calling systemctl stop and
>systemctl start to stop and start mysql -- and I'm doing that in a
>script that is itself being called by a systemd unit (the one triggered
>by the timer). I wonder if that is in some way naughty and contributing
>to the problem? Hmmm, is there a better way to ensure these services are
>stopped before the backup starts and started again afterwards?

https://www.freedesktop.org/software/systemd/man/systemd.unit.html says

Conflicts=
  A space-separated list of unit names. Configures negative requirement 
  dependencies. If a unit has a Conflicts= setting on another unit, 
  starting the former will stop the latter and vice versa. Note that 
  this setting is independent of and orthogonal to the After= and 
  Before= ordering dependencies.

  If a unit A that conflicts with a unit B is scheduled to be started at 
  the same time as B, the transaction will either fail (in case both are 
  required part of the transaction) or be modified to be fixed (in case 
  one or both jobs are not a required part of the transaction). In the 
  latter case, the job that is not the required will be removed, or in 
  case both are not required, the unit that conflicts will be started 
  and the unit that is conflicted is stopped.

So you should, in theory, be able to add "Conflicts=mysql" to your unit 
and systemd will arrange for it to be stopped before running your unit, 
and started thereafter.

>
>Although that said, MySQL and SVNServe (which are started by systemd) go
>down and come back up fine, it is the one that ISN'T currently
>controlled by systemd that I am having problems with.
>
>Hmmm, interesting, although I'm not sure quite what to do with that...
>
>Mark
>

-- 
For more information, please reread.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web