let's say Fedora and Ubuntu?
… both of which are nowadays systemd operating systems.
What happens in systemd operating systems
the native mechanism
Systemd employs various kinds of units. .mount unit files instruct it to mount volumes. .swap unit files instruct it to tell the kernel about swap partitions. (.service unit files instruct it how to run services. And so on.) These are the native systemd mechanisms. To enact them, systemd itself forks off child processes that make the relevant system calls.
If you use the systemctl command (with --all) on such a systemd operating system, it will tell you about the loaded .swap units. For example:
dev-disk-by\x2dpartuuid-40549710\x2d05.swap loaded active active /dev/disk/by-partuuid/40549710-05
dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap loaded active active /dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
dev-sda5.swap loaded active active /dev/sda5
It will also tell you about the .mount units.
A system administrator can actually write such .swap unit files by hand, just as xe can write .service, .socket, and other unit files by hand. systemd itself just looks for unit files in the filesystem. They are its native mechanism.
One can even get systemd to show you what is in these unit files and where in the filesystem they can be found:
$ systemctl cat dev-disk-by\\x2duuid-1bb589e8\\x2d929f\\x2d4041\\x2d81f4\\x2dff2b339b4e2a.swap
# /run/systemd/generator/dev-disk-by\x2duuid-1bb589e8\x2d929f\x2d4041\x2d81f4\x2dff2b339b4e2a.swap
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
[Swap]
What=/dev/disk/by-uuid/1bb589e8-929f-4041-81f4-ff2b339b4e2a
Options=sw
$
automatically generated unit files
One can write them by hand. Usually however such .mount and .swap unit files are automatically generated by programs known as generators. Two such generators are systemd-fstab-generator and systemd-gpt-auto-generator. They both run early in the bootstrap process and in response to a systemctl daemon-reload command, and (as you can see above) they generate a whole load of unit files into an undocumented subdirectory in /run/systemd/. systemd itself just uses those generated unit files.
The former generator reads /etc/fstab, recognizing several systemd extensions to that file format. As I pointed out in an answer comment, traditionally swap partitions have the mount type of sw and that is how one will find that other operating systems recognise swap records in this table. But Linux softwares have taken the alternative tack of recognizing the VFS type instead, looking for swap as the VFS type. systemd-fstab-generator is no exception here, and that is how it interprets /etc/fstab when converting it into the native mechanisms.
The latter generator processes the EFI partition table that is on the same disc that holds the EFI System Partition, looking for EFI partition table entries that have various well-known partition type GUIDs. One of those GUIDs is the conventional GUID assigned to Linux swap partitions; and if systemd-gpt-auto-generator finds a partition with that GUID (that satisfies the criteria given in the systemd doco) it will make a .swap unit for it; no /etc/fstab involved at all.
Of course, this process has lots of side-effects. For example, because /etc/fstab has no primary key to the table, records can have duplicate "spec" and "file" (i.e. "what" and "where") fields. In the native systemd mechanism, though, the "file" (i.e. "where") field is a unique key for .mount units, embedded into the unit names. No two .mount units can share it. For .swap units the "spec" (i.e. "what") field is the unique key for units. No two .swap units can share that. So not all records in /etc/fstab are necessarily convertible to the native mechanisms and will work, especially if people do things like list the same mount point for two different purposes or list the same swap partition in two different ways.
Similarly, because it has translated /etc/fstab into the native mechanism and systemd's native mechanism has other ways of activating units, the behaviour is subtly different to that of non-systemd operating systems. A .mount unit will, by default, be automatically activated by systemd-udevd, even after bootstrap, in response to the appearance of the mounted storage device. Or it can be listed as a Wants= or Requires= of some .service or .socket unit, meaning that it will be (re-)activated when they are. There is even RequiresMountsFor=.
installer programs and the systemd way
Traditionally, operating system installer programs, and the systemd administrator afterwards reconfiguring the system, have written sw entries to /etc/fstab. And that is how the native .mount and .swap units end up being auto-generated. The install/configuration utility "knows" where the swap file was put, because in its user interface the system administrator made some sort of choice, and writes an /etc/fstab to match. Sometimes that choice is I need you to make me a swap partition as part of installation.; sometimes it is Just use the swap partition that you have found already on the disc. (installers looking at the partition types, too).
But the systemd people have this idea of operating systems that auto configure themselves from a largely empty /etc tree, so-called stateless systems, and that is what mechanisms like the generator that reads the EFI partition table are all about. In the systemd people's plan, there is no /etc/fstab, and indeed is no persistent configuration data under /etc at all, and all of this stuff is deduced from the contents of the partition table on disc, at every bootstrap and at every systemctl daemon-reload. They are nowadays promoting operating system installer programs than do not write an /etc/fstab.
In the traditional scheme, of course you can indeed have each operating system have its own private swap partition, and not have them touch one another's swap partitions. And indeed if you are using hibernate to disc via a swap partition and expecting to be able to multi-boot to another operating system whilst hibernated (which is a very bad idea because it is very easy to cause filesystem corruption this way) that will be necessary.
In the systemd scheme, even if the operating system is not yet as the systemd people envisage it and "stateless", the aforementioned generators run; and thus all swap partitions (on the ESP/root disc) with the requisite partition type are automatically employed by all systemd operating systems. Since they will be sharing all automatically discovered swap partitions, one really does not need to create one swap partition per installed operating system.
Further reading
