[01:06] <ruben23> hi guys i have a startup scrip named vicidial and wanted this to be run this every startup on my Ubuntu server 16.04 any idea how to do it.?
[01:08] <sarnold> ruben23: sticking a @reboot line in a crontab would be an easy way to do it
[01:08] <sarnold> ruben23: just be aware that cron has different PATH than your login shell :)
[01:10] <ruben23> should it not be put in /etc/init.d/
[01:10] <ruben23> then make like this update-rc.d -f vicidial defaults  <------------ is this still works.?
[01:10] <sarnold> yes, that should still work too
[01:13] <sarnold> ruben23: you may or may not find this useful, too: https://wiki.ubuntu.com/SystemdForUpstartUsers
[01:17] <ruben23> ok thanks, where do we can view if how the startup script run during the startup of teh ubuntu server.? like logs
[01:18] <tomreyn> ruben23: /var/log/syslog* or journalctl -b
[01:20] <tomreyn> ruben23: the 'proper' way with systemd to run something at boot would be to create a systemd unit (start reading up on this if you'll upgrade to 18.04 LTS and beyond at some point).
[01:22] <tomreyn> for now, there are still compatibility wrappers for sysv init scripts (but i hope / wish they'll all be converted / dropped 'soon')
[13:31] <mjcd> holla all
[13:32] <mjcd> i'm looking for mouse support for the native terminals without window or desktop managers
[13:32] <mjcd> I tried um
[13:32] <mjcd> gpm
[13:32] <mjcd> but it's super laggy
[13:32] <mjcd> painful to use
[13:33] <mjcd> I know easiest solution is to ssh in from windows or wherever
=== Pugs is now known as Pugsafk
[17:18] <ratrace> hi. anyone with experince with btrfs in kernels newer than 4.9? iam re-evaluating its feasibility for production storage, and would love to hear other people's experience.
[17:30] <blackflow> ratrace: considered ZFS too? I wouldn't trust btrfs in prod.
[17:34] <ratrace> blackflow, considered but we have no interest in zfs. plus its future in linux is questionable due to license. prefer in-tree modules wherever possible.
[17:35] <compdoc> I hadnt heard there were issues
[17:37] <ratrace> compdoc, debian has a wiki page full of warnings, and we had issues with earlier kernels (4.4 and 4.9) with unmountable filesystems after conversion of extent types from single to mirror
[18:56] <hackeron_> Hi there, I have an issue with journalctl, I set it to use 100M maximum, which for some reason gives me only 2 days of logs. When I run journalctl --disk-usage it shows 106M used but when I run journalctl | wc -c - there are only 7MB of logs. Any ideas?
[19:03] <hackeron_> I posted a question with more details here: https://serverfault.com/questions/975160/journalctl-disk-usage-shows-106m-while-journalctl-wc-c-shows-only-7mb-of-lo
[20:08] <Walex> ratrace: Btrfs works well except for the multiple device layer. If you use it on a single block device (e.g. based on MD) it is quite reliable.
[20:14] <ratrace> Walex, that defeats almost all the advantages of btrfs
[20:15] <Walex> ratrace: the main advantage of Btrfs is snapshots...
[20:19] <andol> Walex: Because everyone has the same use case and sees the same advantages?
[20:22] <TJ-> hackeron_:  the stored logs are binary and include lots of meta-data you don't see in the usual output
[20:25] <Walex> andol: because snapshots is the almost unique feature of Btrfs, unique if you count only in-kernel filesystems
[20:30] <ratrace> Walex, yes snapshots and checksumming, make the two top reasons we want btrfs.
[20:31] <ratrace> checksumming more than snapshots
[21:16] <blackflow> ZFS has no issues with RAID levels tho'.