[systemd-devel] [PATCH manpages] umount.2: revise MNT_FORCE description.

[NeilBrown]

MNT_FORCE does not allow a busy filesystem to be unmounted.  Only
MNT_DETACH allows that.
MNT_FORCE only tries to abort pending transactions, in the hope that
might help umount not to block,

Also, other filesystems than NFS support MNT_FORCE.

Signed-off-by: NeilBrown 
---

Explanation derived from examination of source code.
Cc to systemd devel in relation to comment I just posted:

https://github.com/systemd/systemd/commit/0c08f5cde749bd2818475e487109cd0d413452df

You may want to move the "linux version when support was added" to a
comment, or discard it.

 man2/umount.2 | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/man2/umount.2 b/man2/umount.2
index 68f76b7c6352..ccd1d07afe88 100644
--- a/man2/umount.2
+++ b/man2/umount.2
@@ -61,9 +61,17 @@ unmounts a target, but allows additional
 controlling the behavior of the operation:
 .TP
 .BR MNT_FORCE " (since Linux 2.1.116)"
-Force unmount even if busy.
-This can cause data loss.
-(Only for NFS mounts.)
+Ask the filesystem to abort pending requests before attempting the
+unmount.  This may allow the unmount to complete without waiting
+for an inaccessible server.  If, after aborting requests, some
+processes still have active references to the filesystem, the
+unmount will still fail. In Linux 4.12, only the filesystems
+9p (2.6.16),
+ceph (2.6.34),
+cifs (2.6.12),
+fuse (2.6.16),
+lustre (3.11),
+and NFS (2.1.116) respond to MNT_FORCE.
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
 Perform a lazy unmount: make the mount point unavailable for new
-- 
2.14.0.rc0.dirty



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

Re: [systemd-devel] question about system reboot and shutdown

[Marek Floriańczyk]

Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> 08.08.2017 17:03, Marek Floriańczyk пишет:
> > What would be the proper way to distinguish between system is going down
> > for reboot and for shutdown ?
> 
> Straightforward way is to make your service WantedBy poweroff.target and
> halt.target. You can then have second service WantedBy reboot.target and
> kexec.target. They may even call the same binary (script) but with
> different arguments.

Thanks for answer,

So, my binary "microupsd" is started  by /etc/init.d/microups at the boot time 
to monitor power input, battery status etc.
During system halt I need to send SIGUSR1 to this "microupsd" process at which 
it will send command to microups device, moreover  I would like to give it 
some time (like 1-2 seconds) to accomplish the transmission.
I don't need to send anything in case of reboot.

Should I prepare some script that sends SIGUSR1 to "microupsd" process and 
then sleeps for 2 seconds and set it as WantedBy poweroff.target and 
halt.target ?

How can I be sure that this script will be called before "microupsd" is 
actually killed during system shutdown ?

Best Regards
Marek

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

[systemd-devel] question about system reboot and shutdown

[Marek Floriańczyk]

Hi all,

I have a small device MicroUPS which helps me to shutdown my system on 
embedded devices, it is controlled by script /etc/init.d/microups and in this 
script I need to know whether system is going down for reboot or for halt, 
because in case of halt I need to send small data over RS232 to MicroUPS 
device to cut the power off.

In previous version of init system I checked $runlevel variable but now I'm 
doing some "grep" commands according to this post

https://stackoverflow.com/questions/25166085/how-can-a-systemd-controlled-service-distinguish-between-shutdown-and-reboot

and sometimes my method doesn't work. Either in  /usr/bin/systemctl list-jobs 
there is sometimes reboot and shutdown process present, or my microupsd 
process gets killed before it sends data to the MicroUPS device over Rs232.

What would be the proper way to distinguish between system is going down for 
reboot and for shutdown ?

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

[systemd-devel] timesyncd equivalent to ntp-wait

[Shawn Johnson]

I need to be able to start a service only after time synchronization has
occurred.  I implemented this as a systemd target with ntpd and ntp-wait
but I can't find an equivalent for timesyncd. I found a couple references
to this problem but didn't find them helpful:

* [Patch from 2014]
https://lists.freedesktop.org/archives/systemd-devel/2014-November/025131.html
* [Github Bug 5097] https://github.com/systemd/systemd/issues/5097

Worst case I guess I could grep the output of timedatectl for "NTP
synchronized" but since that tool knows the state of synchronization It
would seem this information must be available in a more programmatic way.
Any help would be greatly appreciated. Also, if a solution is found how can
I submit changes to the documentation? The systemd-timesyncd.service man
page is pretty weak.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question about system reboot and shutdown

[Andrei Borzenkov]

08.08.2017 17:03, Marek Floriańczyk пишет:
> 
> What would be the proper way to distinguish between system is going down for 
> reboot and for shutdown ?
> 

Straightforward way is to make your service WantedBy poweroff.target and
halt.target. You can then have second service WantedBy reboot.target and
kexec.target. They may even call the same binary (script) but with
different arguments.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question about system reboot and shutdown

[Marek Floriańczyk]

Dnia wtorek, 8 sierpnia 2017 19:35:12 CEST Mantas Mikulėnas pisze:
> I suggest first porting microupsd itself to a native systemd .service file
> (so that it'll have process monitoring and everything). That might even fix
> part of the problem.

Hi

I have no problem with changing some code in microupsd so it behave in certain 
way. It is handling SIGTERM and other signals if needed.
The problem for me is that SIGTERM is send to process during system reboot and 
system halt - so I need to differentiate between the two.

If you can suggest me  a way, maybe with some example I will change my code.

Best Regards
Marek

> 
> Normally services are given a certain amount of time to stop after SIGTERM
> (or whatever KillSignal was set, or whatever ExecStop command was
> specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call
> a bug), it's possible to add some... arbitrary delays.
> 
> Units are stopped due to having automatic Conflicts=shutdown.target, if I
> remember correctly. I'm not sure if disabling that default dependency is a
> good approach though...
> 
> This time I can't think of a good combination that'd solve both problems
> without introducing some ugly race conditions...
> 
> On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk 
> 
> wrote:
> > Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> > > 08.08.2017 17:03, Marek Floriańczyk пишет:
> > > > What would be the proper way to distinguish between system is going
> > 
> > down
> > 
> > > > for reboot and for shutdown ?
> > > 
> > > Straightforward way is to make your service WantedBy poweroff.target and
> > > halt.target. You can then have second service WantedBy reboot.target and
> > > kexec.target. They may even call the same binary (script) but with
> > > different arguments.
> > 
> > Thanks for answer,
> > 
> > So, my binary "microupsd" is started  by /etc/init.d/microups at the boot
> > time
> > to monitor power input, battery status etc.
> > During system halt I need to send SIGUSR1 to this "microupsd" process at
> > which
> > it will send command to microups device, moreover  I would like to give it
> > some time (like 1-2 seconds) to accomplish the transmission.
> > I don't need to send anything in case of reboot.
> > 
> > Should I prepare some script that sends SIGUSR1 to "microupsd" process and
> > then sleeps for 2 seconds and set it as WantedBy poweroff.target and
> > halt.target ?
> > 
> > How can I be sure that this script will be called before "microupsd" is
> > actually killed during system shutdown ?
> > 
> > Best Regards
> > Marek
> > 
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

Re: [systemd-devel] question about system reboot and shutdown

[Mantas Mikulėnas]

I suggest first porting microupsd itself to a native systemd .service file
(so that it'll have process monitoring and everything). That might even fix
part of the problem.

Normally services are given a certain amount of time to stop after SIGTERM
(or whatever KillSignal was set, or whatever ExecStop command was
specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call
a bug), it's possible to add some... arbitrary delays.

Units are stopped due to having automatic Conflicts=shutdown.target, if I
remember correctly. I'm not sure if disabling that default dependency is a
good approach though...

This time I can't think of a good combination that'd solve both problems
without introducing some ugly race conditions...

On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk 
wrote:

> Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> > 08.08.2017 17:03, Marek Floriańczyk пишет:
> > > What would be the proper way to distinguish between system is going
> down
> > > for reboot and for shutdown ?
> >
> > Straightforward way is to make your service WantedBy poweroff.target and
> > halt.target. You can then have second service WantedBy reboot.target and
> > kexec.target. They may even call the same binary (script) but with
> > different arguments.
>
> Thanks for answer,
>
> So, my binary "microupsd" is started  by /etc/init.d/microups at the boot
> time
> to monitor power input, battery status etc.
> During system halt I need to send SIGUSR1 to this "microupsd" process at
> which
> it will send command to microups device, moreover  I would like to give it
> some time (like 1-2 seconds) to accomplish the transmission.
> I don't need to send anything in case of reboot.
>
> Should I prepare some script that sends SIGUSR1 to "microupsd" process and
> then sleeps for 2 seconds and set it as WantedBy poweroff.target and
> halt.target ?
>
> How can I be sure that this script will be called before "microupsd" is
> actually killed during system shutdown ?
>
> Best Regards
> Marek
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

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