Re: [systemd-devel] ssh socket activation (Was: systemd unit files for Debian based systems)
On Wed, 20.06.12 10:17, Mathieu Bridon (boche...@fedoraproject.org) wrote: On Tue, 2012-06-19 at 19:15 +0200, Lennart Poettering wrote: On Tue, 19.06.12 18:50, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, On Tue, Jun 19, 2012 at 10:03:23AM +0200, Lennart Poettering wrote: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Do you know of a service file for openssh-server? The Fedora packages have some, but I don't like them too much since they don't use socket activation... Is someone actually working on real socket activation for openssh? While the inetd like stuff works, it does not perform well. it doesn't? In which way? It should be totally OK? When we worked on porting the package to systemd units, we found that the per-connection openssh process would exit with a non-zero status code even if the client disconnected properly: https://bugzilla.redhat.com/show_bug.cgi?id=697698#c59 No idea if that has been fixed upstream since, but that's why the inetd-style socket activation units aren't shipped in Fedora. Well, but that's hardly a performance issue, and adding - to the ExecStart= line makes this problem go away nicely. 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] ssh socket activation (Was: systemd unit files for Debian based systems)
On Wed, 2012-06-20 at 08:44 +0200, Lennart Poettering wrote: On Wed, 20.06.12 10:17, Mathieu Bridon (boche...@fedoraproject.org) wrote: On Tue, 2012-06-19 at 19:15 +0200, Lennart Poettering wrote: On Tue, 19.06.12 18:50, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, On Tue, Jun 19, 2012 at 10:03:23AM +0200, Lennart Poettering wrote: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Do you know of a service file for openssh-server? The Fedora packages have some, but I don't like them too much since they don't use socket activation... Is someone actually working on real socket activation for openssh? While the inetd like stuff works, it does not perform well. it doesn't? In which way? It should be totally OK? When we worked on porting the package to systemd units, we found that the per-connection openssh process would exit with a non-zero status code even if the client disconnected properly: https://bugzilla.redhat.com/show_bug.cgi?id=697698#c59 No idea if that has been fixed upstream since, but that's why the inetd-style socket activation units aren't shipped in Fedora. Well, but that's hardly a performance issue, and adding - to the ExecStart= line makes this problem go away nicely. That's what I had proposed at first, but the maintainer didn't want it as that would also ignore actual errors. I'm pretty sure that's the only thing blocking the addition of a openssh-server-ondemand subpackage in Fedora though (the maintainer doesn't want this to be the default if I recall correctly from the bz ticket). -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? Trying to see this in relation to jhbuild. There I hate webkit and mozilla, but those are in a different order than what is discussed here. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? While I try to keep the dependencies at a minimum, this is not the real issue. I don't think you understand the embedded use-case. Right now what we have is basically a set of rules (how to build things) and some configuration (what to build). And with one command we get a root filesystem image. The configuration is more or less a list of packages to build. Now I need two lists, what to build and what to include in the final image. And while it is possible to implement this, it's also a lot more complex than fixing the real issue for udev. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh socket activation (Was: systemd unit files for Debian based systems)
On Tue, Jun 19, 2012 at 07:45:47PM +0200, Lennart Poettering wrote: On Tue, 19.06.12 23:40, Alexander E. Patrakov (patra...@gmail.com) wrote: IMHO there is one issue with the inetd-style approach: it is explicitly discouraged in man sshd. It may well be the case of outdated documentation, as I don't see any of the indicated problems on my desktop or laptop. Still, it would be nice to clarify this discrepancy in the unit file. I think this is mostly out of date information on today's machines. Starting a per-connection instance is hardly distuingishable from single-instance sshd latency-wise, at least on my machines here. Well, I don't have any numbers, but I think on a 200MHz ARM the situation might be a bit different. (I mean, I'd be happy if somebody would make sshd single-instance socket activatable, but I think the inetd-style activation is pretty OK performance wise and Apple ships SSH like this too, so I don't see why we shouldn't). I was mostly curious because of the issue in the man page. If that is no problem any more, then inetd-style activation is ok. ssh is mostly a debug and development tool for me anyways. And here any socket activation is really great because there is no impact one the startup time and memory usage but it's still available when needed. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 01:46:40PM +0200, Olav Vitters wrote: On Wed, Jun 20, 2012 at 01:32:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. Not really. There are build time dependencies and runtime dependencies. Build time stuff is only of a concern of building the software. Has no relevance to post-install scripts (talking about post-install rpm scripts, not sure if you mean the same). Yes really. This is about the end user of the distro. Which means comparing installing packages. I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? While I try to keep the dependencies at a minimum, this is not the real issue. I don't think you understand the embedded use-case. Right now what we have is basically a set of rules (how to build things) and some configuration (what to build). And with one command we get a root filesystem image. The configuration is more or less a list of packages to build. Now I need two lists, what to build and what to include in the final image. And while it is possible to implement this, it's also a lot more complex than fixing the real issue for udev. This is part of the build systems for the distributions that I know (rpm based; opensuse, fedora, rhel, mageia, mandriva). Forgot how apt does it, assume it has the same functionality. What I mean that you have Requires: and BuildRequires:. What you need for building is not what dependencies are needed once it has been built. It sometimes happens that to apply a patch you need additional BuildRequires to e.g. regenerate 'configure' and so on. That won't result in any extra runtime dependencies. We all know this works very well with the big binary distros. This whole thread is about source distros. Which means every user has to support all build time requirements. Which means they are all part of the final system of _every_ user unless we add extra complexity to keep unwanted things out. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
2012/6/19 Kay Sievers k...@vrfy.org On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: dbus libcap I am quite happy with depending on these two as it makes little sense to build an OS without it, unless you go super minimal in which case sysemd/udev are not relevant. For embedded distros udev without systemd is a very real usecase. m4 intltool gperf (--enable-keymap will require gperf for a udev build as well) These are only build-time deps, and hence are totally OK to have. I don't care about these. But cross-compiling dbus when it's not actually wanted or needed is not ok. There are zero known problems with doing that with D-Bus. All you do is waste CPU cycles on the build system, which is what we all do anyway when we do your own stuff and don't use a pre-compiled package from a distro. I really don't see a problem here besides some inconvenience, which is justified at this moment, where everything is just newly introduced stuff. I mean, the next thing you come up with is a patch to not require automake and use only make, just because you have a problem with dependencies? I mean, seriously. This is uncalled for. Depending on a good build-system is ok. But it was clearly stated that using udev without systemd will still be possible. I don't see why it should not be possible to build udev without systemd and therefore any extra dependencies. We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Without patching the build sys, you can *probably* temporarily work around the build dependencies with things like: $ export PKG_CONFIG_PATH=$PWD; \ echo -e Name: dbus-1\nDescription: stub\nVersion: 999 dbus-1.pc $ ./configure $ make systemd-udevd udevadm ata_id Longer-term plan is to move the D-Bus daemon functionality to the kernel, and let systemd talk directly to the kernel. The external D-Bus dependency might go entirely away with that. At that point, when there is no D-Bus daemon runtime dependency anymore, it is very likely that udevd/udevadm/libudev will use the kernel's D-Bus interfaces too instead of the home-grown IPC, and all of that build-sys splitting and fiddling makes not much sense anymore. NOKIA married with M$ , so, this kdbus stuff is vanished, said. So, please keep that build-sys stuff local please and do not expect any of this to be merged upstream at this moment. We can merge reasonable and obvious patches to make things easier, like we removed the needless D-Bus tools linking for the udev binaries, but we do not want to make promises about full modularization, or things like disabling the build of systemd in the systemd tarball. We properly support *running* (and distros can do such packaging) a standalone udev, for people who run systems without systemd. We just do not support fully separated standalone *builds* at the moment, and maybe we never will. If things turn out differently in the future as we expect them to be, we can discuss that again, but that is unlikely to happen before the end of the year. We first need to see where we will end up with D-Bus when we get there, it might change all the assumptions people make about this sort dependency so far. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 02:34:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 01:46:40PM +0200, Olav Vitters wrote: On Wed, Jun 20, 2012 at 01:32:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. Not really. There are build time dependencies and runtime dependencies. Build time stuff is only of a concern of building the software. Has no relevance to post-install scripts (talking about post-install rpm scripts, not sure if you mean the same). Yes really. This is about the end user of the distro. Which means comparing installing packages. It is only needed during the build, so don't see what you're getting at. Install when needed, remove after. [..] It sometimes happens that to apply a patch you need additional BuildRequires to e.g. regenerate 'configure' and so on. That won't result in any extra runtime dependencies. We all know this works very well with the big binary distros. This whole thread is about source distros. Which means every user has to support all build time requirements. Which means they are all part of the final system of _every_ user unless we add extra complexity to keep unwanted things out. I don't see why it should. Just install the build time dependencies automatically and remove afterwards. If the build system of a source based distribution doesn't know the difference between these, then seems the build system needs to be taught the difference. IMO, this seems to be just a difference in perception. IMO there is a difference between build time and runtime dependencies. If you think that there is no difference (or should be no difference), then every extra build time dependency causes pollution (cause the build stuff is kept on machines instead of removed after building). I don't see why there is a difference between building at a build machine or building at users machine should make any difference. On both types, you don't want to keep those build dependencies on the machine. I can see you of course need to build all the various build time dependencies, so if there a lot it'll result in wasted CPU cycles... but if you want efficiency on that it is easier to have something build everything for you. In any case, if there is no knowledge of build vs runtime dependencies, a machine will already have loads of packages purely for making stuff build. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 'Offline System Updates' examination
'Offline System Updates' will come as feature for Fedora 18. Reading your official page http://freedesktop.org/wiki/Software/systemd/SystemUpdates: The system update script now creates a btrfs snapshot (if possible), then installs all RPMs. After completion (regardless whether the update succeeded or failed) the /system-update symlink is removed. In addition, on failure it reverts to the old btrfs state (modulo the aforementioned symlink), on success it leaves the newly made changes in place. BTRFS ? Will 'Offline Updates' be available only with BTRFS ? How will be managed all kernel modules come from extra Fedora repositories (like RPMFusion) ? Will be possible disable completely 'Offline System Updates' ? Disadvantages of this approach over in-system updates: 1 The system is rebooted twice. This is a very inconvenient. The short boot times obtained with systemd are useless if every update (frequent in Fedora) needs of twice reboot. Regards. -- *Antonio Trande Fedora Ambassador **mail*: mailto:sagit...@fedoraproject.org sagit...@fedoraproject.org *Homepage*: http://www.fedora-os.org *Sip Address* : sip:sagitter AT ekiga.net *Jabber http://jabber.org/* :sagitter AT jabber.org *GPG Key: 19E6DF27* ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 09:40:39PM +0200, Robert Schwebel wrote: Currently, the workflow would be like this: 1) build other components 2a) build prerequisites necessary for systemd, which are otherwhise unneeded; this needs to be installed into the local sysroot in order to let systemd pick up the prerequisites 2b) build systemd+udev 2c) somehow remove the wrong components from sysroot again, as all the rest of the system is not allowed to see them (otherwhise their configure scripts would assume the features to be there) 2d) install only udev 3) move on Instead of: 1) build other components 2) configure with just the right switches, make 3) move on In ptxdist, we have 700+ packages which don't need this kind of special handling (especially 2c will really be a pain). And all this because of something which can be solved in configure.ac. Note: This discussion shouldn't be about if source distributions are a valid use case. Fact is that there are source distributions and people have their reasons to use them. And all source distributions have this issue. We should avoid that everyone implements his own uggly workaround. Agreed. As shown in this thread, there are definitely enough use cases out there for building stand-alone udev that this should be handled upstream so that everyone doesn't have to invent a workaround. Like I've said multiple times on this thread, I don't care whether or not *my* patches get used, but it would be greatly appreciated if there was a way to build udev standalone. Thanks for your consideration, William pgpcmny1kQMIK.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] login/logout hooks in fedora 17?
On 06/18/2012 10:42 AM, Lennart Poettering wrote: On Mon, 18.06.12 10:04, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: Thanks for any advice! Hmm, so there are multiple ways to achieve this, but it really depends on what you are trying to do here. May I ask what kind of script you want to run for a user logging in? Our workstations have a partition on the hard disk for users to use temporarily, mounted under /zap (we've had this for a long long time). When a local user (ie: sitting in front of the machine) logs out the contents of /zap/ are erased. The partition is usually rather big and different from /tmp, /var/tmp, etc (ie: the user should see an empty directory when he/she logins). The script singled out some processes for killing (and log) that could spell trouble for subsequent users if they stayed alive (namely jack and pd if I remember correctly). The script also reloads the state of the alsa mixer so that users are assured sound will work as expected after they login. I also used them to track and terminate any user processes that linger for a while after the logout, but I believe that can be done now through systemd (I think I saw some references to that last week, the name of the preference escapes me right now). Yes, you can do that now with systemd. Just set KillUserProcesses=yes in /etc/systemd/logind.conf. Also do you want this to run prviliged or unprivieleged? I would prefer privileged, that would allow me, for example, to choose what to erase in /zap (not necessarily only the current user's files). OK, with all this I'd recommend using something like pam-hooks or pam-scripts. It will run privileged, works for all PAM services, is not dependant on systemd, and runs synchronously. Thanks for the advice, I'm trying this right now. So far I managed (using pam_script 1.1.6) to trigger a script on login by adding pam_script.so to gdm-password, but I have not found where to activate it for the end of the gdm session. Sigh. Never easy... -- Fernando ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimal builds
On Wed, Jun 20, 2012 at 06:22:49PM +0200, Lennart Poettering wrote: Heya, regarding the whole discussion on minimal builds and people wanting to pick specific parts of the systemd build leaving out others, beyond what the configure switches offer: Here are some guidelines how we recommend people to do this: http://freedesktop.org/wiki/Software/systemd/MinimalBuilds From our side this should be enough to settle the discussion. It isn't for us, because, for example, if I use option 1, I have to do the opposite of the second half of it. Our pm installs everything in the place pointed to by DESTDIR, then I have to manually remove the things I don't need. As was pointed out in a thread earlier, this is very error-prone and definitely could lead to issues. Another thing to think about from our side is, although the main components compile quickly on a pc, how long would it take to compile everything on an ARM-based machine for example? I have no idea, so it could end up being really annoying to users of that platform for us to compile all of the main components and turn around and remove most of them. Thanks for your consideration, William pgpiH93qgo8ee.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 01:46:41PM -0700, Kok, Auke-jan H wrote: You could easily build dbus-for-systemd inside the systemd buildroot, and never install dbus to the sysroot, but in a temporary location. After building the local dbus, system and udev, you just make install in only the udev parts and you now have a system without dbus or systemd. We always find ways to work around crude upstream makefiles, that's not the point. Most of the code in ptxdist/oe/buildroot/... is about patching upstream packages for proper cross compilation. Most of that is necessary because people invent their own superduper makefiles, instead of using proven technologies like autotools etc. The arguments are all in Lennart's paper about userspace for kernel hackers, and we fully second that. The thing is that the source distro maintainers need to invent their own workarounds, in different ways and with different bugs. So our suggestion is to go the systemd way and provide one proven solution in the upstream. However, all this is theory without patches. So I'd suggest that we do our homework first and check if we find a minimal patch which avoids complexity for the maintainers. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimal builds
On Thu, Jun 21, 2012 at 1:49 AM, microcai micro...@fedoraproject.org wrote: 2012/6/21 William Hubbs w.d.hu...@gmail.com On Wed, Jun 20, 2012 at 06:22:49PM +0200, Lennart Poettering wrote: regarding the whole discussion on minimal builds and people wanting to pick specific parts of the systemd build leaving out others, beyond what the configure switches offer: Here are some guidelines how we recommend people to do this: http://freedesktop.org/wiki/Software/systemd/MinimalBuilds From our side this should be enough to settle the discussion. It isn't for us, because, for example, if I use option 1, I have to do the opposite of the second half of it. Our pm installs everything in the place pointed to by DESTDIR, then I have to manually remove the things I don't need. As was pointed out in a thread earlier, this is very error-prone and definitely could lead to issues. Another thing to think about from our side is, although the main components compile quickly on a pc, how long would it take to compile everything on an ARM-based machine for example? I have no idea, so it could end up being really annoying to users of that platform for us to compile all of the main components and turn around and remove most of them. If you don't want to use systemd, then don't use udev, use some thing else old too. most ARM-based machine actually don't use udev, they use busybox. Or an old udev that don't require an recent kernel. If you are stupid enough to use udev, then you probably will use systemd. :) So, don't use the ARM use-case. I think the only reason is you want to support sysvinit. Oh, please, if you're still using sysvinit, then don't use recent udev. sysvinit is old, there is no reason to have a new udev with it. Use old udev too. I really don't think this is helping the discussion at all. There are far better considerations to make, and udev on embedded makes a lot of sense (there is nothing better out there anyway). There is definately good reason for folks to use the new udev (in the long run). Instead, you could have pointed out that one should probably cross-compile from a build-farm for ARM instead - compiling a source distro on an ARM system isn't the most pleasant thing out there. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] login/logout hooks in fedora 17?
On 06/18/2012 10:42 AM, Lennart Poettering wrote: On Mon, 18.06.12 10:04, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote: Thanks for any advice! Hmm, so there are multiple ways to achieve this, but it really depends on what you are trying to do here. May I ask what kind of script you want to run for a user logging in? Our workstations have a partition on the hard disk for users to use temporarily, mounted under /zap (we've had this for a long long time). When a local user (ie: sitting in front of the machine) logs out the contents of /zap/ are erased. The partition is usually rather big and different from /tmp, /var/tmp, etc (ie: the user should see an empty directory when he/she logins). The script singled out some processes for killing (and log) that could spell trouble for subsequent users if they stayed alive (namely jack and pd if I remember correctly). The script also reloads the state of the alsa mixer so that users are assured sound will work as expected after they login. ... Also do you want this to run prviliged or unprivieleged? I would prefer privileged, that would allow me, for example, to choose what to erase in /zap (not necessarily only the current user's files). OK, with all this I'd recommend using something like pam-hooks or pam-scripts. It will run privileged, works for all PAM services, is not dependant on systemd, and runs synchronously. (for some reason a previous response did not make it to the list). Hi Lennart, Thanks for the advice, sounds like the right solution[*]. I managed to get pam_script going. Right now it is at the end of postlogin in /etc/pam.d/ (after several earlier choices) and it works. Half of the time. Literally. The open session script triggers with a gdm login into a gnome session, but the close session script does not trigger with a logout. But both scripts trigger on ssh logins and logouts. Systemd seems to to be happy (at least I see messages in dbus-monitor). But pam, somehow, does not get the right push when I logout of a gnome-shell session (this is all in fc17). So, who is missing a message? (or whatever) Pam? Gnome-shell? Systemd? Another obscure little piece of the puzzle that I can't yet see? A simple logout hook is what I need most, of course. Very very _very_ frustrating. -- Fernando [*] I also tested hacking dbus-monitor and I guess that could be made into a login/logout detector - but how do you differentiate between local and ssh logins? .../login1/Manager messages do not seem to be enough. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Minimal builds
]] William Hubbs Another thing to think about from our side is, although the main components compile quickly on a pc, how long would it take to compile everything on an ARM-based machine for example? I have no idea, so it could end up being really annoying to users of that platform for us to compile all of the main components and turn around and remove most of them. The v44-2 Debian package built in 31 minutes on armel and armhf, compared to 11 minutes for powerpc and 5 minutes for s390x or 14 minutes for ia64. udev by itself (v175-3.1) seems to be around half that. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
