Re: [systemd-devel] Adding a Timer section to .service files
systemctl start foo.service systemctl enable foo.service systemd tools must be modified/adjusted too On Fri, Jul 8, 2016 at 8:08 AM, Mantas Mikulėnas wrote: > On Fri, Jul 8, 2016 at 7:52 AM, One Infinite Loop <6po...@gmail.com> > wrote: > >> Instead of having a .service file and a .timer file why not having a >> [Timer] section inside a .service file? It would be much more manageable as >> one file. >> > > More manageable? How would you actually activate/deactivate it without > being able to 'systemctl start foo.timer'? > > -- > Mantas Mikulėnas > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding a Timer section to .service files
On Fri, Jul 8, 2016 at 7:52 AM, One Infinite Loop <6po...@gmail.com> wrote: > Instead of having a .service file and a .timer file why not having a > [Timer] section inside a .service file? It would be much more manageable as > one file. > More manageable? How would you actually activate/deactivate it without being able to 'systemctl start foo.timer'? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Adding a Timer section to .service files
Instead of having a .service file and a .timer file why not having a [Timer] section inside a .service file? It would be much more manageable as one file. Of course, if there are users who prefer having .timer files, .timer files will continue to exist. I use systemd 229. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
Hi Andrei, That worked, thank you so much! Here is the final of the hello-phoenix.service: [Unit] Description=hello-phoenix service [Service] WorkingDirectory=/home/hello-phoenix/app/bin ExecStart=/home/hello-phoenix/app/bin/hello_phoenix foreground Environment=MIX_ENV=prod PORT= Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=hello-phoenix User=hello-phoenix [Install] WantedBy=multi-user.target Thank you and everyone for your insights:) Cheers, Michael Sincerely, Michael Chavez, Web Developer Space-Rocket | web and graphic design M: 415-724-7935 W: http://www.space-rocket.com/ On Thu, Jul 7, 2016 at 8:36 AM, Andrei Dziahel wrote: > Hi Michael, > > How did you get this /home/hello-phoenix/app/bin/hello_phoenix script > anyway? If it is generated by exrm, I'd suggest to try "hello_phoenix > foreground" in ExecStart directive — it'd prevent forking and detaching > from console (it is unnecessary if being supervised by systemd). > > 2016-07-07 17:29 GMT+03:00 Michael Chavez : > >> Hello, >> >> I am a newbie trying to get systemd to load my phoenix/elixir app. >> >> I have tried many variations of my hello-phoenix service file, the >> version that I feel is closest to being correct looks like this: >> [Unit] >> Description=hello-phoenix service >> >> [Service] >> WorkingDirectory=/home/hello-phoenix/app/bin >> ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start >> Environment=MIX_ENV=prod PORT= >> Restart=always >> StandardOutput=syslog >> StandardError=syslog >> SyslogIdentifier=hello-phoenix >> User=hello-phoenix >> >> [Install] >> WantedBy=multi-user.target >> >> after reloading daemon, enabling and starting the hello-phoenix.service, >> systemctl status hello-phoenix.service outputs: >> >> ● hello-phoenix.service - hello-phoenix service >>Loaded: loaded (/etc/systemd/system/hello-phoenix.service; enabled) >>Active: failed (Result: start-limit) since Thu 2016-07-07 10:14:30 >> EDT; 9min ago >> Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start >> (code=exited, status=0/SUCCESS) >> Main PID: 4281 (code=exited, status=0/SUCCESS) >> >> Jul 07 10:14:30 Phoenix1 systemd[1]: hello-phoenix.service start request >> repeated too quickly, refusing to start. >> Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix >> service. >> Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered >> failed state. >> Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request >> repeated too quickly, refusing to start. >> Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix >> service. >> >> and journalctl -xn outputs: >> -- Logs begin at Wed 2016-07-06 16:21:33 EDT, end at Thu 2016-07-07 >> 10:17:01 EDT. -- >> Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix >> service. >> -- Subject: Unit hello-phoenix.service has failed >> -- Defined-By: systemd >> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> -- >> -- Unit hello-phoenix.service has failed. >> -- >> -- The result is failed. >> Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered >> failed state. >> Jul 07 10:14:33 Phoenix1 sudo[4319]: root : TTY=pts/2 ; PWD=/root ; >> USER=root ; COMMAND=/bin/systemctl start hello-phoenix.service >> Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session >> opened for user root by root(uid=0) >> Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request >> repeated too quickly, refusing to start. >> Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix >> service. >> -- Subject: Unit hello-phoenix.service has failed >> -- Defined-By: systemd >> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> -- >> -- Unit hello-phoenix.service has failed. >> -- >> -- The result is failed. >> Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session >> closed for user root >> Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session >> opened for user root by (uid=0) >> Jul 07 10:17:01 Phoenix1 CRON[4343]: (root) CMD ( cd / && run-parts >> --report /etc/cron.hourly) >> Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session >> closed for user root >> >> Anybody have any ideas on what I am doing wrong? I am on day two of >> ramming my head against the wall trying to figure out. Any help would >> greatly appreciated. >> >> Thanks and Cheers, >> Michael >> >> Sincerely, >> Michael Chavez, Web Developer >> Space-Rocket | web and graphic design >> >> M: 415-724-7935 >> >> W: http://www.space-rocket.com/ >> >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >> > > > -- > Regards, > Andrei Dziahel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedes
Re: [systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
Hi Michael, How did you get this /home/hello-phoenix/app/bin/hello_phoenix script anyway? If it is generated by exrm, I'd suggest to try "hello_phoenix foreground" in ExecStart directive — it'd prevent forking and detaching from console (it is unnecessary if being supervised by systemd). 2016-07-07 17:29 GMT+03:00 Michael Chavez : > Hello, > > I am a newbie trying to get systemd to load my phoenix/elixir app. > > I have tried many variations of my hello-phoenix service file, the version > that I feel is closest to being correct looks like this: > [Unit] > Description=hello-phoenix service > > [Service] > WorkingDirectory=/home/hello-phoenix/app/bin > ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start > Environment=MIX_ENV=prod PORT= > Restart=always > StandardOutput=syslog > StandardError=syslog > SyslogIdentifier=hello-phoenix > User=hello-phoenix > > [Install] > WantedBy=multi-user.target > > after reloading daemon, enabling and starting the hello-phoenix.service, > systemctl status hello-phoenix.service outputs: > > ● hello-phoenix.service - hello-phoenix service >Loaded: loaded (/etc/systemd/system/hello-phoenix.service; enabled) >Active: failed (Result: start-limit) since Thu 2016-07-07 10:14:30 EDT; > 9min ago > Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start > (code=exited, status=0/SUCCESS) > Main PID: 4281 (code=exited, status=0/SUCCESS) > > Jul 07 10:14:30 Phoenix1 systemd[1]: hello-phoenix.service start request > repeated too quickly, refusing to start. > Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix service. > Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered > failed state. > Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request > repeated too quickly, refusing to start. > Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix service. > > and journalctl -xn outputs: > -- Logs begin at Wed 2016-07-06 16:21:33 EDT, end at Thu 2016-07-07 > 10:17:01 EDT. -- > Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix service. > -- Subject: Unit hello-phoenix.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit hello-phoenix.service has failed. > -- > -- The result is failed. > Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered > failed state. > Jul 07 10:14:33 Phoenix1 sudo[4319]: root : TTY=pts/2 ; PWD=/root ; > USER=root ; COMMAND=/bin/systemctl start hello-phoenix.service > Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session > opened for user root by root(uid=0) > Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request > repeated too quickly, refusing to start. > Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix service. > -- Subject: Unit hello-phoenix.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit hello-phoenix.service has failed. > -- > -- The result is failed. > Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session > closed for user root > Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session > opened for user root by (uid=0) > Jul 07 10:17:01 Phoenix1 CRON[4343]: (root) CMD ( cd / && run-parts > --report /etc/cron.hourly) > Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session > closed for user root > > Anybody have any ideas on what I am doing wrong? I am on day two of > ramming my head against the wall trying to figure out. Any help would > greatly appreciated. > > Thanks and Cheers, > Michael > > Sincerely, > Michael Chavez, Web Developer > Space-Rocket | web and graphic design > > M: 415-724-7935 > > W: http://www.space-rocket.com/ > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > > -- Regards, Andrei Dziahel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
On Thu, Jul 07, 2016 at 07:29:20AM -0700, Michael Chavez wrote: > Hello, > > I am a newbie trying to get systemd to load my phoenix/elixir app. > > I have tried many variations of my hello-phoenix service file, the version > that I feel is closest to being correct looks like this: > > [Service] > WorkingDirectory=/home/hello-phoenix/app/bin > ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start > Environment=MIX_ENV=prod PORT= > Restart=always > StandardOutput=syslog > StandardError=syslog > SyslogIdentifier=hello-phoenix > User=hello-phoenix > > after reloading daemon, enabling and starting the hello-phoenix.service, > systemctl status hello-phoenix.service outputs: > > ● hello-phoenix.service - hello-phoenix service >Loaded: loaded (/etc/systemd/system/hello-phoenix.service; enabled) >Active: failed (Result: start-limit) since Thu 2016-07-07 10:14:30 EDT; > 9min ago > Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start > (code=exited, status=0/SUCCESS) > Main PID: 4281 (code=exited, status=0/SUCCESS) > Does it fork? If so, you need Type=forking in you [Service] section (default is Type=simple, e.g. application running in foreground). See https://enotty.pipebreaker.pl/2014/10/08/failure-modes-of-incorrect-type-in-systemd-units/ for longer explanation. -- Tomasz Torcz"Funeral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
Thanks for the reply. I added "Type=forking" and still get same results: ● hello-phoenix.service - hello-phoenix service Loaded: loaded (/etc/systemd/system/hello-phoenix.service; enabled) Active: failed (Result: start-limit) since Thu 2016-07-07 10:59:25 EDT; 23s ago Process: 7139 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start (code=exited, status=0/SUCCESS) Main PID: 7174 (code=exited, status=0/SUCCESS) Jul 07 10:59:25 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:59:25 Phoenix1 systemd[1]: Failed to start hello-phoenix service. Jul 07 10:59:25 Phoenix1 systemd[1]: Unit hello-phoenix.service entered failed state. Jul 07 10:59:27 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:59:27 Phoenix1 systemd[1]: Failed to start hello-phoenix service. root@Phoenix1:~# journalctl -xn -- Logs begin at Wed 2016-07-06 16:21:33 EDT, end at Thu 2016-07-07 10:59:27 EDT. -- Jul 07 10:59:24 Phoenix1 sudo[6984]: pam_unix(sudo:session): session opened for user root by root(uid=0) Jul 07 10:59:24 Phoenix1 sudo[6984]: pam_unix(sudo:session): session closed for user root Jul 07 10:59:25 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:59:25 Phoenix1 systemd[1]: Failed to start hello-phoenix service. -- Subject: Unit hello-phoenix.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit hello-phoenix.service has failed. -- -- The result is failed. Jul 07 10:59:25 Phoenix1 systemd[1]: Unit hello-phoenix.service entered failed state. Jul 07 10:59:27 Phoenix1 sudo[7177]: root : TTY=pts/2 ; PWD=/root ; USER=root ; COMMAND=/bin/systemctl start hello-phoenix.service Jul 07 10:59:27 Phoenix1 sudo[7177]: pam_unix(sudo:session): session opened for user root by root(uid=0) Jul 07 10:59:27 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:59:27 Phoenix1 systemd[1]: Failed to start hello-phoenix service. -- Subject: Unit hello-phoenix.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit hello-phoenix.service has failed. -- -- The result is failed. Jul 07 10:59:27 Phoenix1 sudo[7177]: pam_unix(sudo:session): session closed for user root root@Phoenix1:~# Sincerely, Michael Chavez, Web Developer Space-Rocket | web and graphic design M: 415-724-7935 W: http://www.space-rocket.com/ On Thu, Jul 7, 2016 at 7:48 AM, Mantas Mikulėnas wrote: > > Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start > (code=exited, status=0/SUCCESS) > > If it's a 'daemon', use Type=forking. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
> Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start (code=exited, status=0/SUCCESS) If it's a 'daemon', use Type=forking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unable to get Systemd to work with Phoenix/Elixir Exrm Release
Hello, I am a newbie trying to get systemd to load my phoenix/elixir app. I have tried many variations of my hello-phoenix service file, the version that I feel is closest to being correct looks like this: [Unit] Description=hello-phoenix service [Service] WorkingDirectory=/home/hello-phoenix/app/bin ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start Environment=MIX_ENV=prod PORT= Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=hello-phoenix User=hello-phoenix [Install] WantedBy=multi-user.target after reloading daemon, enabling and starting the hello-phoenix.service, systemctl status hello-phoenix.service outputs: ● hello-phoenix.service - hello-phoenix service Loaded: loaded (/etc/systemd/system/hello-phoenix.service; enabled) Active: failed (Result: start-limit) since Thu 2016-07-07 10:14:30 EDT; 9min ago Process: 4281 ExecStart=/home/hello-phoenix/app/bin/hello_phoenix start (code=exited, status=0/SUCCESS) Main PID: 4281 (code=exited, status=0/SUCCESS) Jul 07 10:14:30 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix service. Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered failed state. Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix service. and journalctl -xn outputs: -- Logs begin at Wed 2016-07-06 16:21:33 EDT, end at Thu 2016-07-07 10:17:01 EDT. -- Jul 07 10:14:30 Phoenix1 systemd[1]: Failed to start hello-phoenix service. -- Subject: Unit hello-phoenix.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit hello-phoenix.service has failed. -- -- The result is failed. Jul 07 10:14:30 Phoenix1 systemd[1]: Unit hello-phoenix.service entered failed state. Jul 07 10:14:33 Phoenix1 sudo[4319]: root : TTY=pts/2 ; PWD=/root ; USER=root ; COMMAND=/bin/systemctl start hello-phoenix.service Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session opened for user root by root(uid=0) Jul 07 10:14:33 Phoenix1 systemd[1]: hello-phoenix.service start request repeated too quickly, refusing to start. Jul 07 10:14:33 Phoenix1 systemd[1]: Failed to start hello-phoenix service. -- Subject: Unit hello-phoenix.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit hello-phoenix.service has failed. -- -- The result is failed. Jul 07 10:14:33 Phoenix1 sudo[4319]: pam_unix(sudo:session): session closed for user root Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session opened for user root by (uid=0) Jul 07 10:17:01 Phoenix1 CRON[4343]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jul 07 10:17:01 Phoenix1 CRON[4342]: pam_unix(cron:session): session closed for user root Anybody have any ideas on what I am doing wrong? I am on day two of ramming my head against the wall trying to figure out. Any help would greatly appreciated. Thanks and Cheers, Michael Sincerely, Michael Chavez, Web Developer Space-Rocket | web and graphic design M: 415-724-7935 W: http://www.space-rocket.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
Andrei Borzenkov [2016-07-07 11:39 +0300]: > Do not we already have "session" concept in logind? Is not session > already stopped when user logs out? Yes, but user systemd units don't "see" the system logind scopes, so you can't relate to them. And the user systemd instance continues to run after you log out of the graphical session, as long as that user still has some other (non-graphical) session open. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
On Thu, Jul 7, 2016 at 11:27 AM, Martin Pitt wrote: > Zbigniew Jędrzejewski-Szmek [2016-07-04 22:20 +]: >> I think we should instead enhance target units to provide missing >> functionality. The most important thing would be to have something >> like PartOf, but more nicely configured. PartOf=graphical-kde.target >> would do the trick, but it would need to be configured in each >> unit separately, which would mean that we'd need to duplicate each >> unit for each target, which is unacceptable. I don't see a nice >> way to achieve this with the current set of options. What about >> adding DependenciesPartOf=yes|no on the target unit, with "yes" >> meaning that we automatically add PartOf= dependencies to any service >> which has a Wants= or Requires= dependency to the target. > > This would still not be sufficient, AFAICS. The top-level targets will > only have relatively few direct dependencies. Let's suppose > gnome-session.target has > "Requires=mutter.service gnome-settings-daemon.service" > and mutter.service then has a "Wants=at-spi2.service". We still want > to stop at-spi2.service together with the session. > > DependenciesPartOf=yes in gnome.target would not achieve that (or it > would need to apply transitively, and to Wants= as well, which sounds > quite strange). OTOH adding "PartOf=graphical-session.target" to all > graphical session specific user services works fine and works with the > existing systemd model and dependencies. > Do not we already have "session" concept in logind? Is not session already stopped when user logs out? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
Zbigniew Jędrzejewski-Szmek [2016-07-04 22:20 +]: > I think we should instead enhance target units to provide missing > functionality. The most important thing would be to have something > like PartOf, but more nicely configured. PartOf=graphical-kde.target > would do the trick, but it would need to be configured in each > unit separately, which would mean that we'd need to duplicate each > unit for each target, which is unacceptable. I don't see a nice > way to achieve this with the current set of options. What about > adding DependenciesPartOf=yes|no on the target unit, with "yes" > meaning that we automatically add PartOf= dependencies to any service > which has a Wants= or Requires= dependency to the target. This would still not be sufficient, AFAICS. The top-level targets will only have relatively few direct dependencies. Let's suppose gnome-session.target has "Requires=mutter.service gnome-settings-daemon.service" and mutter.service then has a "Wants=at-spi2.service". We still want to stop at-spi2.service together with the session. DependenciesPartOf=yes in gnome.target would not achieve that (or it would need to apply transitively, and to Wants= as well, which sounds quite strange). OTOH adding "PartOf=graphical-session.target" to all graphical session specific user services works fine and works with the existing systemd model and dependencies. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
Martin Pitt [2016-07-07 9:29 +0200]: > I'll go ahead and create a PR with the unit and a manpage, using > graphical-session.target for now. Then the name bikeshedding can be > continued there. https://github.com/systemd/systemd/pull/3678 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Standardizing names for graphical session units
Hello Jóhann, Jóhann B. Guðmundsson [2016-07-06 16:22 +]: > It's more about people will be have hard time distinguish between two or > more type units with the same name but serve two different purposes. I was thinking graphical.target would be nicely symmetrical to the system-level one, but there's the confusion potential, yes. So if we call the "real" sessions like gnome-session.target, then IMHO that generic "alias" target should have the same form; graphical-session.target would be reasonable. > One way to solve them is with type target units as you proposed ( > user-graphical.target could serve that purpose ) but back in the day Lennart > was against introducing generic type targets like webserver.target, > database.target etc Oh, I wasn't aware of this. I guess we'll let him have the last word about that then? :-) I'll go ahead and create a PR with the unit and a manpage, using graphical-session.target for now. Then the name bikeshedding can be continued there. BTW, I updated http://people.canonical.com/~pitti/tmp/session.sh to have a kde.target as well, to demonstrate that this works with two independent sessions. Thanks everyone for their input! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
