[systemd-devel] How to control the login prompt from my application service unit file?
Hi, We have VMware vApp based solution. Our application gets installed during first boot. Till now we had SLES11 OS based VM and we upgraded to SLES12. Now we have systemd instead of init scripts for service handling. In SLES11, we had service dependency configured in init scripts that was holding back the login prompt until our application installation is done. But in SLES12, we get the login prompt before our application is installed. How to hold the login prompt until our application installation is complete? We tried adding Before=getty@.service in our application install unit file, but its not helping. ~ [Unit] Description=ADG runonce apg_install DefaultDependencies=no After=local-fs.target network-online.target Before=getty@.service Wants=network-online.target Wants=network-onine.target [Service] Type=forking ExecStartPre=/bin/touch /etc/no-login-console ExecStart=/bin/sh -c "/opt/ADG/runonce/scripts/apg_install" ExecStartPost=/opt/ADG/runonce/bin/runonce removeflag apg_install ExecStartPost=/bin/rm /etc/no-login-console KillMode=process Restart=no [Install] WantedBy=multi-user.target Thanks, Shashi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mount units with After=autofs.service cause ordering cycles
So, I much prefer the expressiveness of systemd's mount units to the naive era of /etc/fstab, but I've found one situation where I seem to always get stuck and am never able to find a reliable solution that survives OS (Fedora & CentOS) updates. I have a NFS filesystem mounted by autofs at /pub that needs to be bind mounted in various places such as /var/www/pub and /var/ftp/pub. So I create a unit that looks like: ~~~ # /etc/systemd/system/var-www-pub.mount [Unit] Description=mount /pub served via httpd Requires=autofs.service After=autofs.service [Mount] What=/mnt/pub Where=/var/www/pub Options=bind,context=system_u:object_r:httpd_sys_content_t [Install] WantedBy=multi-user.target ~~~ The above worked for a long time, but once again a `dnf upgrade` seems to have broken things because now I have a ordering cycle that systemd must break. Since I haven't changed my mount units, my ability to mesh with those shipped by the OS proves fragile. I'm deliberately avoiding too much detail here because it would seem that there should be a relatively simple solution to this general sort of task -- I just can't seem to discover it. Any recommendations that don't involve an entirely different approach? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mutually exclusive (timer-triggered) services
exactly for this you would use a flock(1) in your .service. Thanks for the hint, didn't have that in mind. So you're suggesting something like this? # service-a.service # (...) [Service] ExecStart=/usr/bin/flock -F /var/lock/resource.lock /usr/bin/service-a # service-b.service # (...) [Service] ExecStart=/usr/bin/flock -F /var/lock/resource.lock /usr/bin/service-b I see some drawbacks of this approach: * Wrapping the actual command in an flock call seems pretty ugly in my eyes, i.e. looking at the `ExecStart=` lines above I find it very hard to see where the former begins, at first glance. This is subjective, of course. * flock leaves the lock file behind so you'd need some type of cleanup in case you really want the jobs to be trace-free. This is not as trivial as it might seem, e.g. you cannot do it from the service units themselves in `ExecStartPost=` or similar. * /var/lock is very likely not user-writable so you'd need a different lock file directory for user services. You could of course use /tmp for that. * File-based locking makes it impossible to use private filesystem namespaces for the service units (think of `PrivateTmp=yes` and lock files in /tmp). As systemd (or service managers in general) are all about queueing, ordering and controlling services and their dependencies I had hoped there would be a cleaner solution using systemd internals rather than solving it using external tools, which mixes up the service call itself with its requirements (exclusive resource access). Nevertheless I think I will go with your proposal and see how it works out. Best regards, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
On Mon, 14 Oct 2019 16:27:47 +0200 Jonas Meurer wrote: > Yeah, something like that was my hope as well: use plymouth and > framebuffer or something alike for spawning the passphrase prompt. FWIW, I'm just a user but I taboo plymouth on all my systems. I prefer to see the traditional scrolling messages. So I hope the mechanism would fall back to a simple password prompt. Cheers, Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
Hi again, Dimitri John Ledkov: > On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas wrote: >> On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer wrote: >>> Tim Dittler: On 09.10.19 19:26, Lennart Poettering wrote: > On Mi, 09.10.19 12:20, Jonas Meurer (jo...@freesources.org) wrote: >> We[1] are working on bringing luksSuspend for LUKS devices before system >> suspend to Debian. The basic idea is to remove the encryption keys of >> encrypted devices from RAM before suspending the system. >> >> While working on it, we figured out that systemd probably is the best >> place to implement this. Would you be willed to accept related patches >> into systemd? We're still early in the design process, but probably the >> relevant parts will be: >> >> [...] >> >> Lennart's talk[2] about systemd-homed mentions luksSuspend support for >> system suspend, but it's limited to home directories. The whole ramfs >> foo wouldn't be necessary to do that. So a direct question: would you >> still be ok with support for luksSuspending the encrypted root >> filesystem in systemd? >> >> Before spending days of work on implementing this in systemd only to get >> the patches rejected in the end, we thought it would be better to ask >> beforehands ;) > > The thing is, this is far from easy to implement, to the point I don't > think it's viable in the long run at all. I mean, in order to be able > to unlock the root disk after suspend you need the full input and > display stack to be up, i.e. wayland/x11/gnome in the general > case. And that's an awful lot to place in a ramdisk. You will end up > having another copy of the OS as a whole in there in the end... > > systemd-homed maintains only the home directory via LUKS encryption, > and leaves the OS itself unencrypted (under the assumption it's > protected differently, for example via verity – if immutable — or via > encryption bound to the TPM), and uses the passphrase only for > home. THis means the whole UI stack to prompt the user is around > without problems, and the problem gets much much easier. > > So what's your story on the UI stack? Do you intend to actually copy > the full UI stack into the ramdisk? If not, what do you intend to do > instead? >>> >>> As Tim already wrote, the UI stack was not our focus so far. But I >>> agree, that it's a valid concern. My silent hope was to find a solution >>> for a simple passwort prompt that can be overlayed over whatever >>> graphical stack is running on the system. But we haven't looked into it >>> yet, so it might well be impossible to do something like this. >>> >>> But since the graphical interface is running already, I doubt that we >>> would have to copy the whole stack into the ramfs. We certainly need to >>> take care of all *new* dependencies that a password prompt application >>> pulls in, but the wayland/x11/gnome basics should just be there, as they >>> have been in use just before the suspend started, no? >> > > Well, one can do what Mac OS X used to do. Take a screenshot, apply > blur, use as a background in a graphical plymouth to type unlock > password and slowly fade in as things are unfrozen. > > Most desktop systems, already might include graphical plymouth already > (and like framebuffer / dri modules needed for it, among with > cryptsetup tooling but maybe not TPM one). Such that it should be > possible to "just use the initrd" one uses for boot anyway. Yeah, something like that was my hope as well: use plymouth and framebuffer or something alike for spawning the passphrase prompt. But I'm not sure yet how to ensure that we change to the passphrase prompt (or overlay the graphical desktop environment). Another idea that came into my mind: spawn the passphrase prompt *before* system suspend, just like it's apparently done with the screenlock right now. The passphrase prompt could write to a fifo pipe or talk to a small daemon that waits for the luks passphrase(s) to be entered. >> They might not be 100% available from just memory. What happens if the DE >> needs to load assets (fonts, .ui files) for the passphrase prompt from disk? >> (Actually, do any GPU drivers need to load firmware from /lib on resume?) >> > > In Ubuntu, casper component, we work around it by reading the files to > ensure they are in the fscache, and then if one force unmounts the > filesystem underneath them (cdrom eject) plymouth can still "read" > fonts and display late boot messages. So there are ways of doing this. Again, the simplest solution would be to spawn the passphrase prompt *before* suspend, to ensure that all required components are already in memory. Or do you see caveats? Cheers jonas signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.fre
Re: [systemd-devel] Mutually exclusive (timer-triggered) services
Am Montag, den 14.10.2019, 12:45 +0200 schrieb Alexander Koch: > Dear [systemd-devel], > > imagine you've got multiple services that perform system housekeeping > tasks, all triggered by .timer units. These services all happen to > use > a specific resource (e.g. the system package manager) so they must > not > be run in parallel, but they all need to be run. > > Is there a systemd'ish way of modeling this? > > I first thought of using `Conflicts=` but having read the manpages I > understand that queueing one of the services would actively stop any > running instance of any of the others. > > `After=` is not an option either as that (unless 'Type=oneshot', > which > isn't to be used for long-running tasks) doesn't delay up to > completion > but only to initialization. Furthermore I think you'd run into > trouble > ordering more than two units using this approach. > > Ideally I'd think of something like a 'virtual resource' that can be > specified by service units, like this (real use case on Arch Linux): > > [Unit] > Description=Pacman sync > Locks=pacman-db > > [Service] > ExecStart=/usr/bin/pacman -Sy > > > > [Unit] > Description=Pacman cleanup > Locks=pacman-db > > [Service] > ExecStart=/usr/bin/paccache -r -k 0 -u > > The value of `Locks=` shall be an arbitrary string describing the > virtual resource the service is requiring exclusive access to. > systemd > would then delay the start of a unit if there is another unit with > identical `Locks=` entry currently active. > > A nice advantage of this concept is that services depending on the > same > virtual resource would not need to know of each other, which > simplifies > shipping them via separate packages. > > Any thoughts on this? Maybe I'm just too blind to see the obvious > solution to this simple problem. > > > Best regards, > > Alex Hi Alex, exactly for this you would use a flock(1) in your .service. BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mutually exclusive (timer-triggered) services
Dear [systemd-devel], imagine you've got multiple services that perform system housekeeping tasks, all triggered by .timer units. These services all happen to use a specific resource (e.g. the system package manager) so they must not be run in parallel, but they all need to be run. Is there a systemd'ish way of modeling this? I first thought of using `Conflicts=` but having read the manpages I understand that queueing one of the services would actively stop any running instance of any of the others. `After=` is not an option either as that (unless 'Type=oneshot', which isn't to be used for long-running tasks) doesn't delay up to completion but only to initialization. Furthermore I think you'd run into trouble ordering more than two units using this approach. Ideally I'd think of something like a 'virtual resource' that can be specified by service units, like this (real use case on Arch Linux): [Unit] Description=Pacman sync Locks=pacman-db [Service] ExecStart=/usr/bin/pacman -Sy [Unit] Description=Pacman cleanup Locks=pacman-db [Service] ExecStart=/usr/bin/paccache -r -k 0 -u The value of `Locks=` shall be an arbitrary string describing the virtual resource the service is requiring exclusive access to. systemd would then delay the start of a unit if there is another unit with identical `Locks=` entry currently active. A nice advantage of this concept is that services depending on the same virtual resource would not need to know of each other, which simplifies shipping them via separate packages. Any thoughts on this? Maybe I'm just too blind to see the obvious solution to this simple problem. Best regards, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
