Re: [systemd-devel] Unit configuration for FUSE file system
Stef Bon writes: > That's why I advise to use a pidfile systemd can watch. I believe one of systemd's design goals is to actually get rid of pid files and related hacks. If I want to use systemd with a pidfile, I may just as well use systemd's sysvinit compatibility layer and stick with my traditional shell init script. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of ID_AUTOSEAT
On Tue, 24.04.12 15:23, shawn (shawnland...@gmail.com) wrote: > if you have a nested ID_AUTOSEAT tags does it ignore the child tags? or > do those get excluded from the parent and put in their own seat? > > Is there documentation for this I missed? What precisely do you mean by "nested" ID_AUTOSEAT tags? and what with "child" tags? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-namespace-* cleaning?
On Wed, 25.04.12 09:57, Tom Gundersen (t...@jklm.no) wrote: > > On Wed, Apr 25, 2012 at 9:34 AM, Colin Guthrie wrote: > > Is there any defined strategy for tidying up the > > /tmp/systemd-namespace-* folders (other than /tmp on tmpfs)? > > > > Nothing seems to be shipped by default in the tmpfiles.d stuff and it > > should really be on service stop that this is cleanup up anyway I believe. > > IIUC, currently a new namespace is set up before each Exec* and never > destroyed. > > I did some work (but did not finish testing it) on refactoring the > namespace stuff so that a namespace is set up before ExecStartPre, > then used by all the Exec*s of the service and finally destroyed after > ExecStopPost. I think this is the right way to go, but sadly have not > had time to finish it up. Yes, I am quite sure, too, that we should maintain the same namespace dir across the whole lifetime of the service. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-namespace-* cleaning?
On Wed, 25.04.12 09:34, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Hi, > > Is there any defined strategy for tidying up the > /tmp/systemd-namespace-* folders (other than /tmp on tmpfs)? > > Nothing seems to be shipped by default in the tmpfiles.d stuff and it > should really be on service stop that this is cleanup up anyway I believe. The subdirs are created by PrivateTmp=yes, and should be cleaned up by the same logic as /tmp itself. Unfortunately there was a bug where we never actually deleted subdirs from /tmp due to aging. This is fixed now in git (e5f3d1ba124f14477d6b5434982d7d44a472a66f). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cannot add dependency service to graphical.target
On Thu, 26.04.12 21:10, ZiQiang Huan (hzqh...@gmail.com) wrote: > hi, everyone, > I try to write a systemd service just like below: > [Unit] > Description=service for telnetd > Wants=syslog.target syslog.target is not really necessary anymore these days. > > [Service] > ExecStart=/usr/bin/busybox telnetd > Restart=always > RestartSec=10 > > [Install] > WantedBy=graphical.target > > but when I boot up, I got the error below: > systemd[1]: Cannot add dependency telnetd.servcie to graphical.target, > ignoring: Invalid argument This looks like a simple typo: "telnetd.servcie" is not a valid service name, and should probably be "telnetd.service". Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, 02.05.12 16:53, David Strauss (da...@davidstrauss.net) wrote: > > On Wed, May 2, 2012 at 3:58 PM, Lennart Poettering > wrote: > > But if you want that you can do that simply by enabling > > NetworkManager-wait-online.service, which then delays > > network.target accordingly. > > That would work, but it has potential undesirable effects: > > * Any services associated with network.target will wait longer to > start, even if all they need to do is bind to *:80. This reduces > parallelism. They shouldn't wait for network.target then. > * If NetworkManager-wait-online.service causes network.target to only > fire once all interfaces are up, a service like openssh-server might > not start if only one of the interfaces comes up. This occasionally > happens on multihomed systems where only the public or private > interface comes up. It would be annoying to not have SSH access in > such a situation. Same here, SSH should not be delayed after network.target. > * It's not clear when or how network.target gets "stopped." If > network.target stops on loss of any interface, existing services might > flap unnecessarily. It would be bad to have MySQL, for example, stop > or restart because a switch restarted. If network.target never gets > stopped or only gets stopped on total network shutdown (no 127.0.0.1), > it would not solve Sebastian's use case. His use case requires > stopping certain network-dependent services when links go down. network.target isn't really something that should be removed. I mean, you can spend a lot of braincells on defining precise semantics for network.target, but in the end I think it's all pointless, since we know that different apps understand different things under "network is around", and in a dynamic and multi-homed network such a definition is broken anyway... Hence: network.target should only be used for software which is incapable of listening to netlink, or using IP_FREEBIND. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, May 2, 2012 at 3:58 PM, Lennart Poettering wrote: > But if you want that you can do that simply by enabling > NetworkManager-wait-online.service, which then delays > network.target accordingly. That would work, but it has potential undesirable effects: * Any services associated with network.target will wait longer to start, even if all they need to do is bind to *:80. This reduces parallelism. * If NetworkManager-wait-online.service causes network.target to only fire once all interfaces are up, a service like openssh-server might not start if only one of the interfaces comes up. This occasionally happens on multihomed systems where only the public or private interface comes up. It would be annoying to not have SSH access in such a situation. * It's not clear when or how network.target gets "stopped." If network.target stops on loss of any interface, existing services might flap unnecessarily. It would be bad to have MySQL, for example, stop or restart because a switch restarted. If network.target never gets stopped or only gets stopped on total network shutdown (no 127.0.0.1), it would not solve Sebastian's use case. His use case requires stopping certain network-dependent services when links go down. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, May 2, 2012 at 3:40 PM, David Strauss wrote: > I would consider adding a script that fires > network-fully-up.target once NetworkManager finishes This actually appears to be a better example, especially for how you'd adapt the script to handle a connection going down: http://blog.abdullahsolutions.com/2009/03/starting-script-after-networkmanager.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, 02.05.12 15:40, David Strauss (da...@davidstrauss.net) wrote: > > On Wed, May 2, 2012 at 1:19 PM, Sebastian Tramp > wrote: > > Are there existing service files which solve a similar or the same issue? > > You may want a target [1]. There is already a network target, but I > believe it comes up before NetworkManager fully initializes all > interfaces. Well, by default we don't delay boot until NM signals that some network devices have been configured. But if you want that you can do that simply by enabling NetworkManager-wait-online.service, which then delays network.target accordingly. > I would consider adding a script that fires > network-fully-up.target once NetworkManager finishes [2]. This would > allow any service to install as "WantedBy" that target. network.target should be sufficient for that. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, May 2, 2012 at 1:19 PM, Sebastian Tramp wrote: > Are there existing service files which solve a similar or the same issue? You may want a target [1]. There is already a network target, but I believe it comes up before NetworkManager fully initializes all interfaces. I would consider adding a script that fires network-fully-up.target once NetworkManager finishes [2]. This would allow any service to install as "WantedBy" that target. It's probably also possible to stop the network-fully-up.target on disconnection. If services indicating WantedBy=network-fully-up.target also have StopWhenUnneeded enabled, they will shut down on stopping that target. Altogether, this should do what you need as well as provide a general facility on your systems for any unit to start and stop based on network availability. Note: For a target like network-fully-up, it would be bad to try and use systemctl isolate in the same way as for the runlevels. [1] http://0pointer.de/public/systemd-man/systemd.target.html [2] http://drewdahl.com/2011/05/03/using-networkmanager-to-run-scripts-after-connecting/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network consuming user services
On Wed, 02.05.12 22:19, Sebastian Tramp (m...@sebastian.tramp.name) wrote: > Hi, > > I want to start some user services which need a working network connection. > This includes services as > > * "fetchmail --idle" to receive mails > * ssh tunnel with autossh > * dyndns update > > I recently switched to systemd 44 on arch linux but after one day of try and > error as well as manpage reading I am not sure that this is in the scope of > systemd. > > The best solution could be to hear on dbus, if the NetworkManager sends an > "online event". The services need to be finished if the network is down and > started again if we are online again. > > Are there existing service files which solve a similar or the same > issue? Ideally services like yours would just listen to netlink events so that they can properly handle connectivity coming and going. In today's dynamic world having daemons that fail if the network isn't up is backwards, in particular since the definition of "network is up" is hard on machines with multiple network interfaces, or machines connected indirectly to the internet. i.e. link beat or pingability might matter more. In summary: we think the only correct way to handle network connectivity is to make the daemons watch netlink. To provide compatibility with services that currently not do it we provide the generic "network.target" which can be used as synchronization point for all services that only care for "network is up", for whatever definition this might be. Depending on the specific installation this can then be filled with different definitions. One option for example is to enable the "NetworkManager-wait-online.service", which hooks into NM and waits until a network configuration is applied and is subject to a timeout. Just run "systemctl enable NetworkManager-wait-online.service" and it will order itself before network.target, thus exposing the desired behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] network consuming user services
Hi, I want to start some user services which need a working network connection. This includes services as * "fetchmail --idle" to receive mails * ssh tunnel with autossh * dyndns update I recently switched to systemd 44 on arch linux but after one day of try and error as well as manpage reading I am not sure that this is in the scope of systemd. The best solution could be to hear on dbus, if the NetworkManager sends an "online event". The services need to be finished if the network is down and started again if we are online again. Are there existing service files which solve a similar or the same issue? Thanks a lot and best regards Sebastian Tramp -- WebID: http://sebastian.tramp.name pgppF0B1jWWwu.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for FUSE file system
2012/5/2 Nikolaus Rath : > On 05/02/2012 03:53 PM, Lennart Poettering wrote: >> On Sat, 28.04.12 20:41, Nikolaus Rath (nikol...@rath.org) wrote: >> automatically, without any manual kludges. We won't support any other >> hacks in systemd. Sorry. > > > Ah, ok. Mounting with /bin/mount -t works just fine, so I > should be good on that side. What I'm worried about is unmounting. The > file system can be unmounted with "umount /mntpoint", but when this > command returns, the mount helper that was started by /bin/mount is > still running and doing important things. Will systemd notice this and > act accordingly (e.g., wait for this process to terminate before > stopping the network)? > Hi, because your fs is not terminated (as I understand it) when umounted (as I read it some caching) the umount action is not the thing systemd should react on. That's why I advise to use a pidfile systemd can watch. When ready, remove the pidfile. I do not know this is possible in the systemd mount context, but as far as I know with the service files. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for FUSE file system
On 05/02/2012 03:53 PM, Lennart Poettering wrote: > On Sat, 28.04.12 20:41, Nikolaus Rath (nikol...@rath.org) wrote: > >> Hello, >> >> I am struggling to come up with the correct way to define a unit >> configuration for a FUSE based network file system. >> >> Generally, the file system needs to be mounted and unmounted with its >> own programs (rather than with mount and umount). The main reason for >> the custom umount command, however, is that it uses some /proc based >> hacks to block until the mount process has actually exited (this may >> take quite some time even after the mountpoint has been freed, because >> cached data is may still be transferred over the network). >> >> Things I am confused about: >> >> Is there a way to express this in a .mount unit, or do I need to declare >> this as a more general .service? >> >> Is the custom umount command still necessary, or can I use the standard >> umount() and rely on systemd to wait until the mount process has truly >> finished before considering the service stopped? >> >> When using a .service file instead, is there some way to still tell >> systemd that this service mounts a specific path? > > The official API to mount file systems of any kind on Linux is > /bin/mount. Only that makes sure we don't have to add additional hooks > to various components of our stack to support specific file system > types. It also makes sure that fstab works for this service the way it > should. /bin/mount is capable of invoking helper tools for specific file > systems, via a hook tool /sbin/mount.. > > Please make sure that your FUSE file system implements this mount > extension protocol correctly. If it does, systemd will support it > automatically, without any manual kludges. We won't support any other > hacks in systemd. Sorry. Ah, ok. Mounting with /bin/mount -t works just fine, so I should be good on that side. What I'm worried about is unmounting. The file system can be unmounted with "umount /mntpoint", but when this command returns, the mount helper that was started by /bin/mount is still running and doing important things. Will systemd notice this and act accordingly (e.g., wait for this process to terminate before stopping the network)? Thanks, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for FUSE file system
On Sat, 28.04.12 20:41, Nikolaus Rath (nikol...@rath.org) wrote: > Hello, > > I am struggling to come up with the correct way to define a unit > configuration for a FUSE based network file system. > > Generally, the file system needs to be mounted and unmounted with its > own programs (rather than with mount and umount). The main reason for > the custom umount command, however, is that it uses some /proc based > hacks to block until the mount process has actually exited (this may > take quite some time even after the mountpoint has been freed, because > cached data is may still be transferred over the network). > > Things I am confused about: > > Is there a way to express this in a .mount unit, or do I need to declare > this as a more general .service? > > Is the custom umount command still necessary, or can I use the standard > umount() and rely on systemd to wait until the mount process has truly > finished before considering the service stopped? > > When using a .service file instead, is there some way to still tell > systemd that this service mounts a specific path? The official API to mount file systems of any kind on Linux is /bin/mount. Only that makes sure we don't have to add additional hooks to various components of our stack to support specific file system types. It also makes sure that fstab works for this service the way it should. /bin/mount is capable of invoking helper tools for specific file systems, via a hook tool /sbin/mount.. Please make sure that your FUSE file system implements this mount extension protocol correctly. If it does, systemd will support it automatically, without any manual kludges. We won't support any other hacks in systemd. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for FUSE file system
On Wed, May 2, 2012 at 1:25 AM, Stef Bon wrote: > 2012/4/29 Nikolaus Rath : > > Hello, > > > > I am struggling to come up with the correct way to define a unit > > configuration for a FUSE based network file system. > > > > Generally, the file system needs to be mounted and unmounted with its > > own programs (rather than with mount and umount). The main reason for > > the custom umount command, however, is that it uses some /proc based > > hacks to block until the mount process has actually exited (this may > > take quite some time even after the mountpoint has been freed, because > > cached data is may still be transferred over the network). > > > > Things I am confused about: > > > > Is there a way to express this in a .mount unit, or do I need to declare > > this as a more general .service? > > Hi, > > the way I see it is that FUSE filesystems are not just like any other > mount, more a program which happens to be a filesystem. > > So I think it's the best choice to handle it like a "normal" program, > and make use of a pidfile, which systemd can watch (or make use of a > dbus service, but that's probably not the case). > > I'm going to leave it in the middle as to what the best method is, but, with little trouble I made a fuse mount unit myself, and it seems to work correctly. It needs 2 parts: - the mount unit. This looks exactly like every other mount unit, except, the filetype is now something special. In my case, I have "Type=fuse.libsqlfs" - a /sbin/mount.fuse.libsqlfs wrapper script or executable. mount itself doesn't know any filesystems, but it calls helpers for the unknown ones. The helper for libsqlfs merely exec's libsqlfs_mount (the daemon providing the fuse fs) with the right parameters, and in my case, I threw a modprobe fuse in there as well. unmounting seems to work fine. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About autofs: no handling of expire??
2012/5/2 Lennart Poettering : >> (autofs_ptype_expire_direct). Is this on purpose? >> I see a timeout set, so I guess it was the intention to handle the >> expire. > > We currently don't do expiration, since this wasn't intended as a full > autofs implementation, but just a way to parallelize and delay load > things at boot. > > That said, we could support expire easily I guess, and so I have now > added this to the TODO list. Well you do not have to. I'm just asking. >> It works, so here probably happens something strange: while using the >> field packet.hdr, actually the field packet.v5_packet.hdr is used. Is >> this correct? > > In Autofs5 all packets have the same format which exposes > pid. i.e. autofs_packet_xxx_yyy_t are all typedef'ed to the same packet > struct. Hence accessing this this way is safe. Well yes every autofs packet starts with a header. If it's a autofsv5 pakket, it also starts with a header. Probably because it's the first struct in the union AND the first field part of autofs_v5_packet, it works. I'm just checking the code and see I understand it to write my own autofs implementation using FUSE. The FUSE fs will somehow be what now is the "browseable" map with indirect maps with the automounter, and somehow I have to find a way to make a specific directory a direct autofs mountpoint. Thanks, Stef Bon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About autofs: no handling of expire??
On Wed, 02.05.12 07:45, Stef Bon (stef...@gmail.com) wrote:
> Hi,
>
> I've been looking into the code how systemd handles the automounting.
Heya,
> I've got two issues:
>
> a. I've found the handling of the "missing" packet
> (autofs_ptype_missing_direct), which triggers the
> mounting. But I did not found the handling of the expire packet
> (autofs_ptype_expire_direct). Is this on purpose?
> I see a timeout set, so I guess it was the intention to handle the
> expire.
We currently don't do expiration, since this wasn't intended as a full
autofs implementation, but just a way to parallelize and delay load
things at boot.
That said, we could support expire easily I guess, and so I have now
added this to the TODO list.
> b. the packet read from the pipe is of type union
> autofs_v5_packet_union which looks like:
>
> union autofs_v5_packet_union {
> struct autofs_packet_hdr hdr;
> struct autofs_v5_packet v5_packet;
> autofs_packet_missing_indirect_t missing_indirect;
> autofs_packet_expire_indirect_t expire_indirect;
> autofs_packet_missing_direct_t missing_direct;
> autofs_packet_expire_direct_t expire_direct;
> };
>
> where autofs_v5_packet is:
>
> struct autofs_v5_packet {
> struct autofs_packet_hdr hdr;
> autofs_wqt_t wait_queue_token;
> __u32 dev;
> __u64 ino;
> __u32 uid;
> __u32 gid;
> __u32 pid;
> __u32 tgid;
> __u32 len;
> char name[NAME_MAX+1];
> };
>
> now in the code of automount_fd_event, the selection is based upon
> packet.hdr.type, and futher the fields
> packet.v5_packet.pid are used. Now this while packet is an union: it's
> used as hdr OR as autofs_v5_packet, not both at the same time.
> It works, so here probably happens something strange: while using the
> field packet.hdr, actually the field packet.v5_packet.hdr is used. Is
> this correct?
In Autofs5 all packets have the same format which exposes
pid. i.e. autofs_packet_xxx_yyy_t are all typedef'ed to the same packet
struct. Hence accessing this this way is safe.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for FUSE file system
2012/4/29 Nikolaus Rath : > Hello, > > I am struggling to come up with the correct way to define a unit > configuration for a FUSE based network file system. > > Generally, the file system needs to be mounted and unmounted with its > own programs (rather than with mount and umount). The main reason for > the custom umount command, however, is that it uses some /proc based > hacks to block until the mount process has actually exited (this may > take quite some time even after the mountpoint has been freed, because > cached data is may still be transferred over the network). > > Things I am confused about: > > Is there a way to express this in a .mount unit, or do I need to declare > this as a more general .service? Hi, the way I see it is that FUSE filesystems are not just like any other mount, more a program which happens to be a filesystem. So I think it's the best choice to handle it like a "normal" program, and make use of a pidfile, which systemd can watch (or make use of a dbus service, but that's probably not the case). Your program should remove the pid file when finished, and should react on signal (this is configurable) to finish, and should take of unmounting itself. Bottom line is that systemd does not take care of the (u)mounting, but stopping and starting of the program. The FUSE fs should take care of the (u)mounting. This means probably a wrapper. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
