Re: [systemd-devel] F16_64: attempt at OpenVPN server service file
On 11/27/2011 11:30 PM, Michael D. Berger wrote: -Original Message- From: Zbigniew Jedrzejewski-Szmek [mailto:zbys...@in.waw.pl] Sent: Sunday, November 27, 2011 14:12 To: systemd-devel@lists.freedesktop.org Cc: Michael D. Berger; 'Reindl Harald' Subject: Re: [systemd-devel] F16_64: attempt at OpenVPN server service file On 11/26/2011 11:39 PM, Michael D. Berger wrote: than i type systemctl stop whatever.service Restart is triggered if they process goes away and in the case of Always this happens even if the process gives back a successfull 0 like after killall processname So I gather that Restart is triggered only if the process goes away ***for reasons other than a stop having been issued***. I suggest that the man pages be modified to say that. Maybe like this? -- 8 -- Subject: [PATCH] man: clarify that Restart= is only for the unexpected cases --- man/systemd.service.xml |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 7b6f12d..7c2ed7e 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -462,8 +462,9 @@ varlistentry termvarnameRestart=/varname/term listitemparaConfigures whether the -main service process shall be -restarted when it exits. Takes one of +service shall be restarted if the main +process exits for reasons other than +the service being stopped. Takes one of optionno/option, optionon-success/option, optionon-failure/option, -- 1.7.8.rc3.348.g8fea1 __ NOD32 6664 (2027) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com The change shown is not bad, but I might say something like ... other than the Stop command being issued... There are other reasons why a unit can be stopped: if the unit Requires a second unit that was stopped, if isolate is requested, and so on. For me, a Stop command being issued seems to take into account only the case of this specific unit being stopped. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] getty login prompt
Michael, Thanks for reply. I am using kernel version 2.6.38 and after objdump, I could see the code for accept4 in libc as well. But still problem persists. Regards, Devendra -Original Message- From: systemd-devel-bounces+devendra.talegaonkar=kpitcummins@lists.freedesktop.org [mailto:systemd-devel-bounces+devendra.talegaonkar=kpitcummins@lists.freedesktop.org] On Behalf Of Michal Schmidt Sent: Friday, November 25, 2011 8:03 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] getty login prompt On 11/23/2011 07:26 AM, Devendra Talegaonkar wrote: 30systemd-stdout-syslog-bridge[78]: Failed to accept new connection: Function not implemented Your kernel or libc does not support the accept4() syscall. Michal ___ 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] Understanding systemd-analyze's plots
On Sun, Nov 27, 2011 at 1:42 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I'd check a fresh install to avoid problem with legacy udev rules... The system was reinstalled when I went to openSUSE 12.1 RC 1 (or Beta 2, don't exactly remember). Since then, I've only updated. Greetings Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Understanding systemd-analyze's plots
On Sun, Nov 27, 2011 at 3:28 PM, Kay Sievers kay.siev...@vrfy.org wrote: There is not that much of the crazy stuff left. And if the filesystem is not on LVM or BIOS raid, most of these packages can be removed. In fact, I've masked lvm.service (=/etc/init.d/boot.lvm) because I don't have LVM and lvm.service looked like it needed a lot of time, but that did not improve the overall startup speed. Greetings Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Understanding systemd-analyze's plots
Le samedi 26 novembre 2011 à 22:52 +0100, Stefan Majewsky a écrit : Hi, my openSUSE 12.1 system boots in about 30 seconds, and I wanted to cut that time down a bit, so I took a look at systemd-analyze's blame and plot output. But I do not really know how to interpret the results which I see in the plot [1]. The startup sequence takes 20.5 seconds in userspace, of which only the last 3 seconds seem to be spent on what I consider the interesting stuff: starting all sorts of services and finally bringing up KDM. The rest of the time seems to be spent activating the hardware, various mounts and udev. (According to the LED on my notebook's case, the disk is busy all the time.) To put my confusion into questions: 1. Why does the system need 6 seconds (from t=6.3s to t=12.3s on the plot) to activate some tmpfs mounts? 2. Why is localnet.service activating for a whole 7 seconds? I looked into it, it's only a SysV init script that sets hostname and domainname from the config in /etc, yet it's number 1 in systemd-analyze blame. 3. Why does it look like about nothing happens between t=13s and t=22s? It might be that openSUSE's unit files (or SysV leftovers) are not yet optimized for the early boot: For example, I seem to have saved some seconds by masking lvm.service (I don't use LVM at all). But that won't explain why systemd is actually slower on this stage of boot vs. the old SysV init some distro versions ago. Can someone enlighten me? Some comments regarding your numbers, since they might be caused by tradeoffs I had to put in openSUSE systemd package : - if you don't use cryptsetup (encrypted partition), you should run systemctl mask storage-after-cryptsetup.service, it should remove the lvm.service reload after cryptsetup.target is reached - if you don't use lvm, systemctl mask lvm.service might help too - localnet.service is still doing too much work, because part of its work is already done by systemd but I didn't had time to move the nisdomain part out of /etc/init.d/boot.localnet to a separate script (or .service). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] F16_64: attempt at OpenVPN server service file
-Original Message- From: Zbigniew Jedrzejewski-Szmek [mailto:zbys...@in.waw.pl] Sent: Monday, November 28, 2011 04:38 To: Michael D. Berger Cc: systemd-devel@lists.freedesktop.org; 'Reindl Harald' Subject: Re: [systemd-devel] F16_64: attempt at OpenVPN server service file On 11/27/2011 11:30 PM, Michael D. Berger wrote: -Original Message- From: Zbigniew Jedrzejewski-Szmek [mailto:zbys...@in.waw.pl] Sent: Sunday, November 27, 2011 14:12 To: systemd-devel@lists.freedesktop.org Cc: Michael D. Berger; 'Reindl Harald' Subject: Re: [systemd-devel] F16_64: attempt at OpenVPN server service file On 11/26/2011 11:39 PM, Michael D. Berger wrote: than i type systemctl stop whatever.service Restart is triggered if they process goes away and in the case of Always this happens even if the process gives back a successfull 0 like after killall processname So I gather that Restart is triggered only if the process goes away ***for reasons other than a stop having been issued***. I suggest that the man pages be modified to say that. Maybe like this? -- 8 -- Subject: [PATCH] man: clarify that Restart= is only for the unexpected cases --- man/systemd.service.xml |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 7b6f12d..7c2ed7e 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -462,8 +462,9 @@ varlistentry termvarnameRestart=/varname/term listitemparaConfigures whether the -main service process shall be -restarted when it exits. Takes one of +service shall be restarted if the main +process exits for reasons other than +the service being stopped. Takes one of optionno/option, optionon-success/option, optionon-failure/option, -- 1.7.8.rc3.348.g8fea1 __ NOD32 6664 (2027) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com The change shown is not bad, but I might say something like ... other than the Stop command being issued... There are other reasons why a unit can be stopped: if the unit Requires a second unit that was stopped, if isolate is requested, and so on. For me, a Stop command being issued seems to take into account only the case of this specific unit being stopped. Zbyszek [...] Excellent point. I might then condider something like: The circumsiances in which the restart process would be initiated are: * program failure of the unit * killall issued on the unit * killall issued on another unit that this unit Requires (? I am guessing) * etc., make the list complete The circumsiances in which the restart process would NOT be initiated are: * The Stop commnd is issued to the unit * The Stop command is issued to another unit that this unit Requires * etc., make the list complete I find bullet lists easy to read quickly, but other formats are acceptable ***provided the information given is clear and complete***. In my long experience as a reader of numerous man pages, often too much is left to trial and error. Mike. -- Michael D. Berger m.d.ber...@ieee.org http://www.rosemike.net/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cannot make java exit 0 on SIGTERM
Hi, I'm running a Java JVM service using: ExecStart=/usr/bin/java -jar foo.jar When I stop the service with systemctl, it goes into the failed state because the JVM exits with status 143 instead of 0. There doesn't seem to be any way to get a JVM to exit(0) on SIGTERM. You can run code on the signal with Runtime.addShutdownHook(), but you cannot call Runtime.exit(0) from within a shutdown hook, so you cannot influence the exit status. Is there any way to get systemd to treat the 143 exit status as normal termination if it sent a SIGTERM? I'd rather not write a signal catching C or shell-script wrapper around the JVM as I'll probably introduce a race condition or other error. Chris. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RefuseEnable
Michael D. Berger (m.d.ber...@ieee.org) said: Is there a way to prevent a service from being enabled? 1) Don't have an '[Install]' section in the unit file 2) Mask the service (ln -s /dev/null /etc/systemd/system/foo.service) 3) Don't install the service file/service binary at all 4) ExecStartPre=/bin/false 5) ... OK, this is rapidly becoming silly What exactly are you trying to accomplish? Are you intending the enable-prevention to be done at the package level or the administrator level? Bill ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RefuseEnable
-Original Message- From: Bill Nottingham [mailto:nott...@redhat.com] Sent: Monday, November 28, 2011 12:14 To: Michael D. Berger Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] RefuseEnable Michael D. Berger (m.d.ber...@ieee.org) said: Is there a way to prevent a service from being enabled? 1) Don't have an '[Install]' section in the unit file 2) Mask the service (ln -s /dev/null /etc/systemd/system/foo.service) 3) Don't install the service file/service binary at all 4) ExecStartPre=/bin/false 5) ... OK, this is rapidly becoming silly What exactly are you trying to accomplish? Are you intending the enable-prevention to be done at the package level or the administrator level? Bill __ NOD32 (2028) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com If I understand correctly, systemctl enable myDaemon, sets up a soft link which results in myDaemon starting automatically on boot. I want to block systemctl enable myDaemon. Blocking disable is less important, especially if enable is blocked. I applied suggestion 1) above, and got the result I wanted. The reason for this is that several daemons do not start correctly on boot on my F16_64. These include httpd and ntpd. Previous posts on the httpd problem yielded no results. The ntpd problem is newly discovered. For a long time, I have had a daemon I wrote that periodically monitors a list of things with ps, and starts them if they are not running. I now use that for daemons I would like automatically started but do not start correctly on boot. I think it best if these problem daemons do not try to start on boot. My new system appears to be functioning well now. Mike. -- Michael D. Berger m.d.ber...@ieee.org http://www.rosemike.net/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FW: F16_64: attempt at OpenVPN server service file
I resend some of this because I think it is inportant, and for some reason it didn't make it to the list. The change shown is not bad, but I might say something like ... other than the Stop command being issued... There are other reasons why a unit can be stopped: if the unit Requires a second unit that was stopped, if isolate is requested, and so on. For me, a Stop command being issued seems to take into account only the case of this specific unit being stopped. Zbyszek [...] Excellent point. I might then condider something like: The circumsiances in which the restart process would be initiated are: * program failure of the unit * killall issued on the unit * killall issued on another unit that this unit Requires (? I am guessing) * etc., make the list complete The circumsiances in which the restart process would NOT be initiated are: * The Stop commnd is issued to the unit * The Stop command is issued to another unit that this unit Requires * etc., make the list complete I find bullet lists easy to read quickly, but other formats are acceptable ***provided the information given is clear and complete***. In my long experience as a reader of numerous man pages, often too much is left to trial and error. Mike. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
