Hot answers tagged

6

Use systemd's coredumpctl to list and retrieve your core dumps. Use the PID or name of the program to select one to dump (to file -o ...) or to run gdb on. $ coredumpctl list TIME PID UID GID SIG PRESENT EXE Mon 2016-04-11 11:18:23 CEST 21538 1000 1000 11 * /usr/bin/sleep $ coredumpctl info 21538 PID: 21538 ...


2

Because journald (probably) differentiate the message according to _COMM of the logging service. sshd is running multiple processes and changes proctitle accordingly. It probably confuses journald. In your example, the [priv] is distinguished correctly, but [preauth] not. The second process is also running in chroot, but parent ([priv]) should log for him.


2

I think I found it. Contrary to what I first thought, the SD card is mounted at boot by udev, not by systemd. It turns out there's a rule /etc/udev/rules.d/11-media-by-label-auto-mount.rules containing: KERNEL!="mmcblk[0-9]p[0-9]", GOTO="media_by_label_auto_mount_end" # Import FS infos IMPORT{program}="/sbin/blkid -o udev -p %N" # Get a label if present, ...


2

Putting parenthesis around the name seems indicate that this process has something special There are two cases: (...) When PID 1 starts a service binary it will first fork off a process, then adjust the process' parameters according to the service config and finally invoke execve() to execute the actual service process. In the time between ...


2

I've been ducking for the solution for a while and finally I've found a solution. It worked for me. I don't know what triggers this weird behaviour though. This is the recipe for shutting down your Debian: Run ps aux | grep suspend. One of the results should be looking like this root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep ...


2

On CentOS 6: service xinetd start chkconfig telnet on chkconfig xinetd on On CentOS 7: systemctl start telnet.socket systemctl enable telnet.socket


2

You should be able to run MATE without using systemd as your system's init, but as it stands in Debian currently you need to have the systemd package installed, because mate-desktop-environment ends up depending on libpam-systemd which depends on systemd. To use all this alongside sysvinit (or Upstart) you need to install systemd-shim instead of ...


2

To set up networking for your chrooted session you need to copy the DNS configuration into the chroot environment : cp /etc/resolv.conf /mnt/etc/resolv.conf Or ln -s /etc/resolv.conf /mnt/etc/resolv.conf


1

ifconfig = Solaris ipconfig = Windows ip = Linux That I know, but am certainly open to additions and corrections.


1

Weird one. I removed all files in the following folders; Nzb, intermediate, queue Restarted the service and that did the trick. No idea why but it's now all working again


1

You cannot use shell style >> redirection in ExecStart. You need to get it to run a shell that can do the redirection for you, or set StandardOutput=. For example, try ExecStart=/bin/bash -c 'echo "%i %I" >> /home/vagrant/test.txt'


1

To understand this... does ExecStart depend on the environment set by this command? Because these lines are actually not executed in the same shell, so you can't expect them to share the environment. What you need is to use the Environment keyword in the unit file. That way, the ExecStart will get the environment defined by your file. ...


1

My systemd service kept timing out because of how long it would take to boot up also, so this fixed it for me: Edit your systemd file, for me this was /usr/lib/systemd/system/node.service. Replace "node" with your application name. Use TimeoutStartSec, TimeoutStopSec or TimeoutSec (more info here) to specify how long the timeout should be for starting ...


1

Use systemd-cat. It connects a pipeline or program output with the journal. Example: printf "Write text to the journal" | systemd-cat Result: journalctl -xn [..] Apr 12 13:37:00 servername [31509]: Write text to the journal If you want to identify the logging tool you can add the -t option: printf "Write text to the journal" | systemd-cat -t ...


1

The systemctl command communicates with systemd. systemd is not running in your container, hence the error. While it is possible to run systemd in a container, it is not a typical use case. For what you are doing, it would be far more common to start httpd directly, e.g.: CMD ["/usr/sbin/httpd", "-DFOREGROUND"]


1

You should first simplify your alias, there is no need to do the activate stuff. What is important is the first, shebang, line of the python script. It should read: #!/path/to/your/virtualenv/bin/python If the script is executable ( chmod +x script_name ) then the above line make sure that the python installed in virtualenv is called, and that ensures ...


1

Yes, you need to make the full-fledged web server executable a service. Prefer a non-root account for the service — I'd even say it's mandatory — to limit damages in cases the web server gets compromised. I think1 systemd is well documented enough to guide you through the required steps. 1 I don't run systemd, in case the question arises...



Only top voted, non community-wiki answers of a minimum length are eligible