Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-08 Thread Christian Rohmann 

Hey Mantas,

On 08/07/2021 10:39, Mantas Mikulėnas wrote:


I am then just wondering why the issue referred to
(https://github.com/systemd/systemd/issues/1741
) is still open?
Are there still further plans to make systemd properly recognize
that the inactive unit (pointing to a mount point that is used in
a new and active unit) actually is superseeded and unmounting it
makes now sense as that hits the new, working, active mount.


I *think* this was supposed to improve with v249:

https://github.com/systemd/systemd/pull/19322 

https://github.com/systemd/systemd/issues/19983 



nice, thanks a bunch for the pointers!




In any case I'd suggest then is to somehow give a warning to the
user as with changes to the systemd units:
  "Warning: myfancyservice.service changed on disk. Run 'systemctl
daemon-reload' to reload units."


systemd can't make non-systemd tools (such as `mount`) display warnings.


yeah, that's certainly true and it's much better to not need any 
warnings anyways .




Regards


Christian

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

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-08 Thread Mantas Mikulėnas 
On Thu, Jul 8, 2021 at 10:12 AM Christian Rohmann <
christian.rohm...@frittentheke.de> wrote:

> Hey Silvio,
> On 07/07/2021 20:04, Silvio Knizek wrote:
>
> after touching /etc/fstab you're supposed to run `systemctl daemon-
> reload` to re-trigger the generators. This is in fact a feature to
> announce changes in configuration files to systemd. See
> man:systemd.generator for more information.
>
> Thanks for the quick reply and the kind hint to the (right) documentation.
>
>
> I am then just wondering why the issue referred to (
> https://github.com/systemd/systemd/issues/1741) is still open?
> Are there still further plans to make systemd properly recognize that the
> inactive unit (pointing to a mount point that is used in a new and active
> unit) actually is superseeded and unmounting it makes now sense as that
> hits the new, working, active mount.
>

I *think* this was supposed to improve with v249:

https://github.com/systemd/systemd/pull/19322
https://github.com/systemd/systemd/issues/19983

In any case I'd suggest then is to somehow give a warning to the user as
> with changes to the systemd units:
>   "Warning: myfancyservice.service changed on disk. Run 'systemctl
> daemon-reload' to reload units."
>

systemd can't make non-systemd tools (such as `mount`) display warnings.

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

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-08 Thread Christian Rohmann 

Hey Silvio,

On 07/07/2021 20:04, Silvio Knizek wrote:

after touching /etc/fstab you're supposed to run `systemctl daemon-
reload` to re-trigger the generators. This is in fact a feature to
announce changes in configuration files to systemd. See
man:systemd.generator for more information.


Thanks for the quick reply and the kind hint to the (right) documentation.


I am then just wondering why the issue referred to 
(https://github.com/systemd/systemd/issues/1741) is still open?
Are there still further plans to make systemd properly recognize that 
the inactive unit (pointing to a mount point that is used in a new and 
active unit) actually is superseeded and unmounting it makes now sense 
as that hits the new, working, active mount.



In any case I'd suggest then is to somehow give a warning to the user as 
with changes to the systemd units:
  "Warning: myfancyservice.service changed on disk. Run 'systemctl 
daemon-reload' to reload units."


Otherwise the "reaction" of an unmount to a just successfully happend 
mount is still quite surprising to a user.




Regards


Christian

||

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

Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-07 Thread Silvio Knizek 
Am Mittwoch, dem 07.07.2021 um 15:21 +0200 schrieb Christian Rohmann:
> Hello systemd-devel,
>
>
> we recently replaced a broken drive on a server and ran into a strange
> issue in regards to a mount 
>
>
>
> 1) It started with the old device not being reachable anymore and
> therefore the crypt setup and mount was just failing:
>
> --- cut ---
> [...]
>
> Jul  2 03:41:11 myserver systemd[1]:
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device:
> Job
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start
> timed out.
> Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device.
> Jul  2 03:41:11 myserver systemd[1]: Dependency failed for Cryptography
> Setup for ee386599-8235-4d4d-9d3e-901ccf2eed4b_crypt.
> Jul  2 03:41:11 myserver systemd[1]:
> systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service:
> Job
> systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service/start
> failed with result 'dependency'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device:
> Job
> dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start
> failed with result 'timeout'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device:
> Job
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start
> timed out.
> Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device.
> Jul  2 03:41:11 myserver systemd[1]: Dependency failed for
> /var/lib/ceph/osd/ceph-64.
> Jul  2 03:41:11 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount:
> Job var-lib-ceph-osd-ceph\x2d64.mount/start failed with result 'dependency'.
> Jul  2 03:41:11 myserver systemd[1]:
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device:
> Job
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start
> failed with result 'timeout'.
>
> [...]
> --- cut ---
>
>
> 2) We then replaced the drive, created a new Luks device and created a
> new XFS filesystem on top of it.
>
>
> 3) We then updated the fstab to point to the new device name (ceph-$UUID
> of the new luks device) and triggered am immediate "mount" via Ansible
> The fstab entry now looks like this:
>
> --- cut ---
> /dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> /var/lib/ceph/osd/ceph-64 xfs nofail 0 0
>
> --- cut ---
>
>
> and the systemd auto-generated mount unit like so:
>
> --- cut ---
>
> # /run/systemd/generator/var-lib-ceph-osd-ceph\x2d64.mount
> # Automatically generated by systemd-fstab-generator
>
> [Unit]
> SourcePath=/etc/fstab
> Documentation=man:fstab(5) man:systemd-fstab-generator(8)
>
> [Mount]
> Where=/var/lib/ceph/osd/ceph-64
> What=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> Type=xfs
> Options=nofail
> --- cut ---
>
>
> What happend was, that the mount succeeded initially, but then systemd
> unmounted the path right away,
> apparently because the old (auto-generated) mount unit was still
> present, in "inactive" state:
>
> --- cut ---
>
> Jul  2 13:17:04 myserver ansible-mount: Invoked with
> src=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
> path=/var/lib/ceph/osd/ceph-64 fstype=xfs state=mounted opts=nofail
> boot=True backup=False dump=None fstab=None passno=None
> Jul  2 13:17:04 myserver kernel: [367734.361658] XFS (dm-25): Mounting
> V5 Filesystem
> Jul  2 13:17:04 myserver kernel: [367734.373636] XFS (dm-25): Ending
> clean mount
> Jul  2 13:17:04 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount:
> Unit is bound to inactive unit
> dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device.
> Stopping, too.
> Jul  2 13:17:04 myserver systemd[1]: Unmounting /var/lib/ceph/osd/ceph-64...
> Jul  2 13:17:05 myserver systemd[1]: Unmounted /var/lib/ceph/osd/ceph-64.
> Jul  2 13:17:05 myserver kernel: [367734.413530] XFS (dm-25): Unmounting
> Filesystem
>
> --- cut ---
>
>
>
> I did find the issue https://github.com/systemd/systemd/issues/1741
> which sounds quite similar, but that is closed for comments unfortunately.
> There a supposed "workaround" apparently is to call "systemd
> daemon-reload" prior to mounting? Is this the proper way to update the
> auto-generated mount-units then?
>
> Or did we handle this whole process of replacing a device and then
> having a new one mounted at the same mount point wrong in any way?
> As explained, we were not handling any systemd mount units directly, but
> only modified the fstab.
>
>
>
> Thanks and with kind Regards
>
>
> Christian
Hi Christian,

after touching /etc/fstab you're supposed to run `systemctl daemon-
reload` to re-trigger the generators. This is in fact a feature to
announce changes in configuration files to

[systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-07 Thread Christian Rohmann 

Hello systemd-devel,


we recently replaced a broken drive on a server and ran into a strange 
issue in regards to a mount 




1) It started with the old device not being reachable anymore and 
therefore the crypt setup and mount was just failing:


--- cut ---
[...]

Jul  2 03:41:11 myserver systemd[1]: 
dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device: 
Job 
dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start 
timed out.
Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device.
Jul  2 03:41:11 myserver systemd[1]: Dependency failed for Cryptography 
Setup for ee386599-8235-4d4d-9d3e-901ccf2eed4b_crypt.
Jul  2 03:41:11 myserver systemd[1]: 
systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service: 
Job 
systemd-cryptsetup@ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b_crypt.service/start 
failed with result 'dependency'.
Jul  2 03:41:11 myserver systemd[1]: 
dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device: 
Job 
dev-disk-by\x2duuid-ee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b.device/start 
failed with result 'timeout'.
Jul  2 03:41:11 myserver systemd[1]: 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device: 
Job 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start 
timed out.
Jul  2 03:41:11 myserver systemd[1]: Timed out waiting for device 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device.
Jul  2 03:41:11 myserver systemd[1]: Dependency failed for 
/var/lib/ceph/osd/ceph-64.
Jul  2 03:41:11 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount: 
Job var-lib-ceph-osd-ceph\x2d64.mount/start failed with result 'dependency'.
Jul  2 03:41:11 myserver systemd[1]: 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device: 
Job 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device/start 
failed with result 'timeout'.


[...]
--- cut ---


2) We then replaced the drive, created a new Luks device and created a 
new XFS filesystem on top of it.



3) We then updated the fstab to point to the new device name (ceph-$UUID 
of the new luks device) and triggered am immediate "mount" via Ansible

The fstab entry now looks like this:

--- cut ---
/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data 
/var/lib/ceph/osd/ceph-64 xfs nofail 0 0


--- cut ---


and the systemd auto-generated mount unit like so:

--- cut ---

# /run/systemd/generator/var-lib-ceph-osd-ceph\x2d64.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)

[Mount]
Where=/var/lib/ceph/osd/ceph-64
What=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data
Type=xfs
Options=nofail
--- cut ---


What happend was, that the mount succeeded initially, but then systemd 
unmounted the path right away,
apparently because the old (auto-generated) mount unit was still 
present, in "inactive" state:


--- cut ---

Jul  2 13:17:04 myserver ansible-mount: Invoked with 
src=/dev/ceph-8ce1a4e6-94dd-4fa8-a7b9-310ab211b54a/data 
path=/var/lib/ceph/osd/ceph-64 fstype=xfs state=mounted opts=nofail 
boot=True backup=False dump=None fstab=None passno=None
Jul  2 13:17:04 myserver kernel: [367734.361658] XFS (dm-25): Mounting 
V5 Filesystem
Jul  2 13:17:04 myserver kernel: [367734.373636] XFS (dm-25): Ending 
clean mount
Jul  2 13:17:04 myserver systemd[1]: var-lib-ceph-osd-ceph\x2d64.mount: 
Unit is bound to inactive unit 
dev-ceph\x2dee386599\x2d8235\x2d4d4d\x2d9d3e\x2d901ccf2eed4b-data.device. 
Stopping, too.

Jul  2 13:17:04 myserver systemd[1]: Unmounting /var/lib/ceph/osd/ceph-64...
Jul  2 13:17:05 myserver systemd[1]: Unmounted /var/lib/ceph/osd/ceph-64.
Jul  2 13:17:05 myserver kernel: [367734.413530] XFS (dm-25): Unmounting 
Filesystem


--- cut ---



I did find the issue https://github.com/systemd/systemd/issues/1741 
which sounds quite similar, but that is closed for comments unfortunately.
There a supposed "workaround" apparently is to call "systemd 
daemon-reload" prior to mounting? Is this the proper way to update the 
auto-generated mount-units then?


Or did we handle this whole process of replacing a device and then 
having a new one mounted at the same mount point wrong in any way?
As explained, we were not handling any systemd mount units directly, but 
only modified the fstab.




Thanks and with kind Regards


Christian

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