Re: [systemd-devel] Method to Wait for service to complete
On 8/12/15 12:32 PM, killermoehre wrote: > Am 12.08.2015 um 20:34 schrieb Harry Goldschmitt: >> I have a service that has to complete before boot can continue. Is there >> an “approved” method for doing this? >> >> >> >> I have an ugly solution I’ve come up with… I’ve created a foo.target to >> run my foo.service and set the default.target to my foo.target. After my >> foo.service completes, I’m issuing “systemctl isolate multi-user” to >> complete the boot. >> >> >> >> Any help would be appreciated. >> >> >> >> Harry > Because my first answer wasn't send to the ML, here again: > >> Hello Harry, >> >> so the first question here always is: why do you think your service >> is so important that no other service should be run at the same time? >> Can you give us more information about your service? Some >> explanaition what it does and why it should run before boot completes >> (which is quite the funny thing, because "boot end" is never defined >> with systemd, because everyting is brought up in parallel only taking >> dependencies in account). >> >> Regards > Harrys answer > >> My product is a Linux network appliance and my service updates >> platform and peripheral firmware as needed without human >> intervention. For the updates to take effect, the platform needs to >> be rebooted after updates. If a network card needs new firmware, the >> network is shut down before the update. If a peripheral needs to be >> updated, it is shutdown, too. It would probably be a bad idea to let >> users log into the appliance only to shutdown peripherals and then >> reboot after a firmware update. In addition we have several services >> that should not be brought up before it is known that firmware needs >> to be updated. >> >> Before systemd, we just ran the service early in the boot process. >> 99.9% of the time the service did nothing and boot continued. If >> something had to be updated, the service did the update and rebooted. > In the end after I got his answer it boils down to > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freedesktop.org_wiki_Software_systemd_SystemUpdates_&d=BQIDaQ&c=8S5idjlO_n28Ko3lg6lskTMwneSC-WqZ5EBTEEvDlkg&r=naTX-IF7_QKyhqVve7SqbI_X3j-x4BDG1qRD3DBP5SU&m=ZM6b57JGl756Bwbd0UsC6ZGXt3aD-B8GRzrA_4gID2Y&s=fDLbpYg1uEoUgEUfFPmQiEPkfpiAXiaRn1AMycnZbT8&e= > > > Regards > Thank you. That's exactly what I need. Harry -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Console screen blanks while long running service executes
On 8/12/15 7:22 PM, Chris Bell wrote: > On 2015-08-12 20:19, Harry Goldschmitt wrote: >> I just modified my grub kernel command line to add the consoleblank=0 >> parameter. That isn't the problem. First consoleblank is the kernel >> screensaver and according to the documentation it kicks in after 15 >> minutes by default. >> >> What I see is a few kernel driver start up messages. Then the console >> screen blanks for about 10 seconds. Then multi-user boot completes. > The only other thing I can think of is when modesetting kicks in and is > configuring your graphics adapter? You could try adding the 'nomodeset' > kernel parameter to your boot, but keep in mind that you will lose > kernel modesetting, which could potentially cause issues with your > system. I'm not sure what else would cause the screen to 'blank' like > you are describing at that point in the boot. > > --Chris > I found it. Not a systemd issue at all. "console=ttyS0" had been dropped from the kernel command line. Without it my Dell iDrac virtual console went grey after GRUB boot. After I added the parameter the console stayed live and I could echo errors to /dev/tty1. I know everything I need is available by journalctl, but the echos help when the system doesn't come up far enough for journalctl to work. Thanks for looking at this. -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Option substitution in unit configuration files?
Thanks to both of you! > I'd always encourage > you to fix the daemon in question to make something like the above > unnecessary. True. Since I'm only packaging the daemon, I can just guess its written as it is to make sure the daemon can remove the PID file independent of the platform its running on and how it was invoked. > But for unprivileged access to pidfiles the usual approach is to create > a dedicated subdirectory under /run¹, either using RuntimeDirectory= > or a full tmpfiles.d config, and tell the service to use > "/run/myservice/myservice.pid". It might be simpler than touch+chown, > and a bit cleaner. You're right. Since I have to solve the same problem for both SysV and systemd, its the better solution. Malte ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Method to Wait for service to complete
On Wed, 12.08.15 18:34, Harry Goldschmitt (harry.goldschm...@quantum.com) wrote: > I have a service that has to complete before boot can continue. Is > there an "approved" method for doing this? Not sure what "boot can continue" is supposed to mean, but all systemd units support After= and Before= dependencies on units that are useful for ensuring that specific services have finished initialization before or after some other service. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Option substitution in unit configuration files?
On Sun, 16.08.15 16:36, Malte Forkel (malte.for...@berlin.de) wrote: > Hi, > > Is there some kind of option substitution in unit configuration > files? Unit files are supposed to be simply configuration files, not a macro language. That said there is: 1) Specifier expansion in a number of settings, resolving things like %i, %f, %b or %H. For a full list of these specifiers, please check systemd.unit(5), there's a whole section about it. 2) ExecStart= and friends support a limited form of env var substitution based on the env vars accumlated when the process specified is invoked, combining all env vars inherited from PID1, those set via Environment=, and EnvironmentFile= as well as a those set due to socket activation, watchdog settings, and a couple of other reasons. Other forms of substituion are not available. > In a service configuration file, I specify the PID file and would like > to re-use its name, e.g. > PIDFile=/var/run/myservice.pid > ExecStartPre=/usr/bin/touch %PIDFile ; /bin/chown myuser %PIDFile This is not supported. Sorry. If you really need this you'd have to specify the path explicitly each time. That said, I'd always encourage you to fix the daemon in question to make something like the above unnecessary. The general problem with doing generic subsituations like the above is that the files cannot be parsed linearly. THis becomes particularly visible if you think about subsitution order: is there suppsoed to be a difference between specifying the two lines like the above or in the reverse order? What do you do with cyclic substituion? And so on... Of course, one could find answers to all these questions, that make sense, but the simple act of asking these questions indicates that one is firmaly in the area of macro languages then, and not simple configuration files anymore... Or in other words: consider using a proper macro language if you want one, for example, m4 or so... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Option substitution in unit configuration files?
On Sun, Aug 16, 2015 at 5:36 PM, Malte Forkel wrote: > Hi, > > Is there some kind of option substitution in unit configuration files? > > In a service configuration file, I specify the PID file and would like > to re-use its name, e.g. > PIDFile=/var/run/myservice.pid > ExecStartPre=/usr/bin/touch %PIDFile ; /bin/chown myuser %PIDFile > Generally there isn't, at least not for referencing unit options. But for unprivileged access to pidfiles the usual approach is to create a dedicated subdirectory under /run¹, either using RuntimeDirectory= or a full tmpfiles.d config, and tell the service to use "/run/myservice/myservice.pid". It might be simpler than touch+chown, and a bit cleaner. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Option substitution in unit configuration files?
Hi, Is there some kind of option substitution in unit configuration files? In a service configuration file, I specify the PID file and would like to re-use its name, e.g. PIDFile=/var/run/myservice.pid ExecStartPre=/usr/bin/touch %PIDFile ; /bin/chown myuser %PIDFile Thanks, Malte ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Troubleshooting Failed Nspawn Starts
On Fri, 14.08.15 14:23, Rich Freeman (r-syst...@thefreemanclan.net) wrote: > On Fri, Aug 14, 2015 at 1:30 PM, Lennart Poettering > wrote: > > On Mon, 10.08.15 08:03, Rich Freeman (r-syst...@thefreemanclan.net) wrote: > > > > We have watchdog (see WatchdogSec= documentation in > > systemd.service(5)) support in all our long-running daemons, and PID 1 > > will kill the service and generate a backtrace for them if they don't > > send a watchdog message often enough. So actually we should be pretty > > good here... > > Thanks. In this case I'm not sure if it is needed more for nspawn > itself, or for systemd (which probably won't work unless nspawn > supports watchdog), or for journald/etc. journald supports the sd_notify() watchdog logic. systemd itself currently does not. Adding this would make a lot of sense, both for the case where "systemd --user" is run, and where systemd is invoked by nspawn. nspawn doesn't support this either. It cannot send out watchdog keep-alive messages to its invoking program, nor can it receive watchdog keep-alive messages from the init system. Adding both would make sense. Could you file a github RFE issue, asking for support for watchdog keep-alive message send stuff in PID 1 and nspawn, and watchdog keep-alive message receive stuff in nspawn? I think it would make a lot of sense to add this! > > journalctl --flush actually pretty much only sends SIGUSR1 to > > journald, but does this through PID1's bus APIs... It then waits for a > > file in /run/systemd/journal/flushed to appear... For some reason that > > doesn't work here... Weird... > > I'm actually wondering if it is some kind of dbus api issue. I don't > have anything in this email but I seem to recall seeing some error in > a situation like this that mentioned dbus. Could be. The kill request is done via PID1's bus APIs after all... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network configuration
On Fri, 14.08.15 19:50, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > Actually what is a procedure for more complicated network > configuration, where you do not have something in networkd? Well, we try to cover a good chunk of the usecases, but we want be conservative when exposing options, to make this not more complex and overwhelming than it already is. For example, options people never actually use or that are clearly legacy don't need to be exposed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Who has rights to override/ignore inhibitors?
On Fri, 14.08.15 21:12, Jayson Willson (jaysonwillson...@gmail.com) wrote: > Hello. I have realized, that my user (groups: > tty,disk,mail,news,dialout,voice,sudo,audio,www-data,video,plugdev,users,mlocate,kvm,vboxusers,libvirt) > can ignore inhibitors (such as root being logged in) using "systemctl > suspend -i" without password prompt (though su, sudo and polkit do require > password). > Could you please tell me, which users can ignore inhibitors, and what should > be changed to change such behaviour? Thank you. This is subject to PolicyKit policy. See /usr/share/polkit-1/actions/org.freedesktop.login1.policy. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
