Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

2016-07-15 Thread David Timothy Strauss 
On Thu, Jul 14, 2016, 19:07 Kai Hendry  wrote:

> I would love to see that 10 lines of shell you claimed, but I think you
> might be underestimating the fine work that went into Dokku!
>

It's not so much underestimating the work in Dokku as much as leveraging
what systemd and a tool like haproxy provide for services.

Here's what a script would do with no socket activation, assuming you're
sending traffic to the services with a tool like haproxy and have an
interface like a control socket [1]:

   1. Tell haproxy to stop sending traffic to service instance A.
   2. systemctl restart instance-a.service
   3. Tell haproxy to start sending traffic to service instance A and stop
   to B.
   4. systemctl restart instance-b.service
   5. Tell haproxy to start sending traffic to service instance B.

Alternatively, you could track state of a flip-flop and stabilize on only
one service instance at a time after the restart.

[1] https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd IPMasquerade

2016-07-15 Thread Lennart Poettering 
On Fri, 15.07.16 13:49, Chris Trobridge (christrobri...@hotmail.com) wrote:

> I have managed to configure enough support in my kernel to enable me
> to use nft to establish IP Masquerading but systemd-networkd is
> still reporting "Could not enable IP masquerading: Operation not
> supported".  What kernel configuration is required for systemd to
> control IP masquerading?
>
> I have the nftables userland tools installed but are there any other
> packages required by systemd?

networkd and nspawn use the "iptables" kernel APIs, not "nftables", as
that is not really universally available yet. Our intention is
certainly to support nftables eventuall, but we aren#t there yet.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Boot error on PowerPC

2016-07-15 Thread Lennart Poettering 
On Wed, 13.07.16 15:22, Alessio Igor Bogani (alessioigorbog...@gmail.com) wrote:

> Dear systemd developers and maintainers,
> 
> I incurred in the following error during the boot on a PowerPC based
> on MPC7410 cpu using systemd v230:
> 

> systemd[131]: Failed to execute
> /lib/systemd/system-generators/systemd-dbus1-generator: Connection
> reset by peer
> systemd[125]: /lib/systemd/system-generators/systemd-system-update-generator
> is empty (a mask).
> systemd[125]: /lib/systemd/system-generators/systemd-sysv-generator is
> empty (a mask).
> systemd[125]: /lib/systemd/system-generators/systemd-fstab-generator
> is empty (a mask).
> systemd[125]: 
> /lib/systemd/system-generators/systemd-hibernate-resume-generator
> succeeded.
> systemd[130]: Failed to execute
> /lib/systemd/system-generators/systemd-rc-local-generator: Connection
> reset by peer
> systemd[129]: Failed to execute
> /lib/systemd/system-generators/systemd-debug-generator: Exec format
> error

If execv() fails with ECONNRESET or ENOEXEC then there's mostly likely
something wrong with your toolset I would say. This smells like some
issue with your compiler or linker, but not with systemd at all...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount units and automatic (un)mounts

2016-07-15 Thread Andrei Borzenkov 
15.07.2016 19:50, Alad Wenter пишет:
...

>>
>>> "systemctl reset-failed" is issued (note that appending the .mount unit
>>> doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
>>> not loaded" error).
>>>
>> So how exactly do you call it?
> % sudo systemctl reset-failed mnt-transcend\x2dsdhc.mount
> Failed to reset failed state of unit mnt-transcendx2dsdhc.mount: Unit
> mnt-transcendx2dsdhc.mount is not loaded.
> 

Sorry if I was not clear. You said this did not work, implying some
other invocation did. If "appending .mount unit does not work", I expect
some other command that *does* work?

> Being now aware of the distinction between in-memory and static units, I
> assume this is due to mnt-transcend\x2dsdhc.mount being in-memory? The
> reset-failed command works as expected with .mount units which are on disk.

Well, if this mount unit was instantiated from /proc/self/mountinfo,
then goes away then of course systemd does not know anything about it
any more.

...

>>> [Service]
>>> Type=oneshot
>>> RemainAfterExit=yes
>>> ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs
>>>
>>> [Install]
>>> WantedBy=local-fs.target
>>>
>>> However, according to the systemd.mount(5), .mount units will be
>>> generated either way. Oddly enough, when using the above service they
>>> don't seem to cause automatic mounts/unmounts.
>>>
>> Because in this case you do not have static mount units, and for
>> transient mount units (created from external mount event) things were
>> partially fixed by not requiring existing device.
> Could you give a pointer on what release this was partially fixed in? In
> the NEWS file, I only found a mention to systemd 219 which introduced
> unmounting of unavailable devices.

I mean this commit

commit 628c89cc68ab96fce2de7ebba5933725d147aecc
Author: Lennart Poettering 
Date:   Fri Feb 27 21:55:08 2015 +0100

core: rework device state logic

This change introduces a new state "tentative" for device units. Device
units are considered "plugged" when udev announced them, "dead" when
they are not available in the kernel, and "tentative" when they are
referenced in /proc/self/mountinfo or /proc/swaps but not (yet)
announced via udev.

This should fix a race when device nodes (like loop devices) are created
and immediately mounted. Previously, systemd might end up seeing the
mount unit before the device, and would thus pull down the mount because
its BindTo dependency on the device would not be fulfilled.


with lot of subsequent fixes ... this commit is included starting with v220.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount units and automatic (un)mounts

2016-07-15 Thread Alad Wenter 
Andrei Borzenkov wrote:
> 15.07.2016 19:50, Alad Wenter пишет:
> ...
>
 "systemctl reset-failed" is issued (note that appending the .mount unit
 doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
 not loaded" error).

>>> So how exactly do you call it?
>> % sudo systemctl reset-failed mnt-transcend\x2dsdhc.mount
>> Failed to reset failed state of unit mnt-transcendx2dsdhc.mount: Unit
>> mnt-transcendx2dsdhc.mount is not loaded.
>>
> Sorry if I was not clear. You said this did not work, implying some
> other invocation did. If "appending .mount unit does not work", I expect
> some other command that *does* work?

Yes, I forgot to quote the escaped name in the shell (thanks to Dave
Reisner for pointing this out). The following works:

% sudo systemctl reset-failed "mnt-transcend\x2dsdhc.mount"
>
>> Being now aware of the distinction between in-memory and static units, I
>> assume this is due to mnt-transcend\x2dsdhc.mount being in-memory? The
>> reset-failed command works as expected with .mount units which are on disk.
> Well, if this mount unit was instantiated from /proc/self/mountinfo,
> then goes away then of course systemd does not know anything about it
> any more.
>
> ...
>
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs

 [Install]
 WantedBy=local-fs.target

 However, according to the systemd.mount(5), .mount units will be
 generated either way. Oddly enough, when using the above service they
 don't seem to cause automatic mounts/unmounts.

>>> Because in this case you do not have static mount units, and for
>>> transient mount units (created from external mount event) things were
>>> partially fixed by not requiring existing device.
>> Could you give a pointer on what release this was partially fixed in? In
>> the NEWS file, I only found a mention to systemd 219 which introduced
>> unmounting of unavailable devices.
> I mean this commit
>
> commit 628c89cc68ab96fce2de7ebba5933725d147aecc
> Author: Lennart Poettering 
> Date:   Fri Feb 27 21:55:08 2015 +0100
>
> core: rework device state logic
>
> This change introduces a new state "tentative" for device units. Device
> units are considered "plugged" when udev announced them, "dead" when
> they are not available in the kernel, and "tentative" when they are
> referenced in /proc/self/mountinfo or /proc/swaps but not (yet)
> announced via udev.
>
> This should fix a race when device nodes (like loop devices) are created
> and immediately mounted. Previously, systemd might end up seeing the
> mount unit before the device, and would thus pull down the mount because
> its BindTo dependency on the device would not be fulfilled.
>
>
> with lot of subsequent fixes ... this commit is included starting with v220.
>
>
>
Understood.

Thanks,

Alad
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount units and automatic (un)mounts

2016-07-15 Thread Alad Wenter 
Andrei Borzenkov wrote:
> 15.07.2016 18:16, Alad Wenter пишет:
>> Hi,
>>
>> When a device is mounted, a matching mount unit is created per
>> systemd.mount(5):
>>
>> Mount points created at runtime (independently of unit files or
>>/etc/fstab) will be monitored by systemd and appear like any other
>>mount unit in systemd. See /proc/self/mountinfo description in
>>proc(5).
>>
>> If the device is removed while the mount is still active, systemd
>> unmounts the stale mount. However, if umount exits with a non-zero
>> status—for example, when the mount is still accessed and the drive
>> connection is flakey—the unit enters a failed state:
>>
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
>> process exited, code=exited status=32
> Please do not make things more confusing then they are already. You do
> not speak about in-memory instantiated mount units, you speak about
> static on disk mount units (may be generated from /etc/fstab but do not
> really need to).
>
>> Jul 12 17:00:34 thinkpad systemd[1]: Failed unmounting /mnt/toshiba-usb.
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Unit is
>> bound to inactive unit dev-sdc1.device. Stopping, too.
>> Jul 12 17:00:34 thinkpad systemd[1]: Unmounting /mnt/toshiba-usb...
>> Jul 12 17:00:34 thinkpad umount[6341]: umount: /mnt/toshiba-usb: target
>> is busy
>> Jul 12 17:00:34 thinkpad umount[6341]: (In some cases useful
>> info about processes that
>> Jul 12 17:00:34 thinkpad umount[6341]:  use the device is found
>> by lsof(8) or fuser(1).)
>> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
>> process exited, code=exited status=32
>>
>> On subsequent mounts, the device may be unmounted immediately unless
> This is caused not by failed (u)mount but by dis- and re-appearing
> device, when it emerges under different name.
>
>> "systemctl reset-failed" is issued (note that appending the .mount unit
>> doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
>> not loaded" error).
>>
> So how exactly do you call it?
% sudo systemctl reset-failed mnt-transcend\x2dsdhc.mount
Failed to reset failed state of unit mnt-transcendx2dsdhc.mount: Unit
mnt-transcendx2dsdhc.mount is not loaded.

Being now aware of the distinction between in-memory and static units, I
assume this is due to mnt-transcend\x2dsdhc.mount being in-memory? The
reset-failed command works as expected with .mount units which are on disk.
>
>> A few possibly related bug reports:
>>
>> https://github.com/systemd/systemd/issues/2475
>> https://github.com/systemd/systemd/issues/1741
>> https://github.com/systemd/systemd/issues/1656
>>
>> My attempt at a workaround is disabling systemd-fstab-generator per
>> systemd.generator(7), and creating a `mount -a` service which mounts
>> file systems at boot.
>>
>> [Unit]
>> Description=Mount local filesystems
>> Documentation=man:mount(8) man:systemd.mount(5) man:bootup(7)
>> DefaultDependencies=No
>> After=local-fs-pre.target
>>
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs
>>
>> [Install]
>> WantedBy=local-fs.target
>>
>> However, according to the systemd.mount(5), .mount units will be
>> generated either way. Oddly enough, when using the above service they
>> don't seem to cause automatic mounts/unmounts.
>>
> Because in this case you do not have static mount units, and for
> transient mount units (created from external mount event) things were
> partially fixed by not requiring existing device.
Could you give a pointer on what release this was partially fixed in? In
the NEWS file, I only found a mention to systemd 219 which introduced
unmounting of unavailable devices.
>> How can this be the case? Is a better approach possible?
>>
> Current approach is fundamentally incompatible with manual mounting. At
> the very least, manual mount (outside systemd) must override any static
> information systemd may have. I.e. if systemd has foo.mount for device
> /dev/foo and sysadmin manually calls "mount /dev/bar /foo", systemd has
> no business to interfere and unmount.
Thanks for the clarifications,

Alad
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount units and automatic (un)mounts

2016-07-15 Thread Andrei Borzenkov 
15.07.2016 18:16, Alad Wenter пишет:
> Hi,
> 
> When a device is mounted, a matching mount unit is created per
> systemd.mount(5):
> 
> Mount points created at runtime (independently of unit files or
>/etc/fstab) will be monitored by systemd and appear like any other
>mount unit in systemd. See /proc/self/mountinfo description in
>proc(5).
> 
> If the device is removed while the mount is still active, systemd
> unmounts the stale mount. However, if umount exits with a non-zero
> status—for example, when the mount is still accessed and the drive
> connection is flakey—the unit enters a failed state:
> 
> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
> process exited, code=exited status=32

Please do not make things more confusing then they are already. You do
not speak about in-memory instantiated mount units, you speak about
static on disk mount units (may be generated from /etc/fstab but do not
really need to).

> Jul 12 17:00:34 thinkpad systemd[1]: Failed unmounting /mnt/toshiba-usb.
> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Unit is
> bound to inactive unit dev-sdc1.device. Stopping, too.
> Jul 12 17:00:34 thinkpad systemd[1]: Unmounting /mnt/toshiba-usb...
> Jul 12 17:00:34 thinkpad umount[6341]: umount: /mnt/toshiba-usb: target
> is busy
> Jul 12 17:00:34 thinkpad umount[6341]: (In some cases useful
> info about processes that
> Jul 12 17:00:34 thinkpad umount[6341]:  use the device is found
> by lsof(8) or fuser(1).)
> Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
> process exited, code=exited status=32
> 
> On subsequent mounts, the device may be unmounted immediately unless

This is caused not by failed (u)mount but by dis- and re-appearing
device, when it emerges under different name.

> "systemctl reset-failed" is issued (note that appending the .mount unit
> doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
> not loaded" error).
> 

So how exactly do you call it?

> A few possibly related bug reports:
> 
> https://github.com/systemd/systemd/issues/2475
> https://github.com/systemd/systemd/issues/1741
> https://github.com/systemd/systemd/issues/1656
> 
> My attempt at a workaround is disabling systemd-fstab-generator per
> systemd.generator(7), and creating a `mount -a` service which mounts
> file systems at boot.
> 
> [Unit]
> Description=Mount local filesystems
> Documentation=man:mount(8) man:systemd.mount(5) man:bootup(7)
> DefaultDependencies=No
> After=local-fs-pre.target
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs
> 
> [Install]
> WantedBy=local-fs.target
> 
> However, according to the systemd.mount(5), .mount units will be
> generated either way. Oddly enough, when using the above service they
> don't seem to cause automatic mounts/unmounts.
> 

Because in this case you do not have static mount units, and for
transient mount units (created from external mount event) things were
partially fixed by not requiring existing device.

> How can this be the case? Is a better approach possible?
> 

Current approach is fundamentally incompatible with manual mounting. At
the very least, manual mount (outside systemd) must override any static
information systemd may have. I.e. if systemd has foo.mount for device
/dev/foo and sysadmin manually calls "mount /dev/bar /foo", systemd has
no business to interfere and unmount.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] mount units and automatic (un)mounts

2016-07-15 Thread Alad Wenter 
Hi,

When a device is mounted, a matching mount unit is created per
systemd.mount(5):

Mount points created at runtime (independently of unit files or
   /etc/fstab) will be monitored by systemd and appear like any other
   mount unit in systemd. See /proc/self/mountinfo description in
   proc(5).

If the device is removed while the mount is still active, systemd
unmounts the stale mount. However, if umount exits with a non-zero
status—for example, when the mount is still accessed and the drive
connection is flakey—the unit enters a failed state:

Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
process exited, code=exited status=32
Jul 12 17:00:34 thinkpad systemd[1]: Failed unmounting /mnt/toshiba-usb.
Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Unit is
bound to inactive unit dev-sdc1.device. Stopping, too.
Jul 12 17:00:34 thinkpad systemd[1]: Unmounting /mnt/toshiba-usb...
Jul 12 17:00:34 thinkpad umount[6341]: umount: /mnt/toshiba-usb: target
is busy
Jul 12 17:00:34 thinkpad umount[6341]: (In some cases useful
info about processes that
Jul 12 17:00:34 thinkpad umount[6341]:  use the device is found
by lsof(8) or fuser(1).)
Jul 12 17:00:34 thinkpad systemd[1]: mnt-toshiba\x2dusb.mount: Mount
process exited, code=exited status=32

On subsequent mounts, the device may be unmounted immediately unless
"systemctl reset-failed" is issued (note that appending the .mount unit
doesn't work in this case, giving a "Unit mnt-transcend\x2dsdhc.mount is
not loaded" error).

A few possibly related bug reports:

https://github.com/systemd/systemd/issues/2475
https://github.com/systemd/systemd/issues/1741
https://github.com/systemd/systemd/issues/1656

My attempt at a workaround is disabling systemd-fstab-generator per
systemd.generator(7), and creating a `mount -a` service which mounts
file systems at boot.

[Unit]
Description=Mount local filesystems
Documentation=man:mount(8) man:systemd.mount(5) man:bootup(7)
DefaultDependencies=No
After=local-fs-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount -a -t nocifs,nosmbfs,nonfs

[Install]
WantedBy=local-fs.target

However, according to the systemd.mount(5), .mount units will be
generated either way. Oddly enough, when using the above service they
don't seem to cause automatic mounts/unmounts.

How can this be the case? Is a better approach possible?

Regards,

Alad
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problems trying to convert a System-V-Init script to systemd

2016-07-15 Thread Andrei Borzenkov 
15.07.2016 13:28, Holger Kiehl пишет:
> I tried to avoid Type=forking and PIDFile= because I then have to maintain
> two different init versions, systemd and System-V-Init. I think there will
> always be other Unix systems around without systemd and I do not want to
> loose those users.
> 
> Would it help if I build into my script for each instant it starts
> it calls systemd-notify with --pid=? But if

systemd expects there is one PID that represents the service (Main PID).
If you have multiple equal instances, which one represents the service
then? Do not forget that if main PID terminates, systemd assumes service
has finished and cleans up. Of course you can cheat by preventing
killing remaining processes but then you also lose service babysitting
systemdm offers you.

> I understand you correctly this too would not help because of the 'su -'.
> Correct?
> 

That is what I expect based on your description. Did you check for extra
logind sessions as I suggested?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd IPMasquerade

2016-07-15 Thread Chris Trobridge 
I have managed to configure enough support in my kernel to enable me to use nft 
to establish IP Masquerading but systemd-networkd is still reporting "Could not 
enable IP masquerading: Operation not supported".
What kernel configuration is required for systemd to control IP masquerading?
I have the nftables userland tools installed but are there any other packages 
required by systemd?
Cheers,Chris
  ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problems trying to convert a System-V-Init script to systemd

2016-07-15 Thread Mantas Mikulėnas 
On Thu, Jul 14, 2016 at 3:34 PM, Holger Kiehl  wrote:

> Hello,
>
> I am new to systemd and the maintainer of the file distribution software
> AFD (http://www.dwd.de/AFD) and I am trying to adapt this application
> to systemd. The problem I am unable to solve is that doing a reboot,
> poweroff or halt, all process get a SIGTERM before systemd calls the
> command supplied by ExecStop. If I do a 'systemctl stop afd.service'
> everything works as expected. I have searched the web for a solution
> and have tried all the different service Type=, unit After=/Before=
> combination, but failed so far. I must be doing something obviously
> wrong, but unable to see what and need help please.
>
> The service/unit file looks as follows:
>
>[Unit]
>Description=Automatic File Distributor
>After=basic.target
>
>[Service]
>RemainAfterExit=yes
>Type=oneshot
>ExecStart=-/etc/init.d/afd start
>ExecStop=-/etc/init.d/afd stop
>KillMode=none
>StandardOutput=syslog+console
>StandardError=syslog+console
>
>[Install]
>WantedBy=multi-user.target
>
> /etc/init.d/afd is a shell script that starts one or more instances of
> the AFD under different users. The users are configured in
> /etc/sysconfig/afd
> and are started via the following command: su - $afduser -c " start/sop AFD>"
> To speed things up a bit the script forks for each user to start/stop the
> AFD instances. The script /etc/init.d/afd is just initiating thinks, but
> always waits for the command to complete. AFD itself has an init process
> (init_afd) that then starts several other process and monitors them.
>

It's possible that `su` moves its children to a different cgroup, making
them no longer technically part of the service, but rather part of a user
session.

Check whether `systemctl status afd` actually shows your sub-daemons while
they're running... (Other useful tools are `systemd-cgls` or `ps axfo
pid,user,unit,cmd`.) If that's the problem, try using `runuser -u $afduser
…` instead.

Better yet, forget init.d and create a native afd@.service, with one
instance per user (afd@user1, afd@user2, etc.), each instance running
*exactly one* daemon.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problems trying to convert a System-V-Init script to systemd

2016-07-15 Thread Holger Kiehl 


On Thu, 14 Jul 2016, Andrei Borzenkov wrote:

> 14.07.2016 15:34, Holger Kiehl пишет:
> > Hello,
> > 
> > I am new to systemd and the maintainer of the file distribution software
> > AFD (http://www.dwd.de/AFD) and I am trying to adapt this application
> > to systemd. The problem I am unable to solve is that doing a reboot,
> > poweroff or halt, all process get a SIGTERM before systemd calls the
> > command supplied by ExecStop. If I do a 'systemctl stop afd.service'
> > everything works as expected. I have searched the web for a solution
> > and have tried all the different service Type=, unit After=/Before=
> > combination, but failed so far. I must be doing something obviously
> > wrong, but unable to see what and need help please.
> > 
> > The service/unit file looks as follows:
> > 
> >[Unit]
> >Description=Automatic File Distributor
> >After=basic.target
> > 
> 
> This is redundant - it is default for any standard service
> 
> >[Service]
> >RemainAfterExit=yes
> >Type=oneshot
> 
> That's wrong (although it is unrelated to the problem you have). It
> means systemd expects ExecStart to run and finish. In your case it
> appears to work because you use RemainAfterExit, but if you look more
> closely, your service is in state where PID is exited.
> 
> >ExecStart=-/etc/init.d/afd start
> >ExecStop=-/etc/init.d/afd stop
> >KillMode=none
> 
> Well, in this case you rely on your service to behave well. You must be
> very confident :)
> 
> >StandardOutput=syslog+console
> >StandardError=syslog+console
> > 
> >[Install]
> >WantedBy=multi-user.target
> > 
> > /etc/init.d/afd is a shell script that starts one or more instances of
> 
> If you start multiple instances, you should consider service template so
> each instance can be represented as exactly one systemd service.
> 
> > the AFD under different users. The users are configured in 
> > /etc/sysconfig/afd
> > and are started via the following command: su - $afduser -c " > AFD>"
> 
> so what most likely happens, is - su establishes new login session; on
> shutdown these sessions are cleaned up (concurrently with any running
> service - unfortunately, there is no way to express dependency between
> user and system systemd instances). Here is where you get your signals.
> 
> Check with loginctl after service is started - do you see and extra seesion?
> 
> > To speed things up a bit the script forks for each user to start/stop the
> > AFD instances. The script /etc/init.d/afd is just initiating thinks, but
> > always waits for the command to complete. AFD itself has an init process
> > (init_afd) that then starts several other process and monitors them.
> > 
> > In /etc/init.d/afd I have added the following line in the beginning, before
> > it wants to do the shutdown:
> > 
> >echo "Before: ps -u afd: `ps -u $afduser`" >> /var/log/afd.log
> > 
> > And this then shows the following:
> > 
> >Before: ps -u afd:   PID TTY  TIME CMD
> > 1258 ?00:00:00 init_afd
> > 1260 ?00:00:00 system_log 
> > 1261 ?00:00:00 event_log 
> > 1262 ?00:00:00 receive_log 
> > 1263 ?00:00:00 transfer_log 
> > 1264 ?00:00:00 trans_db_log 
> > 1265 ?00:00:00 archive_watch 
> > 1266 ?00:00:00 input_log 
> > 1267 ?00:00:00 output_log 
> > 1268 ?00:00:00 delete_log 
> > 1269 ?00:00:00 production_log 
> > 1270 ?00:00:00 distribution_lo 
> > 1271 ?00:00:00 amg 
> > 1272 ?00:00:00 aldad 
> > 1287 ?00:00:00 afd_stat 
> > 1288 ?00:00:00 fd 
> > 1289 ?00:00:00 dir_check 
> > 
> > All the process have received a SIGTERM before (or during the execution)
> > of the script.
> > 
> > Any idea what I am doing wrong,
> 
> Much :)
> 
> > or what else I can try to do a proper
> > shutdown of this application under systemd?
> >
> 
> Use native systemd unit, do not use init scripts. Use User= to
> impersonate user, use Type=forking and PIDFile= to proper synchronize
> service startup, use templates to run multiple instances.
> 
First thank you very much for your very clear and good explaination.

I tried to avoid Type=forking and PIDFile= because I then have to maintain
two different init versions, systemd and System-V-Init. I think there will
always be other Unix systems around without systemd and I do not want to
loose those users.

Would it help if I build into my script for each instant it starts
it calls systemd-notify with --pid=? But if
I understand you correctly this too would not help because of the 'su -'.
Correct?

Regards,
Holger___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

2016-07-15 Thread Kai Krakow 
Am Sat, 18 Jun 2016 13:56:03 +0200
schrieb Paul Menzel :

> Dear systemd folks,
> 
> 
> the setup is as follows.
> 
> Nginx is used as the Web server, which communicates with a Ruby on
> Rails application over a socket. Puma [1] is used as the application
> server.
> 
> Nginx and Puma are managed by systemd service files.
> 
> If a new version of the application is installed, the goal is that
> there is no downtime. That means, until the application with the new
> code isn’t ready yet to serve requests, the old application still
> answers them, that means, not only are no requests lost, but during
> restart the visitor does not need to wait any longer than normally.
> 
> In this case, JRuby is used, which means that application start, `sudo
> systemctl start web-application.service` takes more than 30 seconds.
> 
> So, `sudo systemctl restart web-application.service` is not enough as
> Puma takes some time to be started. (The socket activation described
> in the Puma systemd documentation [2] only takes care, that no
> requests are lost. The visitor still has to wait.)
> 
> Is that possible by just using systemd, or is a load balancer like
> HAProxy or a special NGINX configuration and service file templates
> needed?
> 
> My current thinking would be, that a service file template for the
> Puma application server is used. The new code is then started in
> parallel, and if it’s done, it “takes over the socket”. (No idea if
> NGINX would need to be restarted.) Then the old version of the code
> is stopped. (I don’t know how to model that last step/dependency.)
> 
> What drawbacks does the above method have? Is it implementable?
> 
> How do you manage such a setup?

This is not really systemd specific. Systemd solves zero-downtime only
by socket-activation which is not exactly what you expect.

We are using mod_passenger with nginx to provider zero-downtime during
application deployment, background workers (job servers etc) are
managed by systemd and socket activation.

Passenger however does not support jruby afaik. But you may want to
look at how they implement zero downtime: Its kind of a proxy which is
switched to the new application instance as soon as it is up and
running. You could do something similar: Deploy to a new installation,
when ready, rewrite your nginx config to point to the new instance,
reload nginx, then gracefully stop the old instance. Its not that well
integrated as passenger does it but it can be optimized. However,
nothing of this is systemd specific except you still may want to use
socket activation in some places. Stopping and starting instances and
reloading nginx should be part of your deployment process. If controlled
with systemd, you can use service templates like
my-application@.service and then start
my-application@instance-201607150001.service and stop
my-application@instance-201607140003.service. You can use the instance
name to setup sockets, proxies etc.

-- 
Regards,
Kai

Replies to list-only preferred.


pgphNUoKsRqYy.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel