(In reply to patrick shanahan from comment #0)
> changing runlevel from 3 to 5 or 5 to 3 drops mounts which are not in fstab.
> 

How exactly were the mounts created initially ?

Did you create mount unit files or did you simply use the mount command ?

(In reply to Franck Bui from comment #1)
> (In reply to patrick shanahan from comment #0)
> > changing runlevel from 3 to 5 or 5 to 3 drops mounts which are not in fstab.
> > 
> 
> How exactly were the mounts created initially ?
> 
> Did you create mount unit files or did you simply use the mount command ?

plug drive in graphical target and tell device notifier to mount

have not tried using manual mount

(In reply to patrick shanahan from comment #2)
> 
> plug drive in graphical target and tell device notifier to mount
> 
> have not tried using manual mount

Which desktop environment are you using (KDE, LXDC, ...) ?

Are you sure the mounts get dropped when switching from runlevel 3 to 5 ?

Just tested this with systemd 228 + fix for bug#966535 together with a nfs mount share. AFAICS from changing runlevels the mount point isn't dropped.

(In reply to Dr. Werner Fink from comment #4)
> Just tested this with systemd 228 + fix for bug#966535 together with a nfs
> mount share. AFAICS from changing runlevels the mount point isn't dropped.

yes I did the same test and came to the same conclusion.

I suspect a component part of Patrick's DE which deals with plugged/unplugged devices which gets killed (when the DE service is stopped) when switching from 5 -> 3.

And I guess, the behaviour would be expected in this case.

(In reply to Franck Bui from comment #5)

This could be, yes.

@ Patrick -- more informations is required on your report.

Please can you provide some more informations about your moount points and the devices used for those.  What type of devices do you use and are those devices part of a special target?

(In reply to Franck Bui from comment #5)
> (In reply to Dr. Werner Fink from comment #4)
> > Just tested this with systemd 228 + fix for bug#966535 together with a nfs
> > mount share. AFAICS from changing runlevels the mount point isn't dropped.
> 
> yes I did the same test and came to the same conclusion.
> 
> I suspect a component part of Patrick's DE which deals with
> plugged/unplugged devices which gets killed (when the DE service is stopped)
> when switching from 5 -> 3.
> 
> And I guess, the behaviour would be expected in this case.

That is not what happened previous.  The mounts were *not* disconnected.

(In reply to patrick shanahan from comment #7)

Does this mena that the fixed version 228 not only fix bug #966535 but also this one?

(In reply to Dr. Werner Fink from comment #6)
> (In reply to Franck Bui from comment #5)
> 
> This could be, yes.
> 
> @ Patrick -- more informations is required on your report.
> 
> Please can you provide some more informations about your moount points and
> the devices used for those.  What type of devices do you use and are those
> devices part of a special target?

runlevel 5
plug in external usb drive
mount using device notifier

change to runlevel 3
mount is not there

/run/media/<user>/<drive-mount-point>


manually mount /mnt/<drive-mount-point>
change to runlevel 5
mount is not there

external usb3 drive
I see this on two boxes, only ones tested

(In reply to Dr. Werner Fink from comment #8)
> (In reply to patrick shanahan from comment #7)
> 
> Does this mena that the fixed version 228 not only fix bug #966535 but also
> this one?

no, only reference.  condition was discussed there iirc

(In reply to Franck Bui from comment #5)
> (In reply to Dr. Werner Fink from comment #4)
> > Just tested this with systemd 228 + fix for bug#966535 together with a nfs
> > mount share. AFAICS from changing runlevels the mount point isn't dropped.
> 
> yes I did the same test and came to the same conclusion.
> 
> I suspect a component part of Patrick's DE which deals with
> plugged/unplugged devices which gets killed (when the DE service is stopped)
> when switching from 5 -> 3.
> 
> And I guess, the behaviour would be expected in this case.

I don't see nfs connection affected here either and didn't report such or didn't intend it to be intrepreted that way.  

local mounts of physical external drives not present if fstab

Please provide some more informations, with

 systemctl list-units | grep \\.mount

your get all mounts ... now with

 systemctl list-dependencies <your_usb_mount_here>
 systemctl show <your_usb_mount_here>

we should see more

Created attachment 667308 [details]
systemctl list-units | grep \\.mount

Created attachment 667309 [details]
systemctl list-dependencies <your_usb_mount_here>

Created attachment 667310 [details]
systemctl show <your_usb_mount_here>

(In reply to patrick shanahan from comment #9)
> (In reply to Dr. Werner Fink from comment #6)
> > (In reply to Franck Bui from comment #5)
> > 
> > This could be, yes.
> > 
> > @ Patrick -- more informations is required on your report.
> > 
> > Please can you provide some more informations about your moount points and
> > the devices used for those.  What type of devices do you use and are those
> > devices part of a special target?
> 
> runlevel 5
> plug in external usb drive
> mount using device notifier

Could you tell us more about the last step ?

Do you know which exact compement is doing the mount ?

Again tell us which DE you're using.


> 
> change to runlevel 3
> mount is not there
> 
> /run/media/<user>/<drive-mount-point>
> 
> 
> manually mount /mnt/<drive-mount-point>
> change to runlevel 5
> mount is not there

This case is strange because mount units are not stopped when isolating a target...

Perhaps the mount point has been moved to /run/media/<user>/<drive-mount-point> ?

(In reply to Franck Bui from comment #16)
> (In reply to patrick shanahan from comment #9)
> > (In reply to Dr. Werner Fink from comment #6)
> > > (In reply to Franck Bui from comment #5)
> > > 
> > > This could be, yes.
> > > 
> > > @ Patrick -- more informations is required on your report.
> > > 
> > > Please can you provide some more informations about your moount points and
> > > the devices used for those.  What type of devices do you use and are those
> > > devices part of a special target?
> > 
> > runlevel 5
> > plug in external usb drive
> > mount using device notifier
> 
> Could you tell us more about the last step ?

"device notifier" is applet on task bar
 
> Do you know which exact compement is doing the mount ?

no

> Again tell us which DE you're using.

plasma5

> 
> > 
> > change to runlevel 3
> > mount is not there
> > 
> > /run/media/<user>/<drive-mount-point>
> > 
> > 
> > manually mount /mnt/<drive-mount-point>
> > change to runlevel 5
> > mount is not there
> 
> This case is strange because mount units are not stopped when isolating a
> target...
> 
> Perhaps the mount point has been moved to
> /run/media/<user>/<drive-mount-point> ?

that is the normal mount point when device notifier is utilized.  grepping for the device, "mount |grep sdb2" provides no output at *any* mount point.

Would be interesting to have a look in the log output of your plasma desktop.
You might run something like

   ps ux

to get the the process table of your session.  The interesting part here is the pid of the starting session script.  With this it should be possible to see what files descriptor for standard error is used:

  ls -l /proc/<your_pid_here>/fd/2

this should be the file where the messages are stored.

(In reply to Dr. Werner Fink from comment #18)
> Would be interesting to have a look in the log output of your plasma desktop.
> You might run something like
> 
>    ps ux
> 
> to get the the process table of your session.  The interesting part here is
> the pid of the starting session script.  With this it should be possible to
> see what files descriptor for standard error is used:

ok, "what" identifies the process table of my session
  ps ux | grep ...... 
or ???
 
>   ls -l /proc/<your_pid_here>/fd/2
> 
> this should be the file where the messages are stored.

remember, I was old before SuSE was born :)

(In reply to patrick shanahan from comment #19)

For plasma I guess something like

  /usr/bin/startplasmacompositor
  /usr/bin/kwin_wayland

also any process started by those processes may have stderr
on this file I guess.

(In reply to Dr. Werner Fink from comment #20)
> (In reply to patrick shanahan from comment #19)
> 
> For plasma I guess something like
> 
>   /usr/bin/startplasmacompositor
>   /usr/bin/kwin_wayland
> 
> also any process started by those processes may have stderr
> on this file I guess.

I see no processes re: plasmacompositor or wayland

I have compositor off, I don't use "effects" :)

(In reply to patrick shanahan from comment #21)

open a konsole, run

  px | grep konsole

(In reply to Dr. Werner Fink from comment #22)
> (In reply to patrick shanahan from comment #21)
> 
> open a konsole, run
> 
>   px | grep konsole

pid 8556

ls -l /proc/8556/fd/2

l-wx------ 1 paka users 64 Mar  1 09:49 /proc/8556/fd/2 -> /home/paka/.xsession-errors-:0

Ahh ... that is simple (AFAIK the lxsession redirects this error messages elsewhere).

OK  then watch in one konsole the file with

   tail -f /home/paka/.xsession-errors-:0

and in an other do your test, that is changing the runlevel during an by the desktop automounted USB device.

(In reply to Dr. Werner Fink from comment #24)
> Ahh ... that is simple (AFAIK the lxsession redirects this error messages
> elsewhere).
> 
> OK  then watch in one konsole the file with
> 
>    tail -f /home/paka/.xsession-errors-:0
> 
> and in an other do your test, that is changing the runlevel during an by the
> desktop automounted USB device.

full .xsession-errors-:0 here:
  http://wahoo.no-ip.org/~paka/.xsession-errors-:0

cannot do tail ....  as systemd closes tty's when changing to runlevel 3 and to 5 and cannot maintain remote connection as systemd drops network connection when changing runlevels 5->3->5.....

another suggestion??

(In reply to patrick shanahan from comment #25)
> full .xsession-errors-:0 here:
>  http://wahoo.no-ip.org/~paka/.xsession-errors-:0

> cannot do tail ....  as systemd closes tty's when changing to runlevel 3 and 
> to 5 and cannot maintain remote connection as systemd drops network connection 
> when changing runlevels 5->3->5.....
> 
> another suggestion??

How this?  AFAICS from my tests the fixed 228 does *not* close the tty's

(In reply to Dr. Werner Fink from comment #26)
> (In reply to patrick shanahan from comment #25)
> > full .xsession-errors-:0 here:
> >  http://wahoo.no-ip.org/~paka/.xsession-errors-:0
> 
> > cannot do tail ....  as systemd closes tty's when changing to runlevel 3 and 
> > to 5 and cannot maintain remote connection as systemd drops network connection 
> > when changing runlevels 5->3->5.....
> > 
> > another suggestion??
> 
> How this?  AFAICS from my tests the fixed 228 does *not* close the tty's

then it hasn't been published:
 systemd-228-2.1.x86_64
closes tty's on all five of my local boxes.

(In reply to patrick shanahan from comment #27)
> (In reply to Dr. Werner Fink from comment #26)
> > (In reply to patrick shanahan from comment #25)
> > How this?  AFAICS from my tests the fixed 228 does *not* close the tty's
> 
> then it hasn't been published:
>  systemd-228-2.1.x86_64
> closes tty's on all five of my local boxes.

Well it's going to take some time before the fix reaches Tumbleweed...

So now I'm not sure which version of systemd you were using from the beginning of your testing.

This repo should contain the fixes:

http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/

Can you redo your test with systemd updated from it ?

Specially the test which consists of mounting your USB drive from runlevel3 and do the switch to runlevel5. According to one of your previous comment your drive isn't mounted anymore.

Before doing this test, change the log level of systemd to "debug" with:
$ systemd-analyze set-log-level debug

then after your test restore the previous log level to the default "info" and the the content of the journal.

Thanks.

(In reply to Franck Bui from comment #28)
> (In reply to patrick shanahan from comment #27)
> > (In reply to Dr. Werner Fink from comment #26)
> > > (In reply to patrick shanahan from comment #25)
> > > How this?  AFAICS from my tests the fixed 228 does *not* close the tty's
> > 
> > then it hasn't been published:
> >  systemd-228-2.1.x86_64
> > closes tty's on all five of my local boxes.
> 
> Well it's going to take some time before the fix reaches Tumbleweed...
> 
> So now I'm not sure which version of systemd you were using from the
> beginning of your testing.

systemd-228-2.1.x86_64

> This repo should contain the fixes:
> 
> http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/
> 
> Can you redo your test with systemd updated from it ?

yes
 
> Specially the test which consists of mounting your USB drive from runlevel3
> and do the switch to runlevel5. According to one of your previous comment
> your drive isn't mounted anymore.
> 
> Before doing this test, change the log level of systemd to "debug" with:
> $ systemd-analyze set-log-level debug
> 
> then after your test restore the previous log level to the default "info"
> and the the content of the journal.

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)

switch to runlevel 3

tty6 previously open is dropped, relogged on
/dev/sdb is no longer mounted

mounted /dev/sdb to /mnt/external/

systemctl isolate graphical.target

tty6 remained open
mount /mnt/external persisted

systemctl isolate multi-user
tty6 remained open
mount /mnt/external persisted

systemctl isolate graphical
umount /mnt/external
used "Device Notifier" applet to mount /dev/sdb2
mounted to 2 locations:
  /run/media/paka/TO..
  /var/run/media/paka/TO..

systemctl isolate multi-user
tty6 remained open
/dev/sdb2 is no longer mounted

journalctl --since "2016-03-03 12:00" > journal.logs.txt 
  http://wahoo.no-ip.org/~paka/journal.logs.txt

additional note:  I did *not* drop internet connections whiching runlevels with systemd-228-10.2

tks

(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.

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

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

(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.

(In reply to patrick shanahan from comment #32)
> 
> 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*.
> 

My point is that systemd stops the Disk Manager service because it's not part of the multi-user.target. And this part works as intended.

The fact that the Disk Manager chooses to umount disks it has mounted previously because it's going to be stopped is up to this service not to systemd.

The fact that the Disk Manager is not part of the multi-user target is also up to the service.

So I'm going to edit the subject to reflect this and we should probably reassign this 'issue' to the udisk2 maintainer.

Hi Alexei, would you please help to have a look at this issue? I assign it to you because you are helping to maintain the package of udisks2 recently, but please feel free to reassign whenever necessary, thank you!