Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Andrei Borzenkov]

24.01.2018 22:54, Lennart Poettering пишет:
> On Mi, 24.01.18 22:12, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> 24.01.2018 22:08, Lennart Poettering пишет:
>>> On Mi, 24.01.18 22:01, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>>> 1;5002;0c
 24.01.2018 17:13, Lennart Poettering пишет:
> On Mi, 24.01.18 14:51, Thomas Blume (thomas.bl...@suse.com) wrote:
>
>> Would this be an acceptable approach?
>
> Since a long time there has been a proper API for this: just take a
> BSD file lock on the device node and udev won't bother with the
> device anymore. As soon as you close the device fully (and thus also
> lost all locks), udev will notice and then reprobe it again.
>

 How exactly is udev relevant here? This discussion has nothing to do
 with udev.
>>>
>>> systemd acts on udev's notifications. Other daemons do too. If you
>>> don't want that all those apps and services act on it for your block
>>> device, then the right approach is to block udev from doing so,
>>> i.e. go to the source, not to the symptom.
>>
>> You cannot lock device that does not exist. And as soon as it appears it
>> is mounted.
> 
> hu? Thomas' proposed approach of "systemctl lock $DEVICE" also requires there
> to be a known path for a device, hence it must already be plugged in
> already?
> 
> Also, it's not that systemd takes possession of arbitrary devices just
> like that. It does that because the device was listed explicitly in
> /etc/fstab as "auto" already, and your system wouldn't even have booted if
> the device didn't show up during boot. 
> 

a) If device has "nofail" systemd *will* boot without this device.
b) User is free to unmount and unplug this device even if it was present
in /etc/fstab. And when device is plugged again user may want to change
its content - repartition, reformat, whatever.

> I think you have a different usecase though? Not sure I grok it
> though? you want to turn off all hotplug handling for all future
> devices entirely? what's the usecase?
> 
> Lennart
> 

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

Re: [systemd-devel] Multiple services using the same core service?

[林自均]

Hi Lennart,

Thank you, I will reconsider this design.

John Lin

Lennart Poettering  於 2018年1月24日 週三 19:41 寫道：

> On Di, 26.12.17 01:39, 林自均 (johnl...@gmail.com) wrote:
>
> > Hi folks,
> >
> > I am trying to achieve:
> >
> > # systemctl start sshd-shell.service (1)
> > # systemctl start sshd-sftp.service (2)
> > # systemctl stop sshd-shell.service (3)
> > # systemctl stop sshd-sftp.service (4)
> >
> > Before the command (1), sshd is not running. By typing (1),
> > /etc/sshd_config is configured to accept ssh shell connections but no
> sftp
> > connections, and then start sshd. By typing (2), /etc/sshd_config is
> > configured to accept sftp connections too, and sshd is reloaded. By
> typing
> > (3), /etc/sshd_config is configured to refuse ssh shell connection, and
> > sshd is reloaded again. By typing (4), sshd will be stopped.
>
> Quite frankly, this is not really in line with how systemd services
> are supposed to be used. They are supposed to wrap running processes,
> but not wrap configuration applied to others really.
>
> But anyway, of course, it's up to you how to make use of this stuff...
>
> > The current problem is that I don't know if there is a better way to
> > achieve this. For example, I have to sleep 1 second before reloading
> > sshd-core.service in sshd-shell.service because otherwise sshd didn't
> setup
> > the signal handler for SIGHUP and will terminate itself. Or systemd
> doesn't
> > suggest such use case?
>
> Yes, it's not really in-line with how this stuff was designed...
>
> That said, I am pretty sure there's something wrong with your
> sshd-core.service: the unit should not be considered up before the
> daemon process is fully running, and that includes having set up
> SIGHUP handlers properly.
>
> Most likely the Type= stuff is not set up correctly in that unit (or
> sshd is broken and doesn't set things up fully before reporting its
> startup being complete).
>
> 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] Behavior of BindsTo when stopping a service

[Andrei Borzenkov]

26.01.2018 05:11, Amit Saha пишет:
> Hello,
> 
> I have a systemd service - drainconnections which I want to to make sure
> finishes stopping before systemd starts stopping another service. What I
> also want is to if I stop supervisord service, drainconnections should be
> stopped first.
> 
> It seems like BindsTo is what I need for establishing the coupling between
> the two units.

If your description of services relationship is accurate and complete,
BindsTo is too strong here; you really need just PartsOf.

> The following unit file describes drainconnections:
> 
> 
> [Unit]
> Description=Drain Connections
> After=supervisord.service
> BindsTo=supervisord.service
> 
> [Service]
> Type=oneshot
> RemainAfterExit=True
> ExecStart=/bin/true

I think recent sytsemd relaxes requirement, so you can omit ExecStart here.

> ExecStop=/usr/bin/touch /var/shuttingdown1
> ExecStop=/usr/bin/sleep 60
> ExecStop=/usr/bin/touch /var/shuttingdown2
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> In addition, I also needed to add BindsTo=drainconnections to the
> supervisord service.
> 

This will create dependency loop with your unit definition shown above.

> Things work as desired for me considering the above configuration.
> 
> Am I on the right track here? Thanks in advance.
> 
> Best Wishes,
> Amit.
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

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

Re: [systemd-devel] automount fails with generic "resources" error

[Olaf Hering]

On Tue, Jan 23, Lennart Poettering wrote:

> On Mo, 15.01.18 15:13, Olaf Hering (o...@aepfle.de) wrote:
> 
> > 'journalctl -b' does not indicate any related failure.
> > 
> > Does anyone happen to know what limits a mount point or an automount
> > point might have? These systems have plenty of cpus, have plenty of
> > memory, likely enough to handle these few fstab entries during bootup.
> > 
> > Is there a way to boot with debug enabled, but not spam the serial
> > console with lots of noise while the issue does not happen?
> 
> "resources" is a bit misleading... It's our catch-all result code if
> some kernel API returned an error we didn't expect. Most likely
> (hopefully?) there's more info about what operation failed in the
> logs. Do you see anything there? If you can reproduce it, can you turn
> on "systemd-analyze set-log-level debug" before it maybe to get more
> detailed output?

There was nothing obvious in the logs, but debug was not enabled AFAIK.

But it turned out the mount point did not exist in this case. Once
created, all "automount" entries in fstab worked fine.

I have seen this generic error on a few more systems. I will enable
debug once I get the chance to work on these systems.


Olaf


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

Re: [systemd-devel] Behavior of BindsTo when stopping a service

[Amit Saha]

On Sun, 28 Jan 2018 at 6:22 am, Andrei Borzenkov 
wrote:

> 26.01.2018 05:11, Amit Saha пишет:
> > Hello,
> >
> > I have a systemd service - drainconnections which I want to to make sure
> > finishes stopping before systemd starts stopping another service. What I
> > also want is to if I stop supervisord service, drainconnections should be
> > stopped first.
> >
> > It seems like BindsTo is what I need for establishing the coupling
> between
> > the two units.
>
> If your description of services relationship is accurate and complete,
> BindsTo is too strong here; you really need just PartsOf.


Thanks. PartOf looks like something more suitable. Would having PartOf in
supervisord obey the before after relationship setup by drainconnections
service?

I will give it a shot.

>
>
> > The following unit file describes drainconnections:
> >
> >
> > [Unit]
> > Description=Drain Connections
> > After=supervisord.service
> > BindsTo=supervisord.service
> >
> > [Service]
> > Type=oneshot
> > RemainAfterExit=True
> > ExecStart=/bin/true
>
> I think recent sytsemd relaxes requirement, so you can omit ExecStart here.


Thanks.

>
>
> > ExecStop=/usr/bin/touch /var/shuttingdown1
> > ExecStop=/usr/bin/sleep 60
> > ExecStop=/usr/bin/touch /var/shuttingdown2
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> >
> > In addition, I also needed to add BindsTo=drainconnections to the
> > supervisord service.
> >
>
> This will create dependency loop with your unit definition shown above.


Wouldn’t the Before/After take care of breaking the dependency loop? That
seems to be what I observed.



>
> > Things work as desired for me considering the above configuration.
> >
> > Am I on the right track here? Thanks in advance.
> >
> > Best Wishes,
> > Amit.
> >
> >
> >
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Behavior of BindsTo when stopping a service

[Andrei Borzenkov]

28.01.2018 02:11, Amit Saha пишет:
> On Sun, 28 Jan 2018 at 6:22 am, Andrei Borzenkov 
> wrote:
> 
>> 26.01.2018 05:11, Amit Saha пишет:
>>> Hello,
>>>
>>> I have a systemd service - drainconnections which I want to to make sure
>>> finishes stopping before systemd starts stopping another service. What I
>>> also want is to if I stop supervisord service, drainconnections should be
>>> stopped first.
>>>
>>> It seems like BindsTo is what I need for establishing the coupling
>> between
>>> the two units.
>>
>> If your description of services relationship is accurate and complete,
>> BindsTo is too strong here; you really need just PartsOf.
> 
> 
> Thanks. PartOf looks like something more suitable. Would having PartOf in
> supervisord obey the before after relationship setup by drainconnections
> service?
> 

PartsOf (like BindsTo) is orthogonal to After/Before. PartsOf/BindsTo
define what to do, After/Before define when to do.

> I will give it a shot.
> 
>>
>>
>>> The following unit file describes drainconnections:
>>>
>>>
>>> [Unit]
>>> Description=Drain Connections
>>> After=supervisord.service
>>> BindsTo=supervisord.service
>>>
...
>>>
>>> In addition, I also needed to add BindsTo=drainconnections to the
>>> supervisord service.
>>>
>>
>> This will create dependency loop with your unit definition shown above.
> 
> 
> Wouldn’t the Before/After take care of breaking the dependency loop? That
> seems to be what I observed.
> 

Probably I had to elaborate. If you need full BindsTo semantic (which is
superset of Requires) it only works as documented if you also have
corresponding After/Before which creates loop. Otherwise Requires part
is mostly useless. If you are only interested in propagating stop
request and "stopping on surprise removal" part of BindsTo then this is
probably OK, but this will make your units definitions rather confusing.

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