Comment # 32 on bug 968727 from patrick shanahan

(In reply to Franck Bui from comment #31)
> (In reply to patrick shanahan from comment #29)
> > runlevel 5, systemd-228-10.2, external usb sdb mounted at:
> >   /run/media/paka/TOSHIBA EXT
> >   /var/run/media/paka/TOSHIBA EXT
> > (Don't know why it mounts two places)
> 
> It's not mounted twice, /var/run is a symlink to /run.
> 
> > 
> > switch to runlevel 3
> > 
> > tty6 previously open is dropped, relogged on
> > /dev/sdb is no longer mounted
> > 
> 
> From your logs:
> 
> Mar 03 12:11:56 toshiba systemd[1]: multi-user.target: Trying to enqueue job
> multi-user.target/start/isolate
> Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Installed new job
> udisks2.service/stop as 19463
> Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Changed stop-sigterm ->
> dead
> Mar 03 12:11:56 toshiba systemd[1]: udisks2.service: Changed running ->
> stop-sigterm
> Mar 03 12:11:56 toshiba systemd[1]: Stopping Disk Manager...
> 
> as expected the service that mounted your USB disk was stopped because it's
> not part of the multi-user target.
> 
> So this seems to work as intended.

It may be "as intended", but mounts should not arbitrarily disappear.  A mount
is a mount and because "Device Notifier" or "Disk Manager" makes that mount is
irrelivant and should endure runlevel changes.  Expectation is the KEY here
rather than "as intended" related to *what* app performs the mount.  Dropping a
mount w/o notice and w/o <user> direction is just plain *wrong*.

> Are you sure that tty6 was open before switching from runlevel 5 to 3 ?

Yes, but ensuing tty's remained open so that may or may not have been related
to actions prior to systemd update.

> Still from the logs:
> 
> Mar 03 12:11:56 toshiba systemd[1]: autovt@tty6.service: Failed to load
> configuration: File exists
> Mar 03 12:11:56 toshiba systemd[1]: autovt@tty6.service: Trying to enqueue
> job autovt@tty6.service/start/fail


ps: I have installed systemd-228-10.2.x86_64 on three other boxes.  These "as
intended" changes certainly throw a spanner into the works for remote
administration, ie: implemented with very narrow sight.  Thankyou for your
consideration.