Re: [systemd-devel] starting processes for other users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Fri, 31 Jul 2015 00:19:06 +0200 Michał Zegan пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello. > What is the recommended easy way to start processes that stay longer > like screen in case I want to do it by first executing su to change to > the target user? This is controlled by KillUserProcesses, see man logind.conf. But default is to leave them running, so it should just work. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlW67RAACgkQR6LMutpd94zC9gCfYFLEInR4sMtcyW8W81awrQMm 3UcAoIA2zyDvq4u9EAsktdEkPsQnBwGL =FTrm -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Complicated SysVInit Migration
В Thu, 30 Jul 2015 16:53:43 -0500 Lesley Kimmel пишет: > I can't really change anything about the way that the Node Manager does it's > job. That all takes place outside of systemd. If I used the PIDFile option in > the original systemd service (executing the WLST process), let's call this > weblogic.service, and the PIDFile pointed to the PID file created by the > final Java process, would that work or does the process that I'm ultimately > starting have to descend directly from whatever it is that the unit file > executes? Process has to be part of cgroup of original systemd service; and for all practical purposes this means it has to be direct descendant of one of ExecStart* commands. There is no systemd API to move processes between cgroups. What exactly is wrong in how it behaves currently? It is no worse than it was before, with sysvinit, right? Do you observe any problems? > > Date: Thu, 30 Jul 2015 23:47:03 +0300 > Subject: Re: [systemd-devel] Complicated SysVInit Migration > From: graw...@gmail.com > To: ljkimme...@hotmail.com > CC: systemd-devel@lists.freedesktop.org > > On Thu, Jul 30, 2015 at 9:40 PM, Lesley Kimmel wrote: > > > > All; > > I'm struggling with figuring out how to migrate some SysVInit scripts to > systemd. Specifically, this service launches WebLogic Managed Server (Java) > instances Let me describe the process flow of my current service to you: > > -The init service/script launches a Java process called WLST which executes a > simple script > -This WLST process connects to an already running Java process called the > Node Manager and issues a start command for the application server it wishes > to start > -The Node Manager process executes a shell script as a subprocess. This shell > script sets up a bunch of environment variables, etc. > -Ultimately the shell script launches a Java process which is a child of the > shell script. > -When this Java process reports itself as running, the initial WLST Java > process exits. > -In the end the actual service/process that we started, and want to manage, > is actually the GRANDCHILD of a completely separate process from the initial > Java process that systemd launched. How, would systemd track that process? > > systemd would see it as an extra process belonging to NodeManager.service, > nothing more. > If you want systemd to track it as an independent service, go back to step #3 > (where the Node Manager executes a shell script), and make that shell script > merely run "systemctl start ..." instead of creating the new instance > directly. (Make a template foo@.service unit for the WLMS instances.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] starting processes for other users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. What is the recommended easy way to start processes that stay longer like screen in case I want to do it by first executing su to change to the target user? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVuqLXAAoJEHb1CzgxXKwY2Y4QAI4RPhz9uOUIdPIL/5N3nL0G 9Be+y5+6l3XBlPZgJ7CtxOncZkz6jBoqqgCacyIdED55tuRyCY5cywVF4xvNgwL3 AbZSAQYwyVX/t789nNxnduhMeZlhpRc5vs2+CN7FU2+b/MrlnJ1o8SLPZXYxLA8S jMylkqmR4czj+rypcn7KwjPBdFWnnuGl/shrycB6Gx+BjVFHcDQ9zbwnzwYfHHdv g7g9+0n0PYomrKCw4EPJXdi0IVM4mc207q6eXjSOicALKSgkUmABCZ1ddOt0lXWX G5wUEqb77HWSJkKIUIqR8kyfSFOTS7kEROVvC8ipnReeFV2RadKtb9ZmHbz+2OJN pWj+vOyS6e7MjOwbbAQCtMqt/qD7hhP3EEAqv/STH+9zYhqFC9RbX3lyp3aUhL6O xGOf9tx2/D+OJnH38cT+g4/4bGxRG5cawL5tTg7Ki4LN2Ajkk8wP+E9K/5eExuJl S2052M7xg399/W5j6TcFsg5NL7L9XWPw+trF6S2he0/9T6w9m9laM7Ellr40Bgt1 CeTd4/tScaSKrnM8lU39fEqCJq2UK7S59VceyLkjO493fF9OTHzQ7CEM9VVtFPXZ 41zBZW4UeQZXBefwPffjxHunT4HjRin3Awr84nrxq1/Acyoa2NwLJwYSe+zNaju5 I5PWQX6OZ/nN0xwzSheA =zxdk -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Complicated SysVInit Migration
I can't really change anything about the way that the Node Manager does it's job. That all takes place outside of systemd. If I used the PIDFile option in the original systemd service (executing the WLST process), let's call this weblogic.service, and the PIDFile pointed to the PID file created by the final Java process, would that work or does the process that I'm ultimately starting have to descend directly from whatever it is that the unit file executes? Date: Thu, 30 Jul 2015 23:47:03 +0300 Subject: Re: [systemd-devel] Complicated SysVInit Migration From: graw...@gmail.com To: ljkimme...@hotmail.com CC: systemd-devel@lists.freedesktop.org On Thu, Jul 30, 2015 at 9:40 PM, Lesley Kimmel wrote: All; I'm struggling with figuring out how to migrate some SysVInit scripts to systemd. Specifically, this service launches WebLogic Managed Server (Java) instances Let me describe the process flow of my current service to you: -The init service/script launches a Java process called WLST which executes a simple script -This WLST process connects to an already running Java process called the Node Manager and issues a start command for the application server it wishes to start -The Node Manager process executes a shell script as a subprocess. This shell script sets up a bunch of environment variables, etc. -Ultimately the shell script launches a Java process which is a child of the shell script. -When this Java process reports itself as running, the initial WLST Java process exits. -In the end the actual service/process that we started, and want to manage, is actually the GRANDCHILD of a completely separate process from the initial Java process that systemd launched. How, would systemd track that process? systemd would see it as an extra process belonging to NodeManager.service, nothing more. If you want systemd to track it as an independent service, go back to step #3 (where the Node Manager executes a shell script), and make that shell script merely run "systemctl start ..." instead of creating the new instance directly. (Make a template foo@.service unit for the WLMS instances.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Complicated SysVInit Migration
On Thu, Jul 30, 2015 at 9:40 PM, Lesley Kimmel wrote: > All; > > I'm struggling with figuring out how to migrate some SysVInit scripts to > systemd. Specifically, this service launches WebLogic Managed Server (Java) > instances Let me describe the process flow of my current service to you: > > -The init service/script launches a Java process called WLST which > executes a simple script > -This WLST process connects to an already running Java process called the > Node Manager and issues a start command for the application server it > wishes to start > -The Node Manager process executes a shell script as a subprocess. This > shell script sets up a bunch of environment variables, etc. > -Ultimately the shell script launches a Java process which is a child of > the shell script. > -When this Java process reports itself as running, the initial WLST Java > process exits. > -In the end the actual service/process that we started, and want to > manage, is actually the GRANDCHILD of a completely separate process from > the initial Java process that systemd launched. How, would systemd track > that process? > systemd would see it as an extra process belonging to NodeManager.service, nothing more. If you want systemd to track it as an independent service, go back to step #3 (where the Node Manager executes a shell script), and make that shell script merely run "systemctl start ..." instead of creating the new instance directly. (Make a template foo@.service unit for the WLMS instances.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks, tracking it. W dniu 2015-07-30 o 20:41, Andrei Borzenkov pisze: > В Thu, 30 Jul 2015 20:07:03 +0200 Michał Zegan > пишет: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> Here is a log from appserver.service: appserver.service: Trying >> to enqueue job appserver.service/stop/replace appserver.service: >> Installed new job appserver.service/stop as 16578 > >> appserver.service: Enqueued job appserver.service/stop as 16578 > >> appserver.service: Changed running -> stop-sigterm > >> Stopping java application server... > >> appserver.service: Child 19079 belongs to appserver.service > >> appserver.service: Main process exited, code=killed, >> status=15/TERM > >> appserver.service: Changed stop-sigterm -> dead > >> Stopped java application server. > >> appserver.service: Child 19142 belongs to appserver.service > >> appserver.service: cgroup is empty > >> appserver.service: cgroup is empty > > >> What happens with the other child? > > You are likely facing variant of > https://github.com/systemd/systemd/issues/317 > > First SIGTERM kills your parent shell immediately. For systemd it > means "service is stopped" and it enters final SIGTERM. Now it does > not wait for child to stop but rather immediately sends final > SIGKILL. > > Either your parent needs to wait until child exits, or you should > get rid of parent so that Java process is main process for > systemd. > > Or you can revert commit mentioned in issue :) > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVuoXMAAoJEHb1CzgxXKwYJocP/1PG3XrYCAd5D6fYqXCWh6zb nC2ihbQNJlQ/D71y2AbGfpf2lMan24WlD7T8FEQlYRoPw7o3BqBvTSCaxtR+DulT Ez26o/qH9/ga1i/4bQ73Dr9UzS5hmWGGSBw1puqjQVNnR5zJuIlYXQzPH4NjwNV7 Rne/3+1JH8pC6AUzNUj8QVQNndNphIrpxkRC4h++OCcU2njZ0G7UcXCkFVGjAjxr 6Cqx87MN9dQ9q4ek15nRyNpkUYwpdGTTj5nDOibXXVlKaJSJ4OhUwXRotxWAYBrH uG7Ig49lUEhkIulK9BO5AnBZj8wU2jmBLiaNEUU6ulZIpYOlKJncJ/lFuUTWZgrd 1nBrNSXRx9wM8wTsJ0RYdl7IRZcm+V23WTWyMGNxYDgiyhfjLlzHkiVzW8Z6BCfj jjtlkg+vNe1ZAytCTMZIrHk3g7E9rqNg4O63pPdz0L80tvKlKYDSA1hK1nZ7g2Hb qy4P4sr0dWvTFb0gxrklXEPu9wfQQRiaGig1wbyCBu9i5C+309HWFgpupbRIA6cV /MLFwkMJYYPcP01MWJeVpAUfr7vwKTnDB7uheqbVDJi4MjdMyEApYpskm54cPL8g sD9GhCgEmn+sjJJkOW3lnXUKN2Ee/4uMCA52FkG1DiCUyuaUG0t556qp0faTac2q 8sQ9gNuOQRsCGRR1m3su =0Mfx -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /var/lib/machines be a mounted subvolume rather than an actual subvolume?
On Mon, Jul 27, 2015 at 1:26 PM, Lennart Poettering wrote: > On Thu, 16.07.15 12:40, Chris Murphy (li...@colorremedies.com) wrote: > >> Hence the question, rephrased, does systemd expect /var/lib/machines >> to be an actual subvolume rather than a mountpoint backed by a mounted >> subvolume? > > No. it can be anything. systemd will create it as subvol if it is > missing, and you will get more features if it is a subvolume (like the > quota/disk usage stuff menionted above) but it degrades gracefully if > it is just a normal dir. It will still be possible to snapshot it, and set quotas, just not delete it because it would be a mounted subvolume rather than a nested one. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] in-kernel structured logging
On Thu, Jul 30, 2015 at 9:47 PM, Anne Mulhern wrote: > > Where can the support for structured logging be found in the kernel? > It seems tricky, given the kernel's constraints, to support arbitrary > structured logging. > It was added to kernel/printk.c in v3.5 – printk_emit() accepts an array of key=value metadata, and printk() is a thin wrapper around that. At the same time /dev/kmsg was added, to export the attached data and fix various other problems which /proc/kmsg had. https://git.kernel.org/linus/7ff9554bb578 https://git.kernel.org/linus/e11fea92e13f https://git.kernel.org/linus/c4e00daaa96d https://git.kernel.org/linus/3b552b92817c Rsyslog can import the structured data from /dev/kmsg: http://www.rsyslog.com/doc/v8-stable/configuration/modules/imkmsg.html -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] in-kernel structured logging
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Anne Mulhern" > Cc: systemd-devel@lists.freedesktop.org > Sent: Thursday, July 30, 2015 1:04:55 PM > Subject: Re: [systemd-devel] in-kernel structured logging > > On Thu, Jul 30, 2015 at 12:16:03PM -0400, Anne Mulhern wrote: > > Hi! > > > > This is really closely related to my previous question re. formalizing an > > API. > > > > In the design document > > (https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs) > > there is a statement about a future intention to support "in-kernel > > structured logging". > > > > Are things like dev_printk() considered to have achieved that, or is > > something more planned for the future? > > One thing is the basic support for structured logs, which was > implemented, another is patching all the places which produce logs > to attach useful metadata. This is only partially done. > If you look at kernel logs from a boot, even basic things > like the priority are set semi-randomly. So from the kernel > the state could be described as POC. > Where can the support for structured logging be found in the kernel? It seems tricky, given the kernel's constraints, to support arbitrary structured logging. I'm likely missing something, but as far as I can tell, dev_printk() is like printk(), except that it takes a few more parameters from which a few more fields about the device are automatically extracted and added to the buffer. Maybe dev_printk is one instance of what is considered the correct way to do structured logging in the kernel? > > From systemd side, we have the fields, but we don't do interesting > things with them. One problem is that the kernel gives us tags > like _KERNEL_DEVICE=+scsi:8:0:3:0 which are dynamic, and change > between boots. For the logs to be useful, we would have to map > those to some static identifiers. It would be nice to tell journalctl > "give me all logs about /dev/sda", but we're not there yet. > > Zbyszek > - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Thu, 30 Jul 2015 20:07:03 +0200 Michał Zegan пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Here is a log from appserver.service: > appserver.service: Trying to enqueue job > appserver.service/stop/replace > appserver.service: Installed new job appserver.service/stop as 16578 > > appserver.service: Enqueued job appserver.service/stop as 16578 > > appserver.service: Changed running -> stop-sigterm > > Stopping java application server... > > appserver.service: Child 19079 belongs to appserver.service > > appserver.service: Main process exited, code=killed, status=15/TERM > > appserver.service: Changed stop-sigterm -> dead > > Stopped java application server. > > appserver.service: Child 19142 belongs to appserver.service > > appserver.service: cgroup is empty > > appserver.service: cgroup is empty > > > What happens with the other child? You are likely facing variant of https://github.com/systemd/systemd/issues/317 First SIGTERM kills your parent shell immediately. For systemd it means "service is stopped" and it enters final SIGTERM. Now it does not wait for child to stop but rather immediately sends final SIGKILL. Either your parent needs to wait until child exits, or you should get rid of parent so that Java process is main process for systemd. Or you can revert commit mentioned in issue :) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlW6b9kACgkQR6LMutpd94w/pACgvnPjF3xVms4D0qv9i24MlnRh 8ukAoMJhioFyh3/n6uDX9w21l24T5Fxk =5S47 -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Complicated SysVInit Migration
All; I'm struggling with figuring out how to migrate some SysVInit scripts to systemd. Specifically, this service launches WebLogic Managed Server (Java) instances Let me describe the process flow of my current service to you: -The init service/script launches a Java process called WLST which executes a simple script -This WLST process connects to an already running Java process called the Node Manager and issues a start command for the application server it wishes to start -The Node Manager process executes a shell script as a subprocess. This shell script sets up a bunch of environment variables, etc. -Ultimately the shell script launches a Java process which is a child of the shell script. -When this Java process reports itself as running, the initial WLST Java process exits. -In the end the actual service/process that we started, and want to manage, is actually the GRANDCHILD of a completely separate process from the initial Java process that systemd launched. How, would systemd track that process? Thanks in advance, -Les Kimmel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Thu, 30 Jul 2015 19:57:42 +0200 Michał Zegan пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > First, it seems that sighup is NOT sent by default. Yes, sorry, my mistake. > Second, setting SendSIGKILL to no fixes the problem (and that should > not be needed), that probably means the second process gets sigkill. > It does not explain what happens. Debug logs may help. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlW6Z90ACgkQR6LMutpd94wJMgCgmzVB0vSpYx36iGJvliyVlAa3 lkIAoK65zwuHL1S1sYwLNEfP6O0Asfkc =oEWb -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is a log from appserver.service: appserver.service: Trying to enqueue job appserver.service/stop/replace appserver.service: Installed new job appserver.service/stop as 16578 appserver.service: Enqueued job appserver.service/stop as 16578 appserver.service: Changed running -> stop-sigterm Stopping java application server... appserver.service: Child 19079 belongs to appserver.service appserver.service: Main process exited, code=killed, status=15/TERM appserver.service: Changed stop-sigterm -> dead Stopped java application server. appserver.service: Child 19142 belongs to appserver.service appserver.service: cgroup is empty appserver.service: cgroup is empty What happens with the other child? I have tested that killing the shell process normally does not kill the child, only the reverse, so... W dniu 2015-07-30 o 18:23, Andrei Borzenkov pisze: > В Thu, 30 Jul 2015 14:51:44 +0200 Michał Zegan > пишет: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> Actually when I have sent the question I had systemd-222. now it >> is 223 and result is the same. Unit file is at >> http://webczatnet.pl/webczat/appserver.service > > > By default systemd also sends SIGHUP right away; how your service > reacts to it? > > You can enable systemd debugging (/bin/kill -RTMIN+22 1), stop > service and look at logs or post here. > > P.S. KillSignal=SIGTERM is default and redundant > >> W dniu 2015-07-30 o 05:36, Andrei Borzenkov pisze: >>> В Wed, 29 Jul 2015 21:17:18 +0200 Michał Zegan >>> пишет: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> Hello. >>> I am trying to use systemd to run wildfly application server. It is being run by a shell script that runs a java vm in a separate process. So, killing the script does not kill the other process. The service is a simple type service, and I am wondering what happens there on stop. when the server receives signal sigint or sigterm directly it logs some messages about it being stopped. However, when I start it and then stop, this does not happen, i get no message as if it was killed by sigkill. What may happen? the documentation says that the systemd sends sigterm to all processes by default (if KillMode=control-group and this is probably default), and then sigkill if processes do not respond for a configured amount of time. In this case sigterm sent to the shell script (the main process) causes it to exit, but then appserver is probably sigkilled. I know that setting sendSIGKILL to no makes it shudown normally. What is going on? >>> >>> Could you post your unit file and which version of systemd? >>> >> > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVumfFAAoJEHb1CzgxXKwYCWwQAMM5jqB4btrIlUJbfRYyMC1o q8K5bAMadVDw5PmdZkcJrly7cEsvC1JcTumt/0O/OPeRfIe6W2cCTmulLJWe3XCM v6ixN3NCBTW6BqxSGDtW4A5v7KWs6cTlLPzgzsAtPf+oiz31l34IZ0xVWdpd06Zt Sh0Vj65+wKFX3DEGo3dq0illwZySRXV7Yf5r42cJUINRe/cO8pvF/8uIao7KUmAa 2WYfy7T3zCc/wkMmb5kayh/8F8sYYzrLBKaN6NbNlgMhTdV3Mri81Jz78TEJuwUn LYI8Koi0VEhUWFRvdEgyqMJoChs1jdXWvLtbuuFm00hjcDBQq4LOujz5/qMK7K9D KgTgcJof5+dJaSG10MC3VxBUSijcNtAEuk7VuNlbH7KSzUwdOk0ntIo++6Bsaj4e V/n4xrD08SlTXRM6MMruVNApqPcEvRjriDHTJjLLKE+Q0clnwoawCUBzGCq5hgKh H7IfPd36NxDbSYQKojAzZ8g6gUCkO5zNGG3ZRolK2k1LZX755KSv3+gcp6iNkoPO FKF4uFF34CcyPxzc29+nQ2M2555A7uZJo4Bm2aCT2/0b++WIrI2SdYC6wRt12U66 E411ZK5/4ROZrwFIkwICoFcMCGVTssR62AO7sHyJy6K58c92wyslhfM/HcuGqbJ4 kamXEs1kkTkQLIUiwOCR =A1is -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First, it seems that sighup is NOT sent by default. Second, setting SendSIGKILL to no fixes the problem (and that should not be needed), that probably means the second process gets sigkill. W dniu 2015-07-30 o 18:23, Andrei Borzenkov pisze: > В Thu, 30 Jul 2015 14:51:44 +0200 Michał Zegan > пишет: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> Actually when I have sent the question I had systemd-222. now it >> is 223 and result is the same. Unit file is at >> http://webczatnet.pl/webczat/appserver.service > > > By default systemd also sends SIGHUP right away; how your service > reacts to it? > > You can enable systemd debugging (/bin/kill -RTMIN+22 1), stop > service and look at logs or post here. > > P.S. KillSignal=SIGTERM is default and redundant > >> W dniu 2015-07-30 o 05:36, Andrei Borzenkov pisze: >>> В Wed, 29 Jul 2015 21:17:18 +0200 Michał Zegan >>> пишет: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> Hello. >>> I am trying to use systemd to run wildfly application server. It is being run by a shell script that runs a java vm in a separate process. So, killing the script does not kill the other process. The service is a simple type service, and I am wondering what happens there on stop. when the server receives signal sigint or sigterm directly it logs some messages about it being stopped. However, when I start it and then stop, this does not happen, i get no message as if it was killed by sigkill. What may happen? the documentation says that the systemd sends sigterm to all processes by default (if KillMode=control-group and this is probably default), and then sigkill if processes do not respond for a configured amount of time. In this case sigterm sent to the shell script (the main process) causes it to exit, but then appserver is probably sigkilled. I know that setting sendSIGKILL to no makes it shudown normally. What is going on? >>> >>> Could you post your unit file and which version of systemd? >>> >> > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVumWUAAoJEHb1CzgxXKwYRVYP/jrbXjV7QurkHN7nnNHIPOAb omX3xbPlrRe0IdgmIQkguXwKPRPueiuNx4mILqFZXhEVwjGGhpA4/zoGVXnKk5gH JPWOZmklDMLQZCTerlWsXGI5B+ze/apFdTMmeLnl9vhuOnubvOO5qReL8z/2MB6N iOjgijKtBRV+w66XcmaGHnfwkkIyO1J+kaEhHLqDpp97S1X3cys8FGyXRQejt6Zv Nusr3OP3iWRn382eXwh47gDSGFuNQVtCkLwMRXeVOXOGM0O+dclUNvYBClPirOpg lM3kgbYC4Z6l11ZfzICDDIaY25l46gobbW+L9e+SWouNkhmTaPgF9yzdwT1M6HXw nnsOAZMbXoCGwj41bhttZnILQ5KW1CrqEB3Y5KzSR5J7BAMyeJOTVYPWD5gUtwj5 KR5wtHMLbjgyk8+rcMMXwVIsx7NH3drEHkKhTO/tz8kuqDUxkV6pdZNSLj5Y5PRv vwgd0KQdvkE2s7cqHvfcTSrVxgh7wpYCmZ2/SiDTDhYXkaSAE3szAqLhrtW1It9f 61ePhMfkZIz8B5U8Y2DWZecE1aMZqvrtSSKDZlQ38+msDEwn2noprbiPBXyzSjJ4 wQ3pi5P/kfR1pTq9ESUX7IUgo9f9TfOawLOR6baF3oulbgUjOxce0HSCO8yo9wJi SURkDNoRLPLjR0zOPb4d =BVTb -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] in-kernel structured logging
On Thu, Jul 30, 2015 at 12:16:03PM -0400, Anne Mulhern wrote: > Hi! > > This is really closely related to my previous question re. formalizing an API. > > In the design document > (https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs) > there is a statement about a future intention to support "in-kernel > structured logging". > > Are things like dev_printk() considered to have achieved that, or is > something more planned for the future? One thing is the basic support for structured logs, which was implemented, another is patching all the places which produce logs to attach useful metadata. This is only partially done. If you look at kernel logs from a boot, even basic things like the priority are set semi-randomly. So from the kernel the state could be described as POC. From systemd side, we have the fields, but we don't do interesting things with them. One problem is that the kernel gives us tags like _KERNEL_DEVICE=+scsi:8:0:3:0 which are dynamic, and change between boots. For the logs to be useful, we would have to map those to some static identifiers. It would be nice to tell journalctl "give me all logs about /dev/sda", but we're not there yet. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Thu, 30 Jul 2015 14:51:44 +0200 Michał Zegan пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Actually when I have sent the question I had systemd-222. > now it is 223 and result is the same. > Unit file is at http://webczatnet.pl/webczat/appserver.service > By default systemd also sends SIGHUP right away; how your service reacts to it? You can enable systemd debugging (/bin/kill -RTMIN+22 1), stop service and look at logs or post here. P.S. KillSignal=SIGTERM is default and redundant > W dniu 2015-07-30 o 05:36, Andrei Borzenkov pisze: > > В Wed, 29 Jul 2015 21:17:18 +0200 Michał Zegan > > пишет: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > > >> Hello. > > > >> I am trying to use systemd to run wildfly application server. It > >> is being run by a shell script that runs a java vm in a separate > >> process. So, killing the script does not kill the other process. > >> The service is a simple type service, and I am wondering what > >> happens there on stop. when the server receives signal sigint or > >> sigterm directly it logs some messages about it being stopped. > >> However, when I start it and then stop, this does not happen, i > >> get no message as if it was killed by sigkill. What may happen? > >> the documentation says that the systemd sends sigterm to all > >> processes by default (if KillMode=control-group and this is > >> probably default), and then sigkill if processes do not respond > >> for a configured amount of time. In this case sigterm sent to the > >> shell script (the main process) causes it to exit, but then > >> appserver is probably sigkilled. I know that setting sendSIGKILL > >> to no makes it shudown normally. What is going on? > > > > Could you post your unit file and which version of systemd? > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVuh3eAAoJEHb1CzgxXKwY1fIQAJKIxvtH1+9c00osb86JCR0z > uTmj1vfrNCgrwNTAHcMlopAnVwFauyBuMP79/R5All0m8iZZpnQKhjUSz7h0Sl0Q > IWVMlRtbZyqIjkwF4FTM1OkvqSkhuOmsXviqvfJtpAjuyAxfOcLJAQohnhA62jwA > JqlNKUmSlKocwmAH3IIc3TxZn6NnDo0jBCZ8QkOQisCycpcShTMPyCbwUvShemj8 > gLpBkOUkPVCjGZV3GFNBoN5rEvLjZtMVVB8+DzeM5NU5B9bodCuMJ8e4GKmuJh+V > yCaS/XG7WCSZrq2C1VSBjQYipZYpgBUee2Dhg5m3xRV3TvhhgPFIwaOaw6OApqeY > 8zXEwniP14LLiFcSbWW4sZmfwR3ZjFH3o+bQWK0ROBDzFn99iI+L3Tx83H6wDFxh > 0j9OlQpCIodtJZ2yU8FybZ6tMdR/NRQCbYogI94QUEGfhXuKFdL4Od3RbmvB6dOy > USvWfQFXVZe3TQ6tal8544QQ+CX5OQpbye3npihlk9qSkiGIhNvAhAr/DZwRz/uO > MQdeHfddje1D0cDx0Wvu4BjJTCLQEOUz2K9YbYNM9Qx7JAuQDCQxfsqoz4m8mhPp > Nh7MKjPvHpVvCaCluQOuCrOKI79hi2Owq7imWxrqBanEuG84AM3PVJKQCURYS06M > BIKXEd/KN2sPj/cl3sYE > =JhUy > -END PGP SIGNATURE- > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlW6T4UACgkQR6LMutpd94xHNACeOeApGc3kFQJEKocW42iVZaUA O0gAoKNEiP+6Rd6IOnigeMH/2vei71bX =c0jF -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] in-kernel structured logging
Hi! This is really closely related to my previous question re. formalizing an API. In the design document (https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs) there is a statement about a future intention to support "in-kernel structured logging". Are things like dev_printk() considered to have achieved that, or is something more planned for the future? Thanks again, - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looking for experiences formalizing an API for journal messages
On Thu, Jul 30, 2015 at 10:56:42AM -0400, Anne Mulhern wrote: > > On Wed, Jul 29, 2015 at 03:02:26PM -0400, Anne Mulhern wrote: > > > What I'm wondering about is the existence of some processes (not systemd), > > > that have an > > > agreement on a set of key-value pairs that they communicate with through > > > the journal. > > > > There was work done on converting abrt to use the journal. We extended > > our set of metadata fields for coredumps which were already used internally > > by coredumpctl (see > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=3f132692e3). > > I think this work is not finished yet, because of some issues that abrt > > would have to copy the coredump file (?), but abrt is becoming an external > > consumer. > > Thanks! That's a helpful datapoint. > > > fail2ban has a "systemd" backend which uses the journal. It uses the > > python API for journal to add matches (the mechanism is general and > > the matches themselves are specified by filters). This is the same > > functionality > > that journalctl uses. > > I did take a look at fail2ban. I didn't study it in depth, but it looks > like it processes journal entries into a different format and then does > regular expression matching on the result. So it didn't really feel like > a good example for what I had in mind. It seems to have (https://github.com/fail2ban/fail2ban/blob/HEAD/fail2ban/protocol.py) ["set addjournalmatch ", "adds to the journal filter of "], so it looks like it is at least possible. I don't know if it is used. > I've been exercising the systemd-python package a little and AFAICT it's > a pretty straightforward mapping onto the journal C API, with a few extra > bits from the journalctl front-end thrown in for convenience. That's a valid description. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looking for experiences formalizing an API for journal messages
- Original Message - > From: "Zbigniew Jędrzejewski-Szmek" > To: "Anne Mulhern" > Cc: systemd-devel@lists.freedesktop.org > Sent: Thursday, July 30, 2015 10:01:54 AM > Subject: Re: [systemd-devel] Looking for experiences formalizing an API for > journal messages > > On Wed, Jul 29, 2015 at 03:02:26PM -0400, Anne Mulhern wrote: > > What I'm wondering about is the existence of some processes (not systemd), > > that have an > > agreement on a set of key-value pairs that they communicate with through > > the journal. > > There was work done on converting abrt to use the journal. We extended > our set of metadata fields for coredumps which were already used internally > by coredumpctl (see > http://cgit.freedesktop.org/systemd/systemd/commit/?id=3f132692e3). > I think this work is not finished yet, because of some issues that abrt > would have to copy the coredump file (?), but abrt is becoming an external > consumer. Thanks! That's a helpful datapoint. > fail2ban has a "systemd" backend which uses the journal. It uses the > python API for journal to add matches (the mechanism is general and > the matches themselves are specified by filters). This is the same > functionality > that journalctl uses. I did take a look at fail2ban. I didn't study it in depth, but it looks like it processes journal entries into a different format and then does regular expression matching on the result. So it didn't really feel like a good example for what I had in mind. I've been exercising the systemd-python package a little and AFAICT it's a pretty straightforward mapping onto the journal C API, with a few extra bits from the journalctl front-end thrown in for convenience. > > HTH, > Zbyszek > - mulhern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.conf 2015 Announcement and CfP
On 07/30/2015 03:53 PM, Umut Tezduyar Lindskog wrote: > Fantastic! Tried to purchase a ticket but seems like PayPal is the > only supported payment. Is this a glitch? For now, only going with PayPal as checkout option was the easiest way of get the sale going. If that turns out to be a major problem for potential attendees, we need to think about alternatives. Please let us know. Note that PayPal should also work as credit card provider directly, without an account. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looking for experiences formalizing an API for journal messages
On Wed, Jul 29, 2015 at 03:02:26PM -0400, Anne Mulhern wrote: > What I'm wondering about is the existence of some processes (not systemd), > that have an > agreement on a set of key-value pairs that they communicate with through the > journal. There was work done on converting abrt to use the journal. We extended our set of metadata fields for coredumps which were already used internally by coredumpctl (see http://cgit.freedesktop.org/systemd/systemd/commit/?id=3f132692e3). I think this work is not finished yet, because of some issues that abrt would have to copy the coredump file (?), but abrt is becoming an external consumer. fail2ban has a "systemd" backend which uses the journal. It uses the python API for journal to add matches (the mechanism is general and the matches themselves are specified by filters). This is the same functionality that journalctl uses. HTH, Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.conf 2015 Announcement and CfP
Fantastic! Tried to purchase a ticket but seems like PayPal is the only supported payment. Is this a glitch? Umut On Wed, Jul 29, 2015 at 5:55 PM, Lennart Poettering wrote: > Heya! > > The first systemd conference, systemd.conf, will take place on > November 5th-7th, 2015 at betahaus in Berlin-Kreuzberg, Germany. The > systemd project is one of the core components of most of today’s Linux > distributions. At systemd.conf 2015 we will discuss the state and > future of the Linux core platform and plumbing. The intended audience > of the conference are developers, distribution packagers as well as > devops professionals. The conference will consist of presentations as > well as an extended hackfest. > > → https://systemd.events/ > > Please Register for the Conference! > > Only a limited number of tickets are available. If you plan on > attending the conference, please sign up soon. If you sign up > before August 16th, 2015, there’s an early-bird discount. A ticket > is required to attend the conference. Tickets are on sale at: > > → https://systemd.events/systemdconf-2015/registration > > Call for Presentations > > We’d like to invite presentation proposals for systemd.conf > 2015. We are looking for talks including, but not limited to the > following topics: > > - Use Cases: systemd in today’s and tomorrow’s devices and applications, > - systemd and containers, in the cloud and on servers, > - systemd in distributions, > - Embedded systemd, > - systemd on the desktop, > - Networking with systemd, > - D-Bus and kdbus IPC systems, > - … and everything else related to systemd. > > Please submit your session proposals by August 31st, 2015 at: > > → https://systemd.events/systemdconf-2015/add/session > > We will notify submitters about proposal acceptance by > September 15th, 2015. > > We will only accept presentations in English. > > More information about the CfP you may find on: > > → https://systemd.events/systemdconf-2015/call-presentations > > Contact Us > > If you wish to receive more information as it becomes available, > follow us at +systemd on Google+. If you have any questions > please send us an email to info@systemd.events. > > For more information about systemd, please consult: > > → https://wiki.freedesktop.org/www/Software/systemd/ > > For more information about systemd.conf 2015, please consult: > > → https://systemd.events/ > > Partners and Sponsoring > > systemd.conf 2015 is a cooperation of the systemd community and > LinuxTag e. V. as organizing host. > > We are seeking corporate partners to help us create the best > conference possible. Please visit > https://systemd.events/systemdconf-2015/become-sponsor for more > information on sponsoring systemd.conf 2015. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > 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] Looking for experiences formalizing an API for journal messages
On Wed, 29.07.15 15:02, Anne Mulhern (amulh...@redhat.com) wrote: > > systemd of courses uses its on its own, and we tried to document > > the fields we use in systemd.journal-fields(7), though it might be > > slightly incomplete. > > > > But yes, this is indeed API, and deserves complete documentation, like > > any C API, any D-Bus API or a any REST API would need too. > > > > Lennart > > > > -- > > Lennart Poettering, Red Hat > > > > What I'm wondering about is the existence of some processes (not systemd), > that have an > agreement on a set of key-value pairs that they communicate with > through the journal. There are multiple bindings for the journal logging API on github for various languages. It might be worth searching for users of these APIs, as well as our C API. libvirt talks the journal logging protocol natively btw, it might be a codebase to check for this. > It seems like, even though there is a mechanism for adding additional > key/value pairs, > regular expression matching is still kind of the norm. Well, yes, regexp searching is definitely more popular. But do note that the journal will implicitly append a big number of structured fields, such as user, process, MAC, unit information, so each record will have a good number of metadata fields already without clients sending the metadata themselves. 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] Configurability for systemd logging API
On Thu, 30.07.15 08:16, SF Markus Elfring (elfr...@users.sourceforge.net) wrote: > >> Such messages correspond to specific data structures. > >> * The log origin and log level are repeated there while the recorded > >> information might occasionally not be detailed enough. > >> I find that such details can be better handled by the software build > >> system. > … > > I appreciate you wanting to help, but this is not helpful. > > Thanks for your feedback. > > > > Please post patches if you have suggestions for improvements. > > I find that the change acceptance is unclear for fine-tuning of this software > also around message log programming interfaces. > Which design approaches do you find acceptable for further considerations? I am sorry, I am sure you are trying to be helpful, but at this point this is just not funny anymore, you are just raising the noise level, stealing our time. You are now on moderation. Sorry for having to do that. But even though we asked you to provide explicit patches or explicit bug reports you keep contributing only vague noise, and that's just time consuming to deal with. Sorry, Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Nagios service fails
On Thu, Jul 30, 2015 at 4:20 PM, Sakhi Hadebe wrote: > > Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: ***> One or more > problems was encountered while processing the config files... > That sounds like a nagios problem? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Nagios service fails
Hi, I have just installed the latest nagios mointoring server on debian 8.1 (jessie). When trying to restart the nagios service, it fails, see the error below: [] Starting nagios (via systemctl): nagios.serviceJob for nagios.service failed. See 'systemctl status nagios.service' and 'journalctl -xn' for details. failed! and there is detailed info from executing the command below: monitor:/usr/local/nagios/etc# journalctl -xn -- Logs begin at Thu 2015-07-30 10:48:19 SAST, end at Thu 2015-07-30 15:13:30 SAST. -- Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: ***> One or more problems was encountered while processing the config files... Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: Check your configuration file(s) to ensure that they contain valid Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: directives and data defintions. If you are upgrading from a previous Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: version of Nagios, you should be aware that some variables/definitions Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: may have been removed or modified in this version. Make sure to read Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: the HTML documentation regarding the config files, as well as the Jul 30 15:13:30 monitor.sanren.ac.za nagios[32281]: 'Whats New' section to find out what has changed. Jul 30 15:13:30 monitor.sanren.ac.za systemd[1]: nagios.service: control process exited, code=exited status=8 Jul 30 15:13:30 monitor.sanren.ac.za systemd[1]: Failed to start LSB: Starts and stops the Nagios monitoring server. -- Subject: Unit nagios.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit nagios.service has failed. -- -- The result is failed. Jul 30 15:13:30 monitor.sanren.ac.za systemd[1]: Unit nagios.service entered failed state. Any help to get through will be appreciated. Thank you. -- Regards, Sakhi Hadebe Engineer: South African National Research Network (SANReN)Competency Area, Meraka, CSIR Tel: +27 12 841 2308 <+27128414213> Fax: +27 12 841 4223 <+27128414223> Cell: +27 71 331 9622 <+27823034657> Email: sa...@sanren.ac.za ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] behavior of stop in case of multiple processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually when I have sent the question I had systemd-222. now it is 223 and result is the same. Unit file is at http://webczatnet.pl/webczat/appserver.service W dniu 2015-07-30 o 05:36, Andrei Borzenkov pisze: > В Wed, 29 Jul 2015 21:17:18 +0200 Michał Zegan > пишет: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> Hello. > >> I am trying to use systemd to run wildfly application server. It >> is being run by a shell script that runs a java vm in a separate >> process. So, killing the script does not kill the other process. >> The service is a simple type service, and I am wondering what >> happens there on stop. when the server receives signal sigint or >> sigterm directly it logs some messages about it being stopped. >> However, when I start it and then stop, this does not happen, i >> get no message as if it was killed by sigkill. What may happen? >> the documentation says that the systemd sends sigterm to all >> processes by default (if KillMode=control-group and this is >> probably default), and then sigkill if processes do not respond >> for a configured amount of time. In this case sigterm sent to the >> shell script (the main process) causes it to exit, but then >> appserver is probably sigkilled. I know that setting sendSIGKILL >> to no makes it shudown normally. What is going on? > > Could you post your unit file and which version of systemd? > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVuh3eAAoJEHb1CzgxXKwY1fIQAJKIxvtH1+9c00osb86JCR0z uTmj1vfrNCgrwNTAHcMlopAnVwFauyBuMP79/R5All0m8iZZpnQKhjUSz7h0Sl0Q IWVMlRtbZyqIjkwF4FTM1OkvqSkhuOmsXviqvfJtpAjuyAxfOcLJAQohnhA62jwA JqlNKUmSlKocwmAH3IIc3TxZn6NnDo0jBCZ8QkOQisCycpcShTMPyCbwUvShemj8 gLpBkOUkPVCjGZV3GFNBoN5rEvLjZtMVVB8+DzeM5NU5B9bodCuMJ8e4GKmuJh+V yCaS/XG7WCSZrq2C1VSBjQYipZYpgBUee2Dhg5m3xRV3TvhhgPFIwaOaw6OApqeY 8zXEwniP14LLiFcSbWW4sZmfwR3ZjFH3o+bQWK0ROBDzFn99iI+L3Tx83H6wDFxh 0j9OlQpCIodtJZ2yU8FybZ6tMdR/NRQCbYogI94QUEGfhXuKFdL4Od3RbmvB6dOy USvWfQFXVZe3TQ6tal8544QQ+CX5OQpbye3npihlk9qSkiGIhNvAhAr/DZwRz/uO MQdeHfddje1D0cDx0Wvu4BjJTCLQEOUz2K9YbYNM9Qx7JAuQDCQxfsqoz4m8mhPp Nh7MKjPvHpVvCaCluQOuCrOKI79hi2Owq7imWxrqBanEuG84AM3PVJKQCURYS06M BIKXEd/KN2sPj/cl3sYE =JhUy -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configurability for systemd logging API
>> I find that the change acceptance is unclear for fine-tuning of this software >> also around message log programming interfaces. >> Which design approaches do you find acceptable for further considerations? > > Sorry, I really can't follow. How do you generally think about any further fine-tuning of function calls for logging purposes? > If you post a patch we can take it from there. My suggestion is not ready yet to be transformed into this format. Would it make sense to extend logging parameters for the software build system? Which extensions can be integrated into a build script like "configure.ac"? Regards, Markus ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configurability for systemd logging API
On Thu, Jul 30, 2015 at 8:16 AM, SF Markus Elfring wrote: >>> Such messages correspond to specific data structures. >>> * The log origin and log level are repeated there while the recorded >>> information might occasionally not be detailed enough. >>> I find that such details can be better handled by the software build >>> system. > … >> I appreciate you wanting to help, but this is not helpful. > > Thanks for your feedback. > > >> Please post patches if you have suggestions for improvements. > > I find that the change acceptance is unclear for fine-tuning of this software > also around message log programming interfaces. > Which design approaches do you find acceptable for further considerations? Sorry, I really can't follow. If you post a patch we can take it from there. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
