Re: [systemd-devel] logind, su - sessions and initscripts compatibility
On Friday, December 19, 2014 at 07:58:11 PM, Andrei Borzenkov wrote:
В Fri, 19 Dec 2014 11:16:58 -0500
wor...@alum.mit.edu (Dale R. Worley) пишет:
Simon McVittie simon.mcvit...@collabora.co.uk writes:
On 18/12/14 14:10, Dale R. Worley wrote:
Simon McVittie simon.mcvit...@collabora.co.uk writes:
On 18/12/14 08:05, Andrei Borzenkov wrote:
Any initscript that is using su - would [cause badness]
Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?
More to the point, why would an initscript do that, since it's *already*
running as root?
su isn't just for becoming root; it can also cause transitions from root
to a less privileged user (su -c 'my-app-clear-cache' daemon is one
example of something that an init script might want to do).
Yeah, ack, that was my mistake. I was confusing su, su [user], and
su - [user]. But the question is about the su - [user] form, which
is basically intended to start a new login session (as far as I can see
from the man page), since it gives the user's shell a - in argv[0],
which is intended to instruct the shell to run the user's
initializations, etc.
Which means that the question I should have asked is Why would an
initscript use 'su -', as that is intended to start a new login
session?
There is not a single word about login session in su man page.
It says it starts login shell - but login session is not created by
shell so I do not see where you draw this conclusion from.
It's indirectly so.
This version of su uses PAM for authentication, account and session
management.
Maybe it's a problem of distro/integration? In current Arch, /etc/pam.d/su{,-l}
say
#%PAM-1.0
authsufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the wheel group.
#auth requiredpam_wheel.so use_uid
authrequiredpam_unix.so
account requiredpam_unix.so
session requiredpam_unix.so
, and su - my user started in systemd's debug shell seems to survive the
transition to rescue.target. Which is just as expected, because in this
configuration su does not register its sessions in logind.
(Please correct me if my analysis is wrong.)
--
Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improving module loading
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Saturday, December 20, 2014 6:11 PM To: Hoyer, Marko (ADITG/SW2) Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Improving module loading On Sat, Dec 20, 2014 at 10:45:34AM +, Hoyer, Marko (ADITG/SW2) wrote: Hi, -Original Message- From: systemd-devel [mailto:systemd-devel- boun...@lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog Sent: Tuesday, December 16, 2014 4:55 PM To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] Improving module loading Hi, Is there a reason why systemd-modules-load is loading modules sequentially? Few things can happen simultaneously like resolving the symbols etc. Seems like modules_mutex is common on module loads which gets locked up on few occasions throughout the execution of sys_init_module. We are actually doing this (in embedded systems which need to be up very fast with limited resources) and gained a lot. Mainly, IO and CPU can be better utilized by loading modules in parallel (one module is loaded while another one probes for hardware or is doing memory initialization). If you have control over your kernel, why not just build the modules into the kernel, then all of this isn't an issue at all and there is no overhead of module loading? It is a questions of kernel image size and startup performance. - We are somehow limited in terms of size from where we are loading the kernel. - Loading the image is a kind of monolithic block in terms of time where you can hardly do things in parallel - We are strongly following the idea from Umut (loading things not before they are actually needed) to get up early services very early (e.g. rendering a camera on a display in less than 2secs after power on) - Some modules do time / CPU consuming things in init(), which would delay the entry time into userspace - deferred init calls are not really a solution because they cannot be controlled in the needed granularity So finally it is actually a trade of between compiling things in and spending the overhead of module loading to gain the flexibility to load things later. greg k-h Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improving module loading
-Original Message- From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com] Sent: Saturday, December 20, 2014 6:45 PM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Improving module loading Hi Marko, Thank you very much for your feedback! You're welcome ;) On Sat, Dec 20, 2014 at 11:45 AM, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com wrote: Hi, -Original Message- From: systemd-devel [mailto:systemd-devel- boun...@lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog Sent: Tuesday, December 16, 2014 4:55 PM To: systemd-devel@lists.freedesktop.org Subject: [systemd-devel] Improving module loading Hi, Is there a reason why systemd-modules-load is loading modules sequentially? Few things can happen simultaneously like resolving the symbols etc. Seems like modules_mutex is common on module loads which gets locked up on few occasions throughout the execution of sys_init_module. We are actually doing this (in embedded systems which need to be up very fast with limited resources) and gained a lot. Mainly, IO and CPU can be better utilized by loading modules in parallel (one module is loaded while another one probes for hardware or is doing memory initialization). The other thought is, what is the preferred way of loading modules when they are needed. Do they have to be loaded on ExecStartPre= or as a separate service which has ExecStart that uses kmod to load them? Wouldn't it be useful to have something like ExecStartModule=? I had such a discussion earlier with some of the systemd guys. My intention was to introduce an additional unit for module loading for exactly the reason you mentioned. The following (reasonable) outcome was: Do you have links for the discussions, I cannot find them. Actually not, sorry. The discussion was not done via any mailing list. systemd already has a service that loads the modules. Sorry, there is a word missing in my sentence above. My idea was not to introduce a unit for modules loading but an own unit type, such as .kmodule. The idea was to define .kmodule units to load one or a set of kernel modules each at a certain point during startup by just integrating them into the startup dependency tree. This idea would require integrating kind of worker threads into systemd. The outcome was as summarized below. The advantages over systemd-modules-load are: - modules can be loaded in parallel - different sets of modules can be loaded at different points in time during startup - It is dangerous to load kernel modules from PID 1 since module loading can get stuck - Since modules are actually loaded with the thread that calls the syscall, systemd would need additional threads - Multi Threading is not really aimed in systemd for stability reasons The probably safest way to do what you intended is to use an additional process to load your modules, which could be easily done by using ExecStartPre= in a service file. We are doing it exactly this way not with kmod but with a tool that loads modules in parallel. Btw: Be careful with synchronization. We found that lots of kernel modules are exporting device nodes in the background (alsa, some graphics driver, ...). With the proceeding mentioned above, you are moving the kernel module loading and the actual use of the driver interface very close together in time. This might lead to race conditions. It is even worse when you need to access sys attributes, which are exported by some drivers even after the device is already available and uevents have been sent out. For such modules, there actually is no other way for synchronization but waiting for the attributes to appear. We are aware of the potential complications and races. But good to be reminded :) ;) We actually stumbled over lots of things here while we rolled out this approach. Sometimes it is really funny that simple questions such as What does your service actually need? are hard to answer. It seems that sometimes things are working more or less accidently due to the fact that the udev trigger comes very early compared to the startup of the services. Umut Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improving module loading
-Original Message- From: systemd-devel [mailto:systemd-devel- boun...@lists.freedesktop.org] On Behalf Of Tom Gundersen Sent: Saturday, December 20, 2014 4:57 PM To: Umut Tezduyar Cc: systemd Mailing List Subject: Re: [systemd-devel] Improving module loading On 16 Dec 2014 17:21, Umut Tezduyar Lindskog u...@tezduyar.com wrote: On Tue, Dec 16, 2014 at 4:59 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Dec 16, 2014 at 4:54 PM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: The other thought is, what is the preferred way of loading modules when they are needed. Rely on kernel autoloading. Not all modules support that yet, but most do. What do you have in mind? We have some modules that we don't need them to be loaded so early. We much prefer them to be loaded when they are needed. For example we don't need to load the SD driver module until the service that uses SD driver is starting. With this idea in mind I started some investigation. Then I realized that our CPU utilization is not that high during module loading and I blame it to the sequential loading of modules. I am thinking this can be improved on systemd-modules-load side. We can probably improve the module loading by making it use worker processes similar to how udev works. We realized it with threads, which are much cheaper for this job. In principle this could cause problems with things making assumptions on the order of module loading, so that is something to keep in mind. Mmm, I don't see any issues here since the dependencies are normally properly described on kernel side (otherwise you have a problem in any case). In worst case you are losing potential to parallelize loading of modules if your algorithm for distributing the modules to workers is not working efficiently. That said, note that most modules will be loaded by udev which already does it in parallel... ... only if you are still triggering add uevent through the complete device tree during startup, which is really expensive and does not go with the load things not before they are actually needed philosophy very well ... Do they have to be loaded on ExecStartPre= or as a separate service which has ExecStart that uses kmod to load them? Wouldn't it be useful to have something like ExecStartModule=? I'd much rather we improve the autoloading support... My understanding is autoloading support is loading a module if the hardware is available. That, or for non-hardware modules when the functionally is first used (networking, filesystems, ...). What I am after is though loading the module when they are needed. This sounds really fragile to me (having to encode this dependency everywhere rather than just always assume the functionality is available). That is actually the main challenge when this approach is applied. But the assumption you are talking about is in many cases a kind of facade only at least if your applications - are not waiting for udev to completely settle after the coldplug trigger, or - are able to deal with devices in a hotplug fashion. Cheers, Tom Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restarting service does not work
В Sun, 21 Dec 2014 13:24:16 +0100 Cecil Westerhof cldwester...@gmail.com пишет: I have a service in which I log vmstat info in a H2 database. Of-course this is only useful when H2 is actually running. So I have the following service file: [Unit] Description=Logging vmstat to H2 Database Requires=h2.service After=h2.service [Service] Type=simple ExecStart=/home/cecil/bin/vmstatLog.sh Restart=always User=cecil [Install] WantedBy=multi-user.target It works insofar that when h2 stops, vmstatLog also stops. But when h2 is started again, vmstatLog does not start and needs to be started manually. What am I doing wrong? Nothing; this is expected behavior. Dependency in systemd is unidirectional; you may want to change [Install] section to WantedBy=h2.service so that starting h2.service will also start your service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restarting service does not work
2014-12-21 14:52 GMT+01:00 Andrei Borzenkov arvidj...@gmail.com: В Sun, 21 Dec 2014 13:24:16 +0100 Cecil Westerhof cldwester...@gmail.com пишет: I have a service in which I log vmstat info in a H2 database. Of-course this is only useful when H2 is actually running. So I have the following service file: [Unit] Description=Logging vmstat to H2 Database Requires=h2.service After=h2.service [Service] Type=simple ExecStart=/home/cecil/bin/vmstatLog.sh Restart=always User=cecil [Install] WantedBy=multi-user.target It works insofar that when h2 stops, vmstatLog also stops. But when h2 is started again, vmstatLog does not start and needs to be started manually. What am I doing wrong? Nothing; this is expected behavior. Dependency in systemd is unidirectional; you may want to change [Install] section to WantedBy=h2.service so that starting h2.service will also start your service. Works likes a charm. Thanks. The name is a bit of a misnomer (vmstatLog is not wanted by h2) but I can live with that. -- Cecil Westerhof ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improving module loading
On Sunday, December 21, 2014 at 01:03:36 PM, Hoyer, Marko wrote: -Original Message- From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com] Sent: Saturday, December 20, 2014 6:45 PM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Improving module loading [...] I had such a discussion earlier with some of the systemd guys. My intention was to introduce an additional unit for module loading for exactly the reason you mentioned. The following (reasonable) outcome was: Do you have links for the discussions, I cannot find them. Actually not, sorry. The discussion was not done via any mailing list. systemd already has a service that loads the modules. Sorry, there is a word missing in my sentence above. My idea was not to introduce a unit for modules loading but an own unit type, such as .kmodule. The idea was to define .kmodule units to load one or a set of kernel modules each at a certain point during startup by just integrating them into the startup dependency tree. This idea would require integrating kind of worker threads into systemd. The outcome was as summarized below. Why would you need a separate unit type for that? load-module@.service: [Unit] Description=Load kernel module %I DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/modprobe %I ...then add a dependency like Required=load-module@foo.service and After=load-module@foo.service. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd log entries
Why are we spamming the journal with entries like this -- Subject: -- Defined-By: -- Support: -- Documentation: ... Dec 21 15:13:25 localhost.localdomain systemd-logind[540]: New seat seat0. -- all information required already provided at this point -- Subject: A new seat seat0 is now available -- spam -- Defined-By: systemd -- more spam -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- even more more spam -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- huge spam -- -- A new seat seat0 has been configured and is now available. -- hello JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd log entries
http://www.freedesktop.org/wiki/Software/systemd/catalog/ it is not in the journal On Sun, Dec 21, 2014 at 4:21 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Why are we spamming the journal with entries like this -- Subject: -- Defined-By: -- Support: -- Documentation: ... Dec 21 15:13:25 localhost.localdomain systemd-logind[540]: New seat seat0. -- all information required already provided at this point -- Subject: A new seat seat0 is now available -- spam -- Defined-By: systemd -- more spam -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- even more more spam -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- huge spam -- -- A new seat seat0 has been configured and is now available. -- hello JBG ___ 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] Improving module loading
-Original Message- From: Ivan Shapovalov [mailto:intelfx...@gmail.com] Sent: Sunday, December 21, 2014 3:26 PM To: systemd-devel@lists.freedesktop.org Cc: Hoyer, Marko (ADITG/SW2); Umut Tezduyar Lindskog Subject: Re: [systemd-devel] Improving module loading On Sunday, December 21, 2014 at 01:03:36 PM, Hoyer, Marko wrote: -Original Message- From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com] Sent: Saturday, December 20, 2014 6:45 PM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Improving module loading [...] I had such a discussion earlier with some of the systemd guys. My intention was to introduce an additional unit for module loading for exactly the reason you mentioned. The following (reasonable) outcome was: Do you have links for the discussions, I cannot find them. Actually not, sorry. The discussion was not done via any mailing list. systemd already has a service that loads the modules. Sorry, there is a word missing in my sentence above. My idea was not to introduce a unit for modules loading but an own unit type, such as .kmodule. The idea was to define .kmodule units to load one or a set of kernel modules each at a certain point during startup by just integrating them into the startup dependency tree. This idea would require integrating kind of worker threads into systemd. The outcome was as summarized below. Why would you need a separate unit type for that? load-module@.service: [Unit] Description=Load kernel module %I DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/modprobe %I To prevent forking a process for that ... We earlier had some issue with cgroups in the kernel, which caused between 20 and 60ms delay per process executed by systemd. But actually we are doing it now exactly this way but not with modprobe but another tool, which can load modules in parallel, takes care for synchronization (devices and attributes), and does some other stuff as well ... In some cases, we don't even have an additional unit for that. We are just putting the kmod call with an ExecStartPre= Statement into the service file, which requires the module / modules being load before. ...then add a dependency like Required=load-module@foo.service and After=load-module@foo.service. -- Ivan Shapovalov / intelfx / Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd log entries
On 12/21/2014 03:24 PM, Peter Sztanojev wrote: http://www.freedesktop.org/wiki/Software/systemd/catalog/ it is not in the journal Not only do I get duplicated reference I also get better reference from the systemd-logind.service unit itself and it's status output then I got from that message in the journal. Docs: man:systemd-logind.service(8) man:logind.conf(5) http://www.freedesktop.org/wiki/Software/systemd/logind http://www.freedesktop.org/wiki/Software/systemd/multiseat Dec 21 15:13:25 localhost.localdomain systemd-logind[540]: New seat seat0. Dec 21 15:13:25 localhost.localdomain systemd-logind[540]: New session c1 of user gdm. Dec 21 15:13:32 localhost.localdomain systemd-logind[540]: New session 1 of user johannbg. Dec 21 15:13:52 localhost.localdomain systemd-logind[540]: Removed session c1. And there is no reference to what c1 actually means in the upstream documentation and advertising the mailinglist as an support is somewhat questionable as well. We all know that opensource communities only provide best effort so on top of well advertising support in the first place where effectively exist none, are people supposed to change those line and reference to their support page if they are companies like Red Hat or Suse who can and do provide support? On top of that each of those msg implemented should be pointing to it's own msg-ID||| Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/||@MESSAGE_ID@| --- Not some random upstream documentation ( you kinda have to use the docs line in units if you are going down that road do you not? ) I think we need to rework/rethinks how this has been implemented in systemd and go through the effort of actually creating a catalog and provide each msg with it's own msg ID. And arguable we should be limiting this to error msg only since this is not particular helpful now is it/?/ This feels like we have started to provided to much information for that information to be useful to anyone. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improving module loading
On Sun, Dec 21, 2014 at 12:31:30PM +, Hoyer, Marko (ADITG/SW2) wrote: If you have control over your kernel, why not just build the modules into the kernel, then all of this isn't an issue at all and there is no overhead of module loading? It is a questions of kernel image size and startup performance. - We are somehow limited in terms of size from where we are loading the kernel. What do you mean by this? What is limiting this? What is your limit? How large are these kernel modules that you are having a hard time to build into your kernel image? - Loading the image is a kind of monolithic block in terms of time where you can hardly do things in parallel How long does loading a tiny kernel image actually take? - We are strongly following the idea from Umut (loading things not before they are actually needed) to get up early services very early (e.g. rendering a camera on a display in less than 2secs after power on) Ah, IVI, you all have some really strange hardware configurations :( There is no reason you have to do a cold reset to get your boot times down, there is the fun resume from a system image solution that others have done that can get that camera up and displayed in milliseconds. - Some modules do time / CPU consuming things in init(), which would delay the entry time into userspace Then fix them, that's the best thing about Linux, you have the source to not accept problems like this! And no module should do expensive things in init(), we have been fixing issues like that for a while now. - deferred init calls are not really a solution because they cannot be controlled in the needed granularity We have loads of granularity there, how much more do you need? So finally it is actually a trade of between compiling things in and spending the overhead of module loading to gain the flexibility to load things later. That's fine, but you will run into the kernel lock that prevents modules loading at the same time for some critical sections, if your I/O issues don't limit you already. There are lots of areas you can work on to speed up boot times other than worrying about multithreaded kernel module loading. I really doubt this is going to be the final solution for your problems. good luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] java crashes only on boot
Hello, on my up to date Arch system I use Crashplan which is a java app for offsite backups. It used to work fine, until recently... When booting java dumps core: # systemctl status crashplan.service ● crashplan.service - CrashPlan Backup Service Loaded: loaded (/etc/systemd/system/crashplan.service; enabled; vendor preset: disabled) Active: failed (Result: signal) since So 2014-12-21 20:00:59 CET; 58s ago Process: 464 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS) Process: 349 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS) Main PID: 366 (code=killed, signal=ABRT) Dez 21 20:00:48 horus CrashPlanEngine[349]: Starting CrashPlan Engine ... Using standard startup Dez 21 20:00:48 horus CrashPlanEngine[349]: OK Dez 21 20:00:48 horus systemd[1]: Started CrashPlan Backup Service. Dez 21 20:00:49 horus systemd[1]: crashplan.service: main process exited, code=killed, status=6/ABRT Dez 21 20:00:49 horus CrashPlanEngine[464]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: Zeile 144: kill: (366) - Kein passender Prozess gefunden Dez 21 20:00:50 horus systemd-coredump[459]: Process 366 (java) of user 0 dumped core. Dez 21 20:00:59 horus CrashPlanEngine[464]: OK Dez 21 20:00:59 horus systemd[1]: Unit crashplan.service entered failed state. Dez 21 20:00:59 horus systemd[1]: crashplan.service failed. % systemctl cat crashplan.service # /usr/lib/systemd/system/crashplan.service [Unit] Description=CrashPlan Backup Engine After=network.target [Service] Type=forking PIDFile=/opt/crashplan/CrashPlanEngine.pid EnvironmentFile=/opt/crashplan/bin/run.conf WorkingDirectory=/opt/crashplan ExecStart=/opt/crashplan/bin/CrashPlanEngine start ExecStop=/opt/crashplan/bin/CrashPlanEngine stop [Install] WantedBy=multi-user.target % systemctl --version systemd 218 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN But when I start it manually with systemctl start crashplan.service it works fine. I got no idea where to look for clues... Thanks, Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] java crashes only on boot
В Sun, 21 Dec 2014 21:24:22 +0100 Florian Lindner mailingli...@xgm.de пишет: Hello, on my up to date Arch system I use Crashplan which is a java app for offsite backups. It used to work fine, until recently... When booting java dumps core: # systemctl status crashplan.service ● crashplan.service - CrashPlan Backup Service Loaded: loaded (/etc/systemd/system/crashplan.service; enabled; vendor preset: disabled) Active: failed (Result: signal) since So 2014-12-21 20:00:59 CET; 58s ago Process: 464 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS) Process: 349 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS) Main PID: 366 (code=killed, signal=ABRT) Dez 21 20:00:48 horus CrashPlanEngine[349]: Starting CrashPlan Engine ... Using standard startup Dez 21 20:00:48 horus CrashPlanEngine[349]: OK Dez 21 20:00:48 horus systemd[1]: Started CrashPlan Backup Service. Dez 21 20:00:49 horus systemd[1]: crashplan.service: main process exited, code=killed, status=6/ABRT Dez 21 20:00:49 horus CrashPlanEngine[464]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: Zeile 144: kill: (366) - Kein passender Prozess gefunden Dez 21 20:00:50 horus systemd-coredump[459]: Process 366 (java) of user 0 dumped core. Dez 21 20:00:59 horus CrashPlanEngine[464]: OK Dez 21 20:00:59 horus systemd[1]: Unit crashplan.service entered failed state. Dez 21 20:00:59 horus systemd[1]: crashplan.service failed. % systemctl cat crashplan.service # /usr/lib/systemd/system/crashplan.service [Unit] Description=CrashPlan Backup Engine After=network.target Does it depend on network? In this case network may not yet be available; you may try to use network-online.target instead. [Service] Type=forking PIDFile=/opt/crashplan/CrashPlanEngine.pid EnvironmentFile=/opt/crashplan/bin/run.conf WorkingDirectory=/opt/crashplan ExecStart=/opt/crashplan/bin/CrashPlanEngine start ExecStop=/opt/crashplan/bin/CrashPlanEngine stop [Install] WantedBy=multi-user.target % systemctl --version systemd 218 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN But when I start it manually with systemctl start crashplan.service it works fine. I got no idea where to look for clues... Thanks, Florian ___ 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] java crashes only on boot
Andrei Borzenkov wrote: В Sun, 21 Dec 2014 21:24:22 +0100 Florian Lindner mailingli...@xgm.de пишет: Hello, on my up to date Arch system I use Crashplan which is a java app for offsite backups. It used to work fine, until recently... When booting java dumps core: # systemctl status crashplan.service ● crashplan.service - CrashPlan Backup Service Loaded: loaded (/etc/systemd/system/crashplan.service; enabled; vendor preset: disabled) Active: failed (Result: signal) since So 2014-12-21 20:00:59 CET; 58s ago Process: 464 ExecStop=/opt/crashplan/bin/CrashPlanEngine stop (code=exited, status=0/SUCCESS) Process: 349 ExecStart=/opt/crashplan/bin/CrashPlanEngine start (code=exited, status=0/SUCCESS) Main PID: 366 (code=killed, signal=ABRT) Dez 21 20:00:48 horus CrashPlanEngine[349]: Starting CrashPlan Engine ... Using standard startup Dez 21 20:00:48 horus CrashPlanEngine[349]: OK Dez 21 20:00:48 horus systemd[1]: Started CrashPlan Backup Service. Dez 21 20:00:49 horus systemd[1]: crashplan.service: main process exited, code=killed, status=6/ABRT Dez 21 20:00:49 horus CrashPlanEngine[464]: Stopping CrashPlan Engine ... /opt/crashplan/bin/CrashPlanEngine: Zeile 144: kill: (366) - Kein passender Prozess gefunden Dez 21 20:00:50 horus systemd-coredump[459]: Process 366 (java) of user 0 dumped core. Dez 21 20:00:59 horus CrashPlanEngine[464]: OK Dez 21 20:00:59 horus systemd[1]: Unit crashplan.service entered failed state. Dez 21 20:00:59 horus systemd[1]: crashplan.service failed. % systemctl cat crashplan.service # /usr/lib/systemd/system/crashplan.service [Unit] Description=CrashPlan Backup Engine After=network.target Does it depend on network? In this case network may not yet be available; you may try to use network-online.target instead. I don't think it depends on having actual network access. I tried using network-online.target but changed nothing. [Service] Type=forking PIDFile=/opt/crashplan/CrashPlanEngine.pid EnvironmentFile=/opt/crashplan/bin/run.conf WorkingDirectory=/opt/crashplan ExecStart=/opt/crashplan/bin/CrashPlanEngine start ExecStop=/opt/crashplan/bin/CrashPlanEngine stop [Install] WantedBy=multi-user.target % systemctl --version systemd 218 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN But when I start it manually with systemctl start crashplan.service it works fine. I got no idea where to look for clues... Thanks, Florian ___ 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] java crashes only on boot
Florian Lindner wrote: Hello, on my up to date Arch system I use Crashplan which is a java app for offsite backups. It used to work fine, until recently... When booting java dumps core: It certainly seems to some timing issue, adding ExecStartPre=/usr/bin/sleep 10 fixed it so far... :-/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] verbs: allow matching by prefix
On Sat, 20.12.14 11:19, Dave Reisner (dreis...@archlinux.org) wrote: Be nice to command line users and allow matching prefixes of verbs, similar to the way getopt_long operates. If the prefix cannot be resolved to a singular verb, log the ambiguity and return an error. --- I'm not thrilled about adding this to every manpage out of concern that it might get out of sync, but I don't really see a better way. Hmm, I am not sure I like the idea of this. I know that getopt works that way and that some tools (including ip) do this, but I am not convinced it's really a great idea. I mean, we keep making changes to the list of supported verbs, adding new entries and such. If people make use of the abbreviations this could have the effect that later on some commands that used to work stop working since something that wasn't ambiguous become abiguous. I am all for allowing people to type less, but I think command line completion is the better answer to that... Moreover the abbreviated commands certainly don't help readability either... In fact due to all of this I'd rather go the other way and find a way to turn off this magic in getopt_long()... 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] logind, su - sessions and initscripts compatibility
Andrei Borzenkov arvidj...@gmail.com writes: There is not a single word about login session in su man page. It says it starts login shell - but login session is not created by shell so I do not see where you draw this conclusion from. The primary reason to use su - in this cases is a) get a clean environment and b) make started shell read usual startup files to ensure some known state for running programs. Actually the only difference between login and non login shells is which startup files are processed. I'm no expert in this, but as far as I know, there's no solid documentation or specification regarding login sessions as a concept. But as you say, the only difference between login and non login shells is which startup files are processed. And I take that to mean that when the login startup files are processed, the intention is to create a login session, to initialize everything as if the named user was logging in. Whereas what the non login startup files are processed, the intention is that this is *not* a new login, but rather an attempt to create a shell subprocess running under the new UID which is *not* disconnected from the environment of its parent process. And when an initscript does an su to get ready to run a daemon, it really ought to use the latter method, not the former. (I have written initscripts, so I know something about that.) I would expect the architects on the systemd project have thought about these problems more than I have. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: add sdio identifiers for Broadcom WLAN cards
Hi Arend, This patch adds the sdio identifiers known to be supported by the brcmfmac open-source driver. Cc: Marcel Holtmann mar...@holtmann.org Signed-off-by: Arend van Spriel ar...@broadcom.com there are some commits with Signed-off-by lines, but in general they are not in use. So don't bother with it. --- hwdb/sdio.ids | 10 ++ 1 file changed, 10 insertions(+) diff --git a/hwdb/sdio.ids b/hwdb/sdio.ids index 8a4c713..d617297 100644 --- a/hwdb/sdio.ids +++ b/hwdb/sdio.ids @@ -34,6 +34,16 @@ 5347 GDM72xx WiMAX 02d0 Broadcom Corp. 044b Nintendo Wii WLAN daughter card + a887 BCM43143 WLAN card + 4324 BCM43241 WLAN card + 4329 BCM4329 WLAN card + 4330 BCM4330 WLAN card + 4334 BCM4334 WLAN card + a94c BCM43340 WLAN card + a94d BCM43341 WLAN card + 4335 BCM4335/BCM4339 WLAN card + a962 BCM43362 WLAN card + 4354 BCM4354 WLAN card I would prefer if we keep the file sorted as stated in the header. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedated: support split usr
The current Debian solution to this is really ugly, and I would rather
have them use the correct patch even if split usr is dumb.
Read: http://rusty.ozlabs.org/?p=236
(Why Everyone Must Oppose The Merging of /usr and /)
(I managed to skip the pulseaudio implamentation mess because I
had a fancy emu10k1 SoundBlaster Live! 5.1 which does its own
hardware mixing.)
---
src/timedate/timedated.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index bf567a1..985864a 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -123,9 +123,20 @@ static int context_write_data_timezone(Context *c) {
if (!p)
return log_oom();
+#ifdef HAVE_SPLIT_USR
+r = write_one_line_file_atomic(/etc/timezone, c-zone);
+if (r 0)
+return r;
+
+ /* /usr/sha... */
+r = copy_file((p + 2), /etc/localtime);
+if (r 0)
+return r;
+#else
r = symlink_atomic(p, /etc/localtime);
if (r 0)
return r;
+#endif
return 0;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedated: support split usr v2
The current Debian solution to this is really ugly, and I would rather
have them use the correct patch even if split usr is dumb.
Read: http://rusty.ozlabs.org/?p=236
(Why Everyone Must Oppose The Merging of /usr and /)
(I managed to skip the pulseaudio implamentation mess because I
had a fancy emu10k1 SoundBlaster Live! 5.1 which does its own
hardware mixing.)
v2: forgot to commit my debugging results before submitting
---
src/timedate/timedated.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index bf567a1..a2fd781 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -30,6 +30,7 @@
#include sd-bus.h
#include util.h
+#include copy.h
#include strv.h
#include def.h
#include clock-util.h
@@ -123,9 +124,21 @@ static int context_write_data_timezone(Context *c) {
if (!p)
return log_oom();
+#ifdef HAVE_SPLIT_USR
+r = write_string_file_atomic(/etc/timezone, c-zone);
+if (r 0)
+return r;
+
+ /* /usr/sha... */
+r = copy_file((p + 2), /etc/localtime, O_TRUNC,
+S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); /*644*/
+if (r 0)
+return r;
+#else
r = symlink_atomic(p, /etc/localtime);
if (r 0)
return r;
+#endif
return 0;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
