RepoMirrors/ceph
1
0
Fork 0
mirror of https://github.com/ceph/ceph synced 2025-01-03 01:22:53 +00:00
Code Issues Packages Projects Releases Wiki Activity
3b66712598
ceph/udev/95-ceph-osd.rules.systemd

33 lines
1.3 KiB
Plaintext
Raw Normal View History

systemd: activate disks via systemd service instead of udev The udev(7) man page states: RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. ceph-disk activate is far from a short-running task: - check whether path is a block dev, for dirs call through to activate_dir() - call blkid to obtain the filesystem type for the block dev - pull mount options from hard-coded ceph.conf file - mount the OSD dev at a temporary path - check the ceph magic for mounted filesystem - read cluster uuid and locate corresponding /etc/ceph/{cluster}.conf path - read or generate (if missing) the OSD uuid - create a file indicating init system usage (systemd) - mount the device at a second (final) location - umount (lazy) the temporary mount path - enable the systemd ceph-osd@{osd_id} service - start the systemd ceph-osd@{osd_id} service This logic is therefore best left in a systemd service for execution. As it is less limited in terms of execution time, and also allows for improved event handling in future (fsck, dmcrypt mapping etc.). This change sees 95-ceph-osd.rules.systemd trigger ceph-disk activate or ceph-disk activate-journal via new ceph-disk-activate-journal@.service, ceph-disk-activate@.service and ceph-disk-dmcrypt-activate@.service systemd service files. ceph-disk-dmcrypt-activate@.service makes use of the newly added --dmcrypt parameter for ceph-disk activate. Signed-off-by: David Disseldorp <ddiss@suse.de>
2015-05-11 23:45:34 +00:00
# activate ceph-tagged partitions
ACTION=="add", SUBSYSTEM=="block", \
ENV{DEVTYPE}=="partition", \
ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
Set Ceph device partitions owner to ceph user in udev. Signed-off-by: Milan Broz <mbroz@redhat.com>
2015-08-05 12:25:07 +00:00
OWNER:="ceph", GROUP:="ceph", MODE:="660", \
systemd: activate disks via systemd service instead of udev The udev(7) man page states: RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. ceph-disk activate is far from a short-running task: - check whether path is a block dev, for dirs call through to activate_dir() - call blkid to obtain the filesystem type for the block dev - pull mount options from hard-coded ceph.conf file - mount the OSD dev at a temporary path - check the ceph magic for mounted filesystem - read cluster uuid and locate corresponding /etc/ceph/{cluster}.conf path - read or generate (if missing) the OSD uuid - create a file indicating init system usage (systemd) - mount the device at a second (final) location - umount (lazy) the temporary mount path - enable the systemd ceph-osd@{osd_id} service - start the systemd ceph-osd@{osd_id} service This logic is therefore best left in a systemd service for execution. As it is less limited in terms of execution time, and also allows for improved event handling in future (fsck, dmcrypt mapping etc.). This change sees 95-ceph-osd.rules.systemd trigger ceph-disk activate or ceph-disk activate-journal via new ceph-disk-activate-journal@.service, ceph-disk-activate@.service and ceph-disk-dmcrypt-activate@.service systemd service files. ceph-disk-dmcrypt-activate@.service makes use of the newly added --dmcrypt parameter for ceph-disk activate. Signed-off-by: David Disseldorp <ddiss@suse.de>
2015-05-11 23:45:34 +00:00
TAG+="systemd", \
ENV{SYSTEMD_WANTS}+="ceph-disk-activate@/dev/$name.service"
# activate ceph-tagged partitions
ACTION=="add", SUBSYSTEM=="block", \
ENV{DEVTYPE}=="partition", \
ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
Set Ceph device partitions owner to ceph user in udev. Signed-off-by: Milan Broz <mbroz@redhat.com>
2015-08-05 12:25:07 +00:00
OWNER:="ceph", GROUP:="ceph", MODE:="660", \
systemd: activate disks via systemd service instead of udev The udev(7) man page states: RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. ceph-disk activate is far from a short-running task: - check whether path is a block dev, for dirs call through to activate_dir() - call blkid to obtain the filesystem type for the block dev - pull mount options from hard-coded ceph.conf file - mount the OSD dev at a temporary path - check the ceph magic for mounted filesystem - read cluster uuid and locate corresponding /etc/ceph/{cluster}.conf path - read or generate (if missing) the OSD uuid - create a file indicating init system usage (systemd) - mount the device at a second (final) location - umount (lazy) the temporary mount path - enable the systemd ceph-osd@{osd_id} service - start the systemd ceph-osd@{osd_id} service This logic is therefore best left in a systemd service for execution. As it is less limited in terms of execution time, and also allows for improved event handling in future (fsck, dmcrypt mapping etc.). This change sees 95-ceph-osd.rules.systemd trigger ceph-disk activate or ceph-disk activate-journal via new ceph-disk-activate-journal@.service, ceph-disk-activate@.service and ceph-disk-dmcrypt-activate@.service systemd service files. ceph-disk-dmcrypt-activate@.service makes use of the newly added --dmcrypt parameter for ceph-disk activate. Signed-off-by: David Disseldorp <ddiss@suse.de>
2015-05-11 23:45:34 +00:00
TAG+="systemd", \
ENV{SYSTEMD_WANTS}+="ceph-disk-activate-journal@/dev/$name.service"
# Map journal if using dm-crypt
ACTION=="add" SUBSYSTEM=="block", \
ENV{DEVTYPE}=="partition", \
ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-5ec00ceff106", \
Set Ceph device partitions owner to ceph user in udev. Signed-off-by: Milan Broz <mbroz@redhat.com>
2015-08-05 12:25:07 +00:00
OWNER:="ceph", GROUP:="ceph", MODE:="660", \
systemd: activate disks via systemd service instead of udev The udev(7) man page states: RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. ceph-disk activate is far from a short-running task: - check whether path is a block dev, for dirs call through to activate_dir() - call blkid to obtain the filesystem type for the block dev - pull mount options from hard-coded ceph.conf file - mount the OSD dev at a temporary path - check the ceph magic for mounted filesystem - read cluster uuid and locate corresponding /etc/ceph/{cluster}.conf path - read or generate (if missing) the OSD uuid - create a file indicating init system usage (systemd) - mount the device at a second (final) location - umount (lazy) the temporary mount path - enable the systemd ceph-osd@{osd_id} service - start the systemd ceph-osd@{osd_id} service This logic is therefore best left in a systemd service for execution. As it is less limited in terms of execution time, and also allows for improved event handling in future (fsck, dmcrypt mapping etc.). This change sees 95-ceph-osd.rules.systemd trigger ceph-disk activate or ceph-disk activate-journal via new ceph-disk-activate-journal@.service, ceph-disk-activate@.service and ceph-disk-dmcrypt-activate@.service systemd service files. ceph-disk-dmcrypt-activate@.service makes use of the newly added --dmcrypt parameter for ceph-disk activate. Signed-off-by: David Disseldorp <ddiss@suse.de>
2015-05-11 23:45:34 +00:00
RUN+="/sbin/cryptsetup --key-file /etc/ceph/dmcrypt-keys/$env{ID_PART_ENTRY_UUID} --key-size 256 create $env{ID_PART_ENTRY_UUID} /dev/$name"
# Map data device and
# activate ceph-tagged partitions
# for dm-crypted data devices
ACTION=="add" SUBSYSTEM=="block", \
ENV{DEVTYPE}=="partition", \
ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-5ec00ceff05d", \
Set Ceph device partitions owner to ceph user in udev. Signed-off-by: Milan Broz <mbroz@redhat.com>
2015-08-05 12:25:07 +00:00
OWNER:="ceph", GROUP:="ceph", MODE:="660", \
systemd: activate disks via systemd service instead of udev The udev(7) man page states: RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. ceph-disk activate is far from a short-running task: - check whether path is a block dev, for dirs call through to activate_dir() - call blkid to obtain the filesystem type for the block dev - pull mount options from hard-coded ceph.conf file - mount the OSD dev at a temporary path - check the ceph magic for mounted filesystem - read cluster uuid and locate corresponding /etc/ceph/{cluster}.conf path - read or generate (if missing) the OSD uuid - create a file indicating init system usage (systemd) - mount the device at a second (final) location - umount (lazy) the temporary mount path - enable the systemd ceph-osd@{osd_id} service - start the systemd ceph-osd@{osd_id} service This logic is therefore best left in a systemd service for execution. As it is less limited in terms of execution time, and also allows for improved event handling in future (fsck, dmcrypt mapping etc.). This change sees 95-ceph-osd.rules.systemd trigger ceph-disk activate or ceph-disk activate-journal via new ceph-disk-activate-journal@.service, ceph-disk-activate@.service and ceph-disk-dmcrypt-activate@.service systemd service files. ceph-disk-dmcrypt-activate@.service makes use of the newly added --dmcrypt parameter for ceph-disk activate. Signed-off-by: David Disseldorp <ddiss@suse.de>
2015-05-11 23:45:34 +00:00
TAG+="systemd", \
ENV{SYSTEMD_WANTS}+="ceph-disk-dmcrypt-activate@/dev/$name.service"
Reference in New Issue Copy Permalink